Slashdot Mirror
Accelerating IPv6 Adoption With Proxy Servers
jgarzik writes "IPv6 presents a catch-22: the most popular web sites on the Internet
don't have any incentive to switch to IPv6 until a large portion
of their userbase is on IPv6, and their user base does not have a
large incentive to switch to IPv6 until many of the popular Internet
destinations support IPv6. My proposed solution is simple: Configure a proxy server that
serves IPv6 requests, passing those requests through
to underlying IPv4-only servers that not have yet been transitioned
to IPv6.
This article describes how to configure Apache's proxy server to fill this role, and suggests a few ideas for use."
This page/site already does it.
By having an open proxy anyone can send/receive data via your proxy server (duh). There are implications: e.g. I've seen someone's server bandwidth being used to serve images in a spam (pr0n) email.
If you don't want people hiving off your bandwidth and potentially using your server's bandwidth for puposes you wouldn't normally approve of, then consider controlling your proxy access.
--
Use your VPS proxy powers for the powers of good
The solution is more ISP support. This is where you vote with your wallet. If your ISP doesn't support IPv6, find another. Same goes if you're hosting a Web site. They will eventually catch on and begin offering IPv6 more widely.
US businesses that currently accept chip and PIN/signature
From there:"
Why does this service exist?
There appears to be a chicken and egg problem in deploying IPv6; ISP's serving endusers don't want to do it yet because there isn't any need for it from their clients, Hosting companies don't do it yet because there isn't any demand yet either from clients... Thus, we made this gateway, which allows users who do have IPv6 to get to all the content in the IPv4 world. If you don't have IPv6 connectivity (yet) you can of course try the SixXS Tunnel Broker.
This is essentially the same observation and the same solution except that it focuses on getting ISPs (clients) to support IPv6 rather than servers.
Okay, I'll answer my own question. They have them for www.ipv6.org, but not for ipv6.org itself.
Karma: It's all a bunch of tree-huggin' hippy crap!
there's also no A record for ipv6.org itself also -- so boo; its not like they singled out AAAA
its just another one of those loony sites thats www. only; and not just the domain name.
May this post be indexed by spiders, and archived for all to see as my Internet epitaph.
40% of the IPv4 address space is unallocated, and much of the allocated space is probably unused.
The issue with ipv6 adoption is not an issue of servers or clients, it's an issue of routers.
ISP's need to adopt ipv6.
Tunnelling won't push adoption, but it might help YOU if you need to work with someone who is using ipv6.
> Do you use NAT (a home router)?
> Blame your IPv4-based ISP for not having enough
> address space for you.
For most peopel NAT actually solves a problem instead of being one.
Yeah, for some people it would be nice to be able to have their toaster online and reachable through the internet as well, and lack of addresses can make that difficult, but most people do not have a big urge to do such things.
They do however have a problem with their computer and an unfiltered internet connection.
A router that does NAT happens to function as a pretty good ip filter with state-keeping that is extremely easy to configure.
> Do you run a web-hosting company?
> You probably know how expensive address space
> is.
Yep, sadly enough, IPv6 sounds more advanced, and thus will be more expensive. The people who market the stuff have absolute controll over the supply so can set a price as they like.
Isn't this just 6to4 which has been around for ages?
The intention with IPv6 is that you won't have "unroutable" networks, like we do with private nets such as 10.x.x.x and 192.168.x.x. Everything will have a globally unique IPv6 address. There was in the original spec what were called a "site-local" addresses, which were private addresses not routed to the outside much like their IPv4 analogues, but those have been deprecated.
However, you'll have plenty of addresses because, in the current incarnation, you're not allocated a single address, but rather you are allocated a subnetwork, which is currently 2^64 addresses. So the first 64 bits are assigned to you by your ISP, and then the second 64 bits are yours to do with as you like.
So that addresses the question of NAT: there won't be any lack of IP addresses necessitating its use. I am only addressing the use of NAT as a way around limited address space, and not any of the other uses for which NAT has.
But what about DHCP? IPv6 comes with something more elementary, called "stateless autoconfiguration." Basically, the router constantly broadcasts your "prefix" to the subnetwork, which is the first 64 bit half of your 128 bit address your ISP assigns you. The machine then takes its subnetwork ID (the MAC address), and sets the second 64 bits to a function of that. In the case of Ethernet, it isn't the 48-bit Ethernet MAC address verbatim, but a published function of it. It's called stateless because it's always a function of whatever the network's prefix is plus some kind of subnet ID, and there's no concept of leases, or any of the state a DHCP server maintains.
There is not yet an equivalent mechanism for "stateful autoconfiguration," which is more what DHCP is, where you can automatically assign an arbitrary address to a client. You can of course statically configure an interface to have a specific address, but there is no automated mechanism to always assign a particular autoconfigured client a particular address you designate. There are proposed standards for an IPv6 version of DHCP, however, and I expect eventually such a beast will eventually come around.
The part you missed is that the pilot can't be diagnosed by a doctor unless he asks to be seen; and since he fears for his own life enough to ask for a diagnosis, he is clearly not insane.
Karma: -2147483648 (Mostly affected by integer overflow)
That problem was IPv4 addressing: not just address space exhaustion, which isn't an immediate problem anyway, but also global routing table sizes. IPv6 is intended from the start to be more aggregatable. If LargeISP1 has one hundred customers using IPv4, that probably means close to one hundred routing table entries. Under IPv6, it is hoped that will be more like one, though in practice it will probably be more. Smaller routing tables means cheaper and faster routers. (On top of that, some people are doing silly things with IPv6, like giving multiple addresses to a single mobile phone, which has no need to be globally addressable anyway.)
The IP numbering allocation in IPv6 is hierarchal, which they are not in IPv4. The first 16 bits are the FP and Top Level Address (allocated to "trunk" cos like MCI), the next is a 32 byt "Next Level Addres" allocated to ISPs, and finally "Sight Level Address"es allocated to people like you and me.
At the moment many routing tables on the trunks have thousands of entries, increasing as allocation of IPv4 becomes more and more fragmented, significantly slowing down the trunks. IPv6 will mean considerably fewer routing table entries there, increasing performance.
Although the raw IPv6 header is larger than the minimum IPv4 header, a system of, in effect, encapsulating parts of the headers in the data packet that are not needed in routing exists where it does not in IPv4 (such as those needed in TCP). The savings there should more than make up for the degregation in increasing the minimum size of 20 to a fixed size of 40.
It is a misconception that IPv4 produces 4 billion IP addresses for the world to use. By the time all the university's Class A addresses and all the wasted IP addresses of those who have networks with machines missing are considered, all the network and bradcast addresses and so on are also considered you will be lucky to see 3 billion. In fact I would not be surprised if the figure was nearer 2. This may be enough for the Western World but not for Asia as well.
IPv6 is also neccessary to adopt the up and coming internet technologies, such as those that use MultiCast (IPv4 implementation of this will NEVER get adopted). I agree with you that it is the routers that are holding this back - but once an area is enjoying the benefits of IPv6 then I believe it will rapidly spread.
My 2c worth....
Web Sig: Eddy Currents
The flaw with that logic is that, in reality, NAT was designed to solve a completely different issue. Mainly, keeping private networks away from public networks, with connectivity only as specifically allowed on a specific ruleset. A firewall, in a sense, except it was never designed to "stop" or "drop" packets as one thinks of a firewall-- only deliver them from the outside, in. The firewall effect is a side benefit in and of itself.
With my ISP package, I get eight IPs. Eight! I'm only using five of them among my four boxes at home, but I'm quite seriously considering NAT'ing up a few of the lesser used boxes. At the moment, they're not configured to act as a private network, yet I'm considering it. The ones I don't monitor as frequently pose a security threat, and as such, NAT is the quick, cheap solution.
The extra "IP space" one benefits is just an added side benefit.
Of course, we now know that NOT having proxies has been a disasterous mistake. I can only hope the IPv6 community in general can accept that.
IPv6 is more than just addresses. You have utterly transparent mobile IP. You have automatic network configuration. Anycasting allows you to request a service and have the closest server respond, without you needing to know where that server is. You have almost-mandatory IPSec - which is more than just encryption, it authenticates that the machines are who they say they are.
IPv6 is a valuable tool. Back in the early days, I ran the first registered IPv6 node in Britain. At its peak, I had 10 tunnels running across Europe and the US. That was using IPv6 under Linux 2.0.20, using the-then VERY experimental IPv6 patches that existed. It started with static routes, but I later moved to MRT and finally Zebra.
MRT and Zebra are now fast-decaying abandoned project, as far as I can tell. The only Open Source software router I can find is Click, and whilst it's good, it doesn't have the developer- or user-base to be confident that it can really do more than be a nice experimental project.
(Any distro authors out there SHOULD put it in their distro, if for no other reason than the fact that Linux will cease to be useful as a router platform, if the last remaining projects don't get adopted.)
IPv6 would benefit from having an IPv6-over-IPv4 protocol defined, much in the same way that SIT defines IPv4-over-IPv6. Again, I've argued this from the start. The idea of a migration to IPv6 will NOT be realised or realisable until the average person can plug in an IPv6 address into a browser or some other network software, without having to care about the fact that it is IPv6, and see a result.
Once IPv6 is truly transparent to the "unwashed masses", you'll start to see people adopting it. After all, it IS easier to configure and maintain. That would make people like ISPs very happy. Less time wasted on network maintenance means more profit for them. And nobody is averse to getting a little richer, a little quicker, when it costs nothing to do. You even have the bonus that it's legal and ethical (though some wouldn't care about that part).
Because IPv6 supports host authentication, it's great for Joe/Jane Average, too. It's harder to spoof mail addresses, when the mail server can validate the transmitting machine. That won't eliminate spam, but it will make using fake addresses slightly harder, which will give people a little more confidence that the sender is who they say they are.
Because multicasting is part of the standard, it also means that video streaming to multiple recipients will be less savage on the network. Once people realise that you can get damn near TV-quality reception by multicast, versus 5 seconds a frame (with tiny, low-grade frames) via a typical webcast, who in their right minds will go back to that worn-out way?
(And by near-TV standard, I'm talking NTSC or PAL resolution at 15 to 20 frames per second. The bandwidth would be impossible to maintain, if the server had to do point-to-point to every recipient, but it's very doable over a multicast transmission, and it's very normal for any of the multicasts advertised using SDR or similar tools.)
The technology that people have, right now, versus the technology researchers have had for decades is pathetic. What you can buy as top-of-the-line off-the-shelf today was commonplace in most research labs 10-15 years ago. Some of the slow adoption comes from wanting to really test the technology. Most comes from corporations dragging their feet and exploiting the time-lag to squeeze their victims^H^H^H^H^H^H^Hcustomers for every penny they h
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Okay, I won't argue with you there.
It's deliberate overkill. It allows things like 64-bit subnets, which in turn allow for stateful autoconfiguration. It also allows for large chunks of address space that won't be allocated at all; if it turns out in the future that our current allocation method is inadequate for our needs, we can simply devise a new allocation method in this empty space, rather than having to migrate to a whole new version of IP.
Yes, if an IPv6 router had to hold nearly 150,000 routes in memory like it does in the current IPv4 world, it would be massive. Fortunately, IPv6 is designed to have properly aggregated addresses, so that things are much more hierarchical, and routing tables can be stored much more efficiently.
Aside from the fact that more and more connections are using much larger MTUs these days, IPv6 also supports more aggressive header compression than IPv4 did, often resulting in similarly compact headers.
\\'
Please, correct me if I am wrong.
Isn't the internet IPv4 only and IPv6 is archieved thru
encapsulations like The 6Bone ?
If so, what's the point of worring about sites not being in the 6bone?
If I am wrong, can you post some links please?
Thanks
If you're so confident that your dissertation has academic merit, why don't you put your name to your post?
1) No arguments, mainly because I don't know about the architectures of the Cisco and Juniper PEs used.
2) For a post-grad student, you don't seem to know much about IPv4. Almost 17 million addresses taken by each of 127/8 and 10/8. Another million gone with 172.16/12. 192.168/16 rounds that all out to about 36 million. Almost one percent of the address space gone, just on reserved ranges. The experimental ranges take some more space again. Then there're all the network and broadcast addresses, with CIDR making that problem worse, even while it does solve the issue of giving organisations blocks of space that're wildly in excess of their requirements.
3) I dunno who makes your NIC, but all mine have a 48-bit MAC.
IPv6 does nice aggregation. Routers only need to know about their immediate network, everything else they see as an aggregation. So rather than knowing about every
Plus, RAM's cheap. Even the Kingston stuff you need for Ciscos. Couple cheap memory with the very good route summarisation in the IPv6 spec, and it's a non-issue.
4) The current IP network has these restrictions. With jumbo frame and the various other techniques now in existence, you don't think it's possible that part of the migration to IPv6 will be to throw a few more bytes into the packet size?
I can't belive you got a +4 (Informative) for that load of tripe. No wonder people have no respect for the moderators!
"God, root, what is difference?" - Pitr, userfriendly
That's not true. It's much easier to give out as many IPs are requested. You need to specially configure a DHCP server to refuse a lease. If IPs were not a scarce resource, you would be able to get as many as you wanted.
<xml><I><am><so><damn>Web 2.0</damn></so></am></I></xml>
A few quick issues with your points, just be glad I'm not on your review board, it wouldn't be pretty.
Oh, and if you actually read said RFC you would learn that it is not a solution, it is a bandaid. Just read the abstract:
BGP currently shows roughly 1.3B addresses as being routable. That represents a little more than 25% of the IPv4 space.
/8's around and a ton of academic institutions (MIT) and large corporations (Eli Lilly, etc.) that received /8 assignments back in the day.
/8 recipients from that time wont either.
e
There are alot of special use
I can not imagine MIT utilizing 16.7M IP's, and most other
For more information see http://www.iana.org/assignments/ipv4-address-spac
> Which is one more step than a NAT box requires (for the same functionality as far as the home luser is concerned).
Uh yes, but one more step doesn't exactly make for a very complicated router setup. They already have to fill out a box with their username and password. I really do not see why there would be a problem in filling in a 3rd field (the contents of which are provided by the ISP just like the rest)
Argument was that nat makes it a lot easier, well, it makes it easier but not a lot. I didn't think that was that hard to understand really was it?
Did anyone else wonder, "whatever happened to IPv5?"?
Well, this seems to be the answer...
Cheers & God bless
Sam "SammyTheSnake" Penny
NAT does not filter anything. A firewall does. You probably already have a firewall, so taking away the NAT would not change the security of your network one bit.
While NAT doesn't filter anything, it does achieve the same result as blocking connections by default, because people will either be trying to access your external IP which will not result in a connection without an appropriate forwarded port, or they will be trying to access your internal IP which is not routable, and backbone routers drop source routed frames. In fact, so does linux, by default, IIRC. Hence, while it's not filtering, it might as well be.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
I'm not talking about source routing. I'm talking about plain old vanilla routing.
You've got two machines on one big network which from our perspective is an ethernet. Perhaps the underlying stuff is the cable cloud in your part of town.
One machine on this network is a router with public IP 172.30.0.2, not filtering anything. Behind this router is 10.0.0.0/24.
On another machine on this big network you type 'route add -net 10.0.0.0/24 gw 172.30.0.2'. Also on this machine you then type 'ping 10.0.0.1' and notice the reply.
No source routing involved here at all.