Creating demand for IPv6, and saving the planet
A number of people have bemoaned the lack of any IPv6-only killer-content that would drive a demand for IPv6. I've thought about this, and about the government's push to make IPv6 a reality. What occurred to me is there is a satellite sitting in storage that would provide such content: http://en.wikipedia.org/wiki/Triana_(satellite) Al Gore pushed for this satellite, Triana, to provide those on earth with a view of the planet among its scientific goals. The Republicans referred to it as an "overpriced screen saver," though the effect even of just the camera component on people's lives and how they treat the planet could be considerable. By combining the launch of Triana with feeding the still images and video from servers only connected to native IPv6 bandwidth, the government would provide both a strong incentive for end users to want to move to IPv6, and a way to get the people of this planet to stop from time to time and ponder the future of the earth. Of course getting this done any time soon would require getting the present administration to reverse its bias against Triana and global warming. But it seemed to me an interesting way to advance two goals in synergy. Dan -- ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.com "Our lives begin to end the day we become silent about things that matter." -- Martin Luther King, Jr.
* Daniel Senie:
By combining the launch of Triana with feeding the still images and video from servers only connected to native IPv6 bandwidth, the government would provide both a strong incentive for end users to want to move to IPv6, and a way to get the people of this planet to stop from time to time and ponder the future of the earth.
How do you stop people from creating IPv4 gateways to the service?
From this perspective, copyrighted porn is much better.
While that may work (I am not going to get into the politics), I think the other poster has a good point that people would create gateways. Actually, a better way to push IPv6 is make users want it and feel like they are missing out if they don't have it. I campaign with some kind of slogan like 'got IPv6' or "I've got ultra high tech IPv6 for my internet and you don't" with a web url like www.getipv6.com (oops, some domain squatter already registered it). For the most part the ISP and provider community is not going to put resources into IPv6 unless there is a market demand for IPv6. By making end users feel like they are missing out on something or not as 'cool' since they don't have it, you will create a market demand. The whole model of making something appealing or making someone feel left out without something is a science that has been exploited by marketing groups for years. If an ISP loses customers because it doesn't have 'cool' IPv6 and another does you can probably bet your money that they will be launching a 'new' 'cool' IPv6 product. This all boils down to simple economics.... supply and demand. When the market has a strong demand for something the technical challenges tend to get mastered faster than when there is not a market demand. As far as creating a demand for something technical that people don't understand, I think that is is very possible just look at some of the crazy fads (remember the neon lights under cars) that people buy. -- Brian Raaen Network Engineer braaen@zcorum.com Tel 678-507-5000x5574 On Monday 01 October 2007 11:53, Daniel Senie wrote:
A number of people have bemoaned the lack of any IPv6-only killer-content that would drive a demand for IPv6. I've thought about this, and about the government's push to make IPv6 a reality. What occurred to me is there is a satellite sitting in storage that would provide such content:
like 'got IPv6' or "I've got ultra high tech IPv6 for my internet and you don't" with a web url like www.getipv6.com (oops, some domain squatter already registered it).
http://www.getipv6.info could put that on the main page if enough people demand it.
For the most part the ISP and provider community is not going to put resources into IPv6 unless there is a market demand for IPv6.
And unless there are IPv6-knowledgeable people to hire, or already on staff. Someday IPv6 will be a routine part of training and education programs like CCIE. But right now it would be nice if more people would submit info for the http://www.getipv6.info/index.php/Educating_Yourself_about_IPv6 page. Right now it points to several ways of building a home IPv6 lab network using virtual machines, a couple of papers/presentations, one free book and some other miscellanous bits. Any other ISP-oriented material on IPv6 and its deployment would be welcome. --Michael Dillon
On 10/2/07, Brian Raaen <braaen@zcorum.com> wrote:
Actually, a better way to push IPv6 is make users want it and feel like they are missing out if they don't have it. I campaign with some kind of slogan like 'got IPv6' or "I've got ultra high tech IPv6 for my internet and you don't" with a web url like www.getipv6.com (oops, some domain squatter already registered it).
Brian, I offer you two words: Ford Edsel. It doesn't matter how clever you make the marketing campaign if on finding out what the product actually is the customers decide they don't want it.
This all boils down to simple economics.... supply and demand.
As far as I can tell, IPv6 is at least theoretically capable of offering exactly two things that IPv4 does not offer and can't easily be made to offer: 1. More addresses. 2. Provider independent addresses At the customer level, #1 has been thoroughly mitigated by NAT, eliminating demand. Indeed, the lack of IPv6 NAT creates a negative demand: folks used to NAT don't want to give it up. This community (network operators) has refused to permit #2, even to the extent that its present in IPv4, eliminating that source of demand as well. Regards, Bill Herrin -- William D. Herrin herrin@dirtside.com bill@herrin.us 3005 Crane Dr. Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
Thus spake "William Herrin" <herrin-nanog@dirtside.com>
As far as I can tell, IPv6 is at least theoretically capable of offering exactly two things that IPv4 does not offer and can't easily be made to offer:
1. More addresses. 2. Provider independent addresses
At the customer level, #1 has been thoroughly mitigated by NAT, eliminating demand. Indeed, the lack of IPv6 NAT creates a negative demand: folks used to NAT don't want to give it up.
This community (network operators) has refused to permit #2, even to the extent that its present in IPv4, eliminating that source of demand as well.
If you feel ARIN has not solved the PIv6 issue sufficiently well, please take that argument to PPML. As of today, if you qualify for PIv4 space, you qualify for PIv6 space automatically -- and you only have to pay the fees for one of them. If you're claiming that you have a PIv6 block and ISPs won't route it, please publicly shame the offending parties here so the rest of us will know not to give them our money. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
Stephen Sprunk wrote:
Thus spake "William Herrin" <herrin-nanog@dirtside.com>
As far as I can tell, IPv6 is at least theoretically capable of offering exactly two things that IPv4 does not offer and can't easily be made to offer:
1. More addresses. 2. Provider independent addresses
At the customer level, #1 has been thoroughly mitigated by NAT, eliminating demand. Indeed, the lack of IPv6 NAT creates a negative demand: folks used to NAT don't want to give it up.
This community (network operators) has refused to permit #2, even to the extent that its present in IPv4, eliminating that source of demand as well.
If you feel ARIN has not solved the PIv6 issue sufficiently well, please take that argument to PPML. As of today, if you qualify for PIv4 space, you qualify for PIv6 space automatically -- and you only have to pay the fees for one of them.
Really? As far as I understood it, I still had to pay $500 for end-user allocations. ~Seth
Thus spake "Seth Mattinen" <sethm@rollernet.us>
Stephen Sprunk wrote:
If you feel ARIN has not solved the PIv6 issue sufficiently well, please take that argument to PPML. As of today, if you qualify for PIv4 space, you qualify for PIv6 space automatically -- and you only have to pay the fees for one of them.
Really? As far as I understood it, I still had to pay $500 for end-user allocations.
If you're an end user, you pay $100/yr for _all_ your resources. If you're an LIR, you pay either your v4 or v6 maintenance fees, whichever is greater. I don't know the status of the v6 initial assignment fee; I think that the v6 initial allocation fee was waived at one point. If they're not waived now, that'd be a one-time cost of $1250. The only $500/yr fee is to be a "General Member", which is how non-LIRs get to vote in ARIN elections. You don't need to be a member to get a v6 assignment. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
On Tue, 2 Oct 2007, Stephen Sprunk wrote:
I don't know the status of the v6 initial assignment fee; I think that the v6 initial allocation fee was waived at one point. If they're not waived now, that'd be a one-time cost of $1250.
I'm pretty sure it's still being waived (at least for ISP/LIRs). I just applied for and received Atlantic.net's v6 /32 without paying any fees in advance. IIRC, with IPv4 initial allocations, you have to pay in advance. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On 10/2/07, Stephen Sprunk <stephen@sprunk.org> wrote:
If you feel ARIN has not solved the PIv6 issue sufficiently well, please take that argument to PPML. As of today, if you qualify for PIv4 space, you qualify for PIv6 space automatically -- and you only have to pay the fees for one of them.
Stephen, At this point its not an ARIN problem. The requirement from the operators (like us) is that ARIN keep the total number of PI prefixes to a minimum. So long as that requirement stands, ARIN is doing the best it can. Having recently dealt with the 244k IPv4 TCAM limit on my 6500 sup 2's, I'll stipulate that the requirement has merit. But lets not pass buck; its our requirement, not ARIN's. Also, to be clear: if you meet the requirements for IPv4 addresses today then you can get IPv6 addresses today. This is not parity with IPv4: a large number of IPv4 addresses are presently assigned to organizations who met the requirements of their day but do not meet today's requirements. Regards, Bill Herrin -- William D. Herrin herrin@dirtside.com bill@herrin.us 3005 Crane Dr. Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Tue, 2 Oct 2007, William Herrin wrote:
On 10/2/07, Brian Raaen <braaen@zcorum.com> wrote:
Actually, a better way to push IPv6 is make users want it and feel like they are missing out if they don't have it. I campaign with some kind of slogan like 'got IPv6' or "I've got ultra high tech IPv6 for my internet and you don't" with a web url like www.getipv6.com (oops, some domain squatter already registered it).
Brian,
I offer you two words: Ford Edsel.
It doesn't matter how clever you make the marketing campaign if on finding out what the product actually is the customers decide they don't want it.
This all boils down to simple economics.... supply and demand.
As far as I can tell, IPv6 is at least theoretically capable of offering exactly two things that IPv4 does not offer and can't easily be made to offer:
1. More addresses. 2. Provider independent addresses
not to state the obvious but: 3. reachability instead of a world of black holes and walled gardens. maybe I'm just a flat-earther... http://hsci.cas.ou.edu/images/jpg-100dpi-10in//19thCentury/Flammarion/1888/F... - Lucy
At the customer level, #1 has been thoroughly mitigated by NAT, eliminating demand. Indeed, the lack of IPv6 NAT creates a negative demand: folks used to NAT don't want to give it up.
This community (network operators) has refused to permit #2, even to the extent that its present in IPv4, eliminating that source of demand as well.
Regards, Bill Herrin
At 12:42 PM -0400 10/2/07, William Herrin wrote:
As far as I can tell, IPv6 is at least theoretically capable of offering exactly two things that IPv4 does not offer and can't easily be made to offer:
1. More addresses. 2. Provider independent addresses
At the customer level, #1 has been thoroughly mitigated by NAT, eliminating demand. Indeed, the lack of IPv6 NAT creates a negative demand: folks used to NAT don't want to give it up.
#1 has been partially mitigated by NAT, and perhaps only temporarily. The last chapter of that book is yet to be written. /John
On Tue, 2 Oct 2007, William Herrin wrote:
As far as I can tell, IPv6 is at least theoretically capable of offering exactly two things that IPv4 does not offer and can't easily be made to offer:
1. More addresses. 2. Provider independent addresses
At the customer level, #1 has been thoroughly mitigated by NAT, eliminating demand. Indeed, the lack of IPv6 NAT creates a negative demand: folks used to NAT don't want to give it up.
At the internet access customer level perhaps. As a hosting provider, try telling your customers "here's your IPv4 /32. If you need more IPs, just use NAT." and see how many customers you retain. The problem is, when we can't get more IPv4 IPs, and we have to assign addresses to customers, what do we do? Give them IPv6 IPs only? Then how does the IPv4 internet (all those people who didn't need or want v6 because they've got NAT) get to those customers? At some point, everyone's going to need to upgrade in order to "stay on the internet." ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On 10/2/07, Jon Lewis <jlewis@lewis.org> wrote:
On Tue, 2 Oct 2007, William Herrin wrote:
At the customer level, #1 has been thoroughly mitigated by NAT, eliminating demand. Indeed, the lack of IPv6 NAT creates a negative demand: folks used to NAT don't want to give it up.
At the internet access customer level perhaps. As a hosting provider, try telling your customers "here's your IPv4 /32. If you need more IPs, just use NAT." and see how many customers you retain.
Jon, Let me spin you a tale. More of a nightmare really. During early phase of free pool exhaustion, when you can't deliver more IPv4 addresses to your customers you lose the customer to a hosting provider who still has addresses left. So sorry. Those will be some nasty years. Unless you're Cogent, Level3 or one of the others sitting pretty on a /8. They'll be in phat city. What should you do about it? Buy stock. And make no mistake: it will drag on and on. Even when everybody is well and truly out, there are a heck of a lot of addresses that can be reclaimed in dialup pools, residential DSL pools and other uses retroactively deemed wasteful by converting them to NAT. And with NAT inbound you can load a lot of functions on a single IP address. How long will it drag on? I'm not that great an oracle. But let me offer you a mild heresy: when you combine aggressive CIDR with double and triple NAT do you really believe that 4B addresses can't be enough for the pushing 7B people on Earth? Must it ever truly end? IPv4 forever. One possible price for failing to deliver an IPv6 that customers want today. Regards, Bill Herrin -- William D. Herrin herrin@dirtside.com bill@herrin.us 3005 Crane Dr. Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
At 5:25 PM -0400 10/2/07, William Herrin wrote:
How long will it drag on? I'm not that great an oracle. But let me offer you a mild heresy: when you combine aggressive CIDR with double and triple NAT do you really believe that 4B addresses can't be enough for the pushing 7B people on Earth? Must it ever truly end?
It doesn't have to end if there's an amazing amount of care in organizing those /32's into aggregated routes... ;-) /John
During early phase of free pool exhaustion, when you can't deliver more IPv4 addresses to your customers you lose the customer to a hosting provider who still has addresses left. So sorry. Those will be some nasty years. Unless you're Cogent, Level3 or one of the others sitting pretty on a /8. They'll be in phat city.
this is a very real and significant problem. a very small fraction of the arin membership holds the vast majority of the address space. it would be interesting to ask arin to give us the cdf of this. given that, the scenario you present is likely to be very real. but what do we do about it? randy
On 10/2/07, Randy Bush <randy@psg.com> wrote:
During early phase of free pool exhaustion, when you can't deliver more IPv4 addresses to your customers you lose the customer to a hosting provider who still has addresses left. So sorry. Those will be some nasty years. Unless you're Cogent, Level3 or one of the others sitting pretty on a /8. They'll be in phat city.
this is a very real and significant problem. a very small fraction of the arin membership holds the vast majority of the address space. it would be interesting to ask arin to give us the cdf of this.
Randy, It would be nice if it was that simple. Those /8's arise from legacy assignments that fall more or less directly under IANA without any form of agreement in place that could allow policy change. Barring government action, they're effectively the unrecoverable property of those organizations. They can even act as mini-registries and auction addresses off to the highest bidder if they're so inclined.
given that, the scenario you present is likely to be very real.
but what do we do about it?
Unless something brilliant arrives out of left field, the only thing we can do is deploy and get customers to deploy IPv6 -before- IPv4 free pool exhaustion starts to hit. That's really not on track right now. Some things which might help get it back on track are: 1. End the insanity of having software prefer IPv6 if available (AAAA records over A records). That's a commonly cited reason that folks who tried IPv6 stopped using it. I might make some of my stuff available via 6to4 but 6to4 is pretty meager so there's no way I'd consider it when stacks will prefer trying to communicate with IPv6. 2. Figure out a PI solution for IPv6 capable of scaling to the equivalent of hundreds of millions of routes in the core at a per-route cost two orders of magnitude less than it is today. RRG is working on this but there aren't enough people involved, they're not focused on a solution that delivers that degree of scalability, they're not in a hurry and AFAIK they're not well funded. This seems self-defeating given how much money rides on a useful answer coming out of the IETF. 3. Produce IPv6 NAT. Folks are used to NAT. They're comfortable with the security they believe NAT provides. They might eventually switch away from NAT if some desirable new application requires it but they won't refactor their network security policies as a prerequisite to deploying IPv6. On 10/2/07, Mark Smith <nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> wrote:
Have you used a NAT free Internet?
Mark, I maintain a /23 in the swamp and have since '94. For the record, I didn't even like NAT back when it was still called "circuit level proxying." I'd love to have an Internet where all firewalls were packet filters. But that's not my call. That's the call of hundreds of thousands of network security officers who have NAT written in stone at the core of their security process. Tying NAT's abandonment to IPv6's deployment won't change their minds but it will doom IPv6.
So if more addresses was "thoroughly mitigated by NAT", when were these problems that NAT creates fixed? http://www.cs.utk.edu/~moore/what-nats-break.html
Many of those never were meaningful problems and most of the rest have been obsoleted by the changing reality of network security on the Internet. Things like controlling the source port meant something once upon a time, but they have no place in a modern security infrastructure. That would be true with or without NAT. The -real- problems with NAT can be summed up in two statements: 1. NAT makes it more difficult to engage in certain popular activities that strictly speaking are against the TOS. 2. NAT makes logging and accountability more difficult. Regards, Bill Herrin -- William D. Herrin herrin@dirtside.com bill@herrin.us 3005 Crane Dr. Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
During early phase of free pool exhaustion, when you can't deliver more IPv4 addresses to your customers you lose the customer to a hosting provider who still has addresses left. So sorry. Those will be some nasty years. Unless you're Cogent, Level3 or one of the others sitting pretty on a /8. They'll be in phat city. this is a very real and significant problem. a very small fraction of the arin membership holds the vast majority of the address space. it would be interesting to ask arin to give us the cdf of this.
It would be nice if it was that simple. Those /8's arise from legacy assignments that fall more or less directly under IANA without any form of agreement in place that could allow policy change. Barring government action, they're effectively the unrecoverable property of those organizations. They can even act as mini-registries and auction addresses off to the highest bidder if they're so inclined.\
and this prevents producing a cdf exactly how? randy
On 3-okt-2007, at 5:20, William Herrin wrote:
1. End the insanity of having software prefer IPv6 if available (AAAA records over A records).
Insanity? Using IPv6 by default can lead to suboptimal results, but there's really no alternative: even in the IETF people think I'm a few bits short of a /128 when I talk about running IPv6-only. And as long as you have both IPv4 and IPv6 connectivity and prefer IPv4, you're never going to see if IPv6 even works, let alone how well.
2. Figure out a PI solution for IPv6 capable of scaling to the equivalent of hundreds of millions of routes in the core at a per-route cost two orders of magnitude less than it is today.
Sure: http://www.muada.com/drafts/draft-van-beijnum-multi6-isp-int-aggr-01.txt
3. Produce IPv6 NAT.
Believe it or not, there are already products that do IPv6 NAT.
On 3-Oct-2007, at 0422, Iljitsch van Beijnum wrote:
On 3-okt-2007, at 5:20, William Herrin wrote:
1. End the insanity of having software prefer IPv6 if available (AAAA records over A records).
Insanity?
I am increasingly of the opinion that the insanity is not in the stub resolver API, but in the decision to deploy dual stack towards end users in the first place. Deploying both IPv4 and IPv6 towards end systems means increased opex, increased support costs, and often reduced performance for users. As a bonus, it does nothing to reduce IPv4 resource consumption. In the absence of any IPv6-only content, it's hard to see what problem this solves. Perhaps this helps explain the lack of deployment. However, if there was a reasonable translation mechanism available which allowed IPv6-only end systems to access IPv4-only content, I think the picture would look quite different. Connecting users with IPv6 only might represent a cost saving (since the addresses are easier to acquire, and easier to manage; there's greatly reduced need to engage in protracted justification exercises in order to give someone a block of addresses.) If the translation mechanism was such that IPv4 content could be consumed, but IPv6 content could be reached more quickly/reliably, then a groundswell in translated IPv6-only end users would provide incentive for content providers to listen on IPv6 as well as IPv4. The translation mechanism doesn't currently exist (although the document that deprecated NAT-PT suggested that it should be created). Designing a universally-general translation mechanism seems hard, and seems likely to suffer from many of the same problems as IPv4-IPv4 NAT; perhaps as an interim measure, however, for the millions of Internet users for whom the network mainly means 80/tcp, the mechanism doesn't have to be universally-general. Perhaps it just has to be good enough. Perhaps the assignment of IPv4 addresses to end users could become a premium service available to those who need them, leaving cheaper, IPv6-only service for everybody else. If there was significant price incentive for users to choose IPv6- only access over IPv4-only or dual stack, perhaps the translation mechanism could be a real, interim measure (as opposed to the kinds of interim measures that hang around smelling bad for 30 years). Perhaps, perhaps. :-) Joe
However, if there was a reasonable translation mechanism available which allowed IPv6-only end systems to access IPv4-only content, I think the picture would look quite different.
Doesn't deploying a 6to4 relay in the content provider network, along with IPv6 access to the content provider network, exactly meet this requirement? I agree that it is better if the mechanism can be installed in the eyeball ISP's network, but the fact is that the majority of content providers connect to the Internet via an ISP, so if there was a concerted effort to get content-hosting ISPs to install this mechanism, we would have solved much of this problem.
Designing a universally-general translation mechanism seems hard, and seems likely to suffer from many of the same problems as IPv4-IPv4 NAT; perhaps as an interim measure, however, for the millions of Internet users for whom the network mainly means 80/tcp, the mechanism doesn't have to be universally-general. Perhaps it just has to be good enough.
Agreed. Good enough might be a bit more than port 80, i.e. some more popular IM and P2P ports, but we already have all the pieces needed for this type of ALG to run on a Linux or BSD system. It's just a matter of someone putting together a good HowTo document which could be posted here <http://www.getipv6.info>.
Perhaps the assignment of IPv4 addresses to end users could become a premium service available to those who need them, leaving cheaper, IPv6-only service for everybody else.
I'm quite sure that this WILL happen within a year or so. Lots of ISPs have already gotten their IPv6 through the trial phase and already offer IPv6 access service, or are about to offer it. The difference between today, and 1995 when the Internet went exponential, is that in 1995 there were lots and lots of people with IPv4 networking experience, and IPv4 server experience. Out of that set of people, the early adopters and pioneers naturally formed a critical mass which created new ISPs and new Internet services. But today, we are still struggling to get enough people up to speed on IPv6. A lot of IPv4 people have so little IPv6 knowledge that we continually see the "Three Blind Men and an Elephant" syndrome. We have got to get beyond that which is why I urge everybody on this list to check this ARIN page http://www.getipv6.info/index.php/Educating_Yourself_about_IPv6 Either use it to further your own education, or add some advice/resource that will be of use to others. Every contribution of information, no matter how small, is useful. --Michael Dillon
On 3-Oct-2007, at 1038, <michael.dillon@bt.com> wrote:
However, if there was a reasonable translation mechanism available which allowed IPv6-only end systems to access IPv4-only content, I think the picture would look quite different.
Doesn't deploying a 6to4 relay in the content provider network, along with IPv6 access to the content provider network, exactly meet this requirement?
No. An end system who only has IPv6 addresses has no way to access IPv4-only content, regardless of whether the IPv6 address is constructed within 2002::/16. (and it's a bit of a stretch to imagine an end-system that has IPv4 close enough for a 6to4 prefix to be constructed, but far enough away for it not also to have an IPv4 address) Joe
On 3-Oct-2007, at 1038, <michael.dillon@bt.com> wrote:
However, if there was a reasonable translation mechanism available which allowed IPv6-only end systems to access IPv4-only content, I think the picture would look quite different.
Doesn't deploying a 6to4 relay in the content provider network, along with IPv6 access to the content provider network, exactly meet this requirement?
Oh, now that I actually *read* your text, you're talking about use of 6to4 in content providers, not end systems. Sorry for not noticing that when I replied just now :-) 6to4 (for content- or access-focussed networks) is surely a solution to the problem of "I have no good way to acquire IPv6 transit"; it's not a solution to the problem of deploying dual-stack across content- serving infrastructure, or the problem of there being near zero demand for IPv6 content, given that the number of existing IPv6-only clients is effectively zero. Joe
jabley@ca.afilias.info (Joe Abley) wrote:
6to4 (for content- or access-focussed networks) is surely a solution to the problem of "I have no good way to acquire IPv6 transit";
It solves another problem as well, like "I cannot go v6 to my servers because my load balancing and packet filtering black boxes don't do it yet". Elmar.
On 3-Oct-2007, at 1143, Elmar K. Bins wrote:
jabley@ca.afilias.info (Joe Abley) wrote:
6to4 (for content- or access-focussed networks) is surely a solution to the problem of "I have no good way to acquire IPv6 transit";
It solves another problem as well, like "I cannot go v6 to my servers because my load balancing and packet filtering black boxes don't do it yet".
I'm not sure how it solves that problem. 6to4 is not a translation mechanism -- it's a tunnelling mechanism. 6to4 does not provide any way for an IPv4-only host to talk to an IPv6-only host. In order to make use of 6to4, surely servers and load balancers still need to support IPv6 -- they just get loaded with addresses covered by a 6to4 prefix rather than a prefix assigned by an RIR or an IPv6 transit provider. Joe
It solves another problem as well, like "I cannot go v6 to my servers because my load balancing and packet filtering black boxes don't do it yet".
For this you need an ALG. This could be something like Squid on a box with both v6 and v4 interfaces. Basically, we now have such fast servers available with such high-speed networking, that anybody can build whatever middle-box they need using Linux and BSD. Ten years or so ago this was not nearly so easy to do which is why vendors stepped in with their blackbox products. But today, the situation is different. If the vendors are lagging behind, cut them out of the equation. Eventually new vendors will step up to the plate and you may decide to replace your home-built boxes with something commercial at around the time IPv6 traffic growth goes exponential. Or maybe you will follow Google's example and stick with the commodity hardware and tweak your software package into a well-opiled machine.
In order to make use of 6to4, surely servers and load balancers still need to support IPv6 -- they just get loaded with addresses covered by a 6to4 prefix rather than a prefix assigned by an RIR or an IPv6 transit provider.
IPv6 transition has a lot more wrinkles than just choosing which one of the IETF transition mechanisms is your favorite. --Michael Dillon
Re Joe, jabley@ca.afilias.info (Joe Abley) wrote:
6to4 (for content- or access-focussed networks) is surely a solution to the problem of "I have no good way to acquire IPv6 transit";
It solves another problem as well, like "I cannot go v6 to my servers because my load balancing and packet filtering black boxes don't do it yet".
I'm not sure how it solves that problem. 6to4 is not a translation mechanism -- it's a tunnelling mechanism. 6to4 does not provide any way for an IPv4-only host to talk to an IPv6-only host.
I was referring to a proxying service...see Michael's post for the details ;-) Yours, Elmar.
On 10/3/07, michael.dillon@bt.com <michael.dillon@bt.com> wrote:
However, if there was a reasonable translation mechanism available which allowed IPv6-only end systems to access IPv4-only content, I think the picture would look quite different.
Doesn't deploying a 6to4 relay in the content provider network, along with IPv6 access to the content provider network, exactly meet this requirement?
Michael, Not in any way, shape or form, no. 6to4 allows folks whose upstream provider is IPv4 only to connect their IPv6 hosts to other IPv6 hosts via IPv6. It does exactly that and nothing else. If you run a web site and only have IPv6 access via 6to4, you SHOULD NOT publish a AAAA record. 6to4 has very few gateways and they get clogged at various times of the day. If you publish a AAAA record, every user who has IPv6 will first try to connect to you via IPv6 and experience a -long- delay.
Perhaps the assignment of IPv4 addresses to end users could become a premium service available to those who need them, leaving cheaper, IPv6-only service for everybody else.
I'm quite sure that this WILL happen within a year or so. Lots of ISPs have already gotten their IPv6 through the trial phase and already offer IPv6 access service, or are about to offer it.
If you care to wager, I'll take some of that action. Without a relatively transparent mechanism for IPv6-only hosts to access IPv4-only sites this isn't going to happen. We don't have such a mechanism built and won't have it deployed in 12 months. Regards, Bill Herrin -- William D. Herrin herrin@dirtside.com bill@herrin.us 3005 Crane Dr. Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
If you run a web site and only have IPv6 access via 6to4, you SHOULD NOT publish a AAAA record. 6to4 has very few gateways and they get clogged at various times of the day. If you publish a AAAA record, every user who has IPv6 will first try to connect to you via IPv6 and experience a -long- delay.
This is precisely why someone else on the list suggested that the content provider should run their own 6to4 relay and anounce 2002::/16 to their IPv6 peers. That way, the IPv6 packets take the direct IPv6 route to the content provider, and the IPv4 path is just a stub in the content provider's network. Admittedly, if the IPv6 path itself has issues due to poor peering, poor bandwidth, neglected routing, that will rear its ugly head.
If you care to wager, I'll take some of that action. Without a relatively transparent mechanism for IPv6-only hosts to access IPv4-only sites this isn't going to happen. We don't have such a mechanism built and won't have it deployed in 12 months.
What about these two? http://www.getipv6.info/index.php/Transitioning:_6to4 http://www.getipv6.info/index.php/Transitioning:_NAT-PT Have you tried both of these yourself? --Michael Dillon
On 10/3/07, michael.dillon@bt.com <michael.dillon@bt.com> wrote:
If you care to wager, I'll take some of that action. Without a relatively transparent mechanism for IPv6-only hosts to access IPv4-only sites this isn't going to happen. We don't have such a mechanism built and won't have it deployed in 12 months.
What about these two? http://www.getipv6.info/index.php/Transitioning:_6to4
Michael, As mentioned, 6to4 doesn't do what you seem to think it does. Its not a solution to the problem of IPv6 endpoints trying to talk to IPv4 endpoints.
Looks interesting. There's some version 0.4 user-space software for Linux which claims to do it and Cisco claims to do it in IOS 12.4 advanced enterprise. Let me know how it works out for you when you try it in "many to one" mode. That is, many IPv6 addresses behind 1 IPv4 address, what Cisco still insists on calling port address translation. Regards, Bill Herrin -- William D. Herrin herrin@dirtside.com bill@herrin.us 3005 Crane Dr. Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
What about these two? http://www.getipv6.info/index.php/Transitioning:_6to4
Michael,
As mentioned, 6to4 doesn't do what you seem to think it does. Its not a solution to the problem of IPv6 endpoints trying to talk to IPv4 endpoints.
I see that you did not change anything on that page. Specifically what is wrong with the wording below? --- This is a transition mechanism in which the user configures a 6to4 client in their PC or home gateway. The 6to4 client requests dynamic tunnels from a 6to4 server which is found via the anycast address prefix 192.88.99.0/24 allocated in RFC 3068. This tunnel then attaches the IPv4 host to the IPv6 network using the IPv6 address 2002:V4ADDR::/48. The mechanism is documented in RFC 3056. ISPs can improve connectivity for their customers who are currently running IPv6 on their PCs by setting up a 6to4 relay. This avoids the increased network latency caused by a trombone path to the IPv6 destination through a distant 6to4 relay. In addition, a content provider can also add IPv6 access to their services by configuring 6to4 on their network. Again, by shortening the routing taken by one of the protocols, you ensure that there is no tromboning of the path and network latency is close to the minimum possible. ---
Looks interesting. There's some version 0.4 user-space software for Linux which claims to do
That's what this part of the page refers to: Guide to Building a Linux IPv6 Router with NAT-PT Good Howto document for setting up your own lab or home trial of NAT-PT
it and Cisco claims to do it in IOS 12.4 advanced enterprise.
You know, you could have added that to the page yourself. In any case, I added a pointer to a Cisco product brief that mentions they have upgraded NAT-PT to CEF in 12.4. --Michael Dillon
On 3-Oct-2007, at 1907, <michael.dillon@bt.com> wrote:
I see that you did not change anything on that page. Specifically what is wrong with the wording below? --- This is a transition mechanism in which the user configures a 6to4 client in their PC or home gateway. The 6to4 client requests dynamic tunnels
(not quite right; the client doesn't actually request anything)
from a 6to4 server which is found via the anycast address prefix 192.88.99.0/24 allocated in RFC 3068.
(most 6to4 implementations allow a relay router to be configured as an alternative to the RFC 3068 well-known relay router address. That address is exactly 192.88.99.1, incidentally; it's not something that needs to be found)
This tunnel then attaches the IPv4 host to the IPv6 network using the IPv6 address 2002:V4ADDR::/48. The mechanism is documented in RFC 3056.
ISPs can improve connectivity for their customers who are currently running IPv6 on their PCs by setting up a 6to4 relay. This avoids the increased network latency caused by a trombone path to the IPv6 destination through a distant 6to4 relay.
(for an ISP's customers to find that relay it either needs to be explicitly configured in their client stacks, or it needs to be numbered 192.88.99.1 and the clients need to use the RFC 3068 address)
In addition, a content provider can also add IPv6 access to their services by configuring 6to4 on their network
(... and configuring all the servers and related infrastructure responsible for those services to use IPv6, using a 6to4 prefix. Note that this is not particularly different from any other kind of IPv6 transit a content provider might decide to arrange.)
. Again, by shortening the routing taken by one of the protocols,
(shortening the IPv4 path over which the tunnel is provisioned is clearer; I'm not sure in general what "shortening the routing" means)
you ensure that there is no tromboning of the path and network latency is close to the minimum possible.
I did not change anything on that page, either. For the record, that's because I have a screaming two-year-old trying to use me as a climbing wall right now. Joe
I did not change anything on that page, either. For the record, that's because I have a screaming two-year-old trying to use me as a climbing wall right now.
My 10 month-old is soundly sleeping right now so I incorporated your suggestions into the page. --Michael Dillon
On 4/10/2007, at 12:24 PM, <michael.dillon@bt.com> <michael.dillon@bt.com> wrote:
I did not change anything on that page, either. For the record, that's because I have a screaming two-year-old trying to use me as a climbing wall right now.
My 10 month-old is soundly sleeping right now so I incorporated your suggestions into the page.
Michael, It would also be worth noting that 6to4 <-> 6to4 goes direct over IPv4 - not through 192.88.99.1 (or whatever other relay you've chosen). It's truely stateless, and the concept of client/server is misleading - when a 6to4 router transmits an IPv6 packet over IPv4, all it's doing is looking at the next-hop to reach that v6 address, and taking bytes 3-6 from the IPv6 address and using that as the destination IPv4 address. In most cases, the next-hop for 2000::/3 is set to 2002:192.88:99.1:: So, content providers would be wise to route 2002::/16 at a 6to4 router they run in-house, so that at least the return path to the 'customer'/'client'/'end user of their content services' goes over a more-or-less identical path as it would if it were IPv4. The content provider can run this on any public IPv4 address, and packets aren't going to be coming back that way. (RFC1918 would work, but you might be blocked by bogon RPFs in some cases). Teredo is really good in this sense - your client detects which relay Teredo packets come from, and caches that as the best relay to use to talk to that host. So, you get close-to-IPv4-path for both forward and reverse. So, content providers should run Teredo relays also - their over- Teredo performance will be almost the same as their over-IPv4 performance. There should be no reason that 6to4 can't do the same thing, I suppose. -- Nathan Ward
On 10/3/07, michael.dillon@bt.com <michael.dillon@bt.com> wrote:
As mentioned, 6to4 doesn't do what you seem to think it does. Its not a solution to the problem of IPv6 endpoints trying to talk to IPv4 endpoints.
I see that you did not change anything on that page. Specifically what is wrong with the wording below?
Michael, I could quibble about the description that it "requests dynamic tunnels." Nothing is requested. Its comepletely stateless. There's no setup or teardown. It just sends packets that get encapsulated and decapsulated as they're received. But the description is not unreasonable. Where in the description you posted did you read anything that suggests it allows IPv6 endpoints to communicate with IPv4 endpoints?
Looks interesting. There's some version 0.4 user-space software for Linux which claims to do You know, you could have added that to the page yourself. In any case, I added a pointer to a Cisco product brief that mentions they have upgraded NAT-PT to CEF in 12.4.
I generally wait until I've seen something actually work before documenting how it works. I haven't dug too deep into NAT-PT, but an obvious question comes to mind: Why would an ISP deliver an IPv6-only connection plus NAT-PT (and all the likely problems) with a surcharge for IPv4 instead of delivering RFC1918 IPv4 + NAT with a surcharge for routable IPv4? Without looking decades ahead to the waning days of IPv4 when its desirable to minimize the IPv4 footprint in your network, I haven't been able to come up with an answer. When I do, I'll take another look at NAT-PT. Regards, Bill Herrin -- William D. Herrin herrin@dirtside.com bill@herrin.us 3005 Crane Dr. Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
I haven't dug too deep into NAT-PT, but an obvious question comes to mind: Why would an ISP deliver an IPv6-only connection plus NAT-PT (and all the likely problems) with a surcharge for IPv4 instead of delivering RFC1918 IPv4 + NAT with a surcharge for routable IPv4?
Why is it an either/or situation? Given the fact that PC's have supported IPv6 for quite a while now, an IPv6 Internet access service is workable, *IF* an ISP can support something that allows the IPv6 user to get to the IPv4 Internet. That is a transition product that will reduce the requirement for IPv4 addresses at the same time as it enables the ISP to market themselves as "Ready for the Future" or whatever. Obviously, the ISP can offer the same old IPv4 service with potentially, double NAT but then they are just making do until some future point in time when they have to deal with IPv6. At that point in time, they may need to offer the NAT-PT solution which means they need to learn about it, do some trials, etc. I'm not suggesting that people should rush out and make dumb business decisions to offer IPv6 services today. I *AM* suggesting that people need to start educating themselves on the intricacies of IPv6, trialing IPv6 in a lab environment, and planning how they will introduce IPv6 services WHEN IT MAKES BUSINESS SENSE TO DO SO. IPv4 exhaustion is close enough that people can't afford to keep their heads in the sand any longer. --Michael Dillon
On 4/10/2007, at 11:07 PM, <michael.dillon@bt.com> <michael.dillon@bt.com> wrote:
I haven't dug too deep into NAT-PT, but an obvious question comes to mind: Why would an ISP deliver an IPv6-only connection plus NAT-PT (and all the likely problems) with a surcharge for IPv4 instead of delivering RFC1918 IPv4 + NAT with a surcharge for routable IPv4?
Why is it an either/or situation? Given the fact that PC's have supported IPv6 for quite a while now
<crazy rambling> This last sentence (fragment) with NAT-PT above it made me ponder a bit. NAT-PT and whatever other solutions we're considering are all aiming to give transparent access to hosts on the IPv4 network from hosts on the IPv6 network (or vice-versa). It probably doesn't have to be so transparent - why couldn't there be some kind of NATv4-over-v6 hack that let it happen? Would GRE (over v6) with DHCP, and NAT on the concentrator work? Maybe L2TP (over v6) or something? OSes don't support this now (as I just pulled it out of thin air), but there's no reason they couldn't be made to, or something like it. Upside down Teredo + NAT. Sure it means we have to have NATs in the way - but as many people have suggested, NAT is an existing issue for most applications, and they work around it just fine. The advantage of doing this as opposed to handing customers' CPEs RFC1918 addresses is, they can do end-to- end over v6 if they want to. </crazy rambling> One does wonder if doing IPv6 and RFC1918 IPv4 at the same time might be easier. Do the IPv6 PPP things let you run IPv6 and IPv4 at the same time? (Maybe not RFC1918, maybe take a single non-RFC1918 /24 and assign those addresses to customers, and then re-use that /24 many many times, each behind a different non-RFC1918 address. To avoid address conflicts with people who NAT their address, etc.) The difference between the two things above is that the former is single NAT, the latter is double. The former is much more complicated, though. -- Nathan Ward
On Tue, 2 Oct 2007 23:20:54 -0400 "William Herrin" <herrin-nanog@dirtside.com> wrote:
On 10/2/07, Randy Bush <randy@psg.com> wrote:
During early phase of free pool exhaustion, when you can't deliver more IPv4 addresses to your customers you lose the customer to a hosting provider who still has addresses left. So sorry. Those will be some nasty years. Unless you're Cogent, Level3 or one of the others sitting pretty on a /8. They'll be in phat city.
this is a very real and significant problem. a very small fraction of the arin membership holds the vast majority of the address space. it would be interesting to ask arin to give us the cdf of this.
<snip>
I'd love to have an Internet where all firewalls were packet filters. But that's not my call. That's the call of hundreds of thousands of network security officers who have NAT written in stone at the core of their security process. Tying NAT's abandonment to IPv6's deployment won't change their minds but it will doom IPv6.
The value of network perimeterisation as a security measure, of which NAT is a method, is being questioned significantly by network security people. The obvious example of why it is being questioned is when the CEO brings their laptop inside the "gooey" centre, bypassing the "hard shell" corporate firewalling/NAT box, and infecting all the devices on the corporate network with the malware they've caught from their home broadband connection. "The de-perimeterization solution Solution While traditional security solutions like network boundary technology will continue to have their roles, we must respond to their limitations. In a fully de-perimeterized network, every component will be independently secure, requiring systems and data protection on multiple levels, using a mixture of * encryption * inherently-secure computer protocols * inherently-secure computer systems * data-level authentication" http://www.opengroup.org/jericho/ Having found out about this project, I spoke to a friend of mine in the local state government (around 10 000+ public servants) i.e. not a big one, not a prominent one, and not likely to be a early adopter of different IT security models. They're moving to this model in the very near future, because they have to.
So if more addresses was "thoroughly mitigated by NAT", when were these problems that NAT creates fixed? http://www.cs.utk.edu/~moore/what-nats-break.html
Many of those never were meaningful problems and most of the rest have been obsoleted by the changing reality of network security on the Internet. Things like controlling the source port meant something once upon a time, but they have no place in a modern security infrastructure. That would be true with or without NAT.
The -real- problems with NAT can be summed up in two statements:
1. NAT makes it more difficult to engage in certain popular activities that strictly speaking are against the TOS.
2. NAT makes logging and accountability more difficult.
Regards, Bill Herrin
-- William D. Herrin herrin@dirtside.com bill@herrin.us 3005 Crane Dr. Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
-- "Sheep are slow and tasty, and therefore must remain constantly alert." - Bruce Schneier, "Beyond Fear"
On 10/3/07, Mark Smith <nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> wrote:
The value of network perimeterisation as a security measure, of which NAT is a method, is being questioned significantly by network security people.
Mark, The discussion at hand is whether the absence of NAT creates a drag on IPv6 deployment. and how much of a drag it creates. Your points about the relative merits of NAT as a security mechanism are entirely irrelevant to that discussion. On 10/3/07, Iljitsch van Beijnum <iljitsch@muada.com> wrote:
On 3-okt-2007, at 5:20, William Herrin wrote:
1. End the insanity of having software prefer IPv6 if available (AAAA records over A records).
Insanity?
Yes, Iljitsch, insanity. Trying IPv6 first is asking folks to disable it on their PCs the second or third time they can't get to a web site because the IPv6 path isn't working. Its also asking web site operators not to offer IPv6 addresses in the first place so as not to inconvenience folks who have Ipv6 turned on without a reliable connection. That's counterproductive. We want people on both sides to turn it on and leave it on. We don't need every PC in the world to be a beta tester for our new Internet. We do need them to turn it on. Regards, Bill -- William D. Herrin herrin@dirtside.com bill@herrin.us 3005 Crane Dr. Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Wed, 3 Oct 2007, Mark Smith wrote:
The value of network perimeterisation as a security measure, of which NAT is a method, is being questioned significantly by network security people. The obvious example of why it is being questioned is when the CEO brings their laptop inside the "gooey" centre, bypassing the "hard shell" corporate firewalling/NAT box, and infecting all the devices on the corporate network with the malware they've caught from their home broadband connection.
Universities have understood this for many years, with the termly influx of infected student computers. Tony. -- f.a.n.finch <dot@dotat.at> http://dotat.at/ IRISH SEA: SOUTHERLY, BACKING NORTHEASTERLY FOR A TIME, 3 OR 4. SLIGHT OR MODERATE. SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.
Is anyone at Level3 who is familiar with IPv6, or anyone who is a Level3 IPv6 customer lurking here? We are a Level3 BGP customer and our contacts are giving us a deer-in-the-headlights stare when we want to bring up our /32, claiming that they don't do IPv6 at all. Not native, not tunneled, zip, nada. Yet, I see lots of AS3356 in the ipv6 routing tables, and there's this from three years ago... http://nanog.org/mtg-0510/bamford.html -- Jay Hennigan - CCIE #7880 - Network Engineering - jay@impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV
On Tue Jun 24, 2008 at 11:37:57AM -0700, Jay Hennigan wrote:
Is anyone at Level3 who is familiar with IPv6, or anyone who is a Level3 IPv6 customer lurking here? We are a Level3 BGP customer and our contacts are giving us a deer-in-the-headlights stare when we want to bring up our /32, claiming that they don't do IPv6 at all. Not native, not tunneled, zip, nada.
We've recently brought up IPv6 with Level3. It's done as an IPv6IP tunnel to their nearest IPv6 router. I may be able to dig out the form you need... Simon -- Simon Lockhart | * Sun Server Colocation * ADSL * Domain Registration * Director | * Domain & Web Hosting * Internet Consultancy * Bogons Ltd | * http://www.bogons.net/ * Email: info@bogons.net *
Level 3 provides best effort IPv6 support with no SLA to current Internet customers. As mentioned IPv6 is currently being provided via tunnels to the customer's existing router. There is a simple service agreement addendum and form to fill out for relevant config bits. Sorry you get such a response from people that should know. *sigh* regards -Craig (Level 3 architecture) * Jay Hennigan was thought to have said:
Is anyone at Level3 who is familiar with IPv6, or anyone who is a Level3 IPv6 customer lurking here? We are a Level3 BGP customer and our contacts are giving us a deer-in-the-headlights stare when we want to bring up our /32, claiming that they don't do IPv6 at all. Not native, not tunneled, zip, nada.
Yet, I see lots of AS3356 in the ipv6 routing tables, and there's this from three years ago...
At 11:57 AM -1000 10/2/07, Randy Bush wrote:
this is a very real and significant problem. a very small fraction of the arin membership holds the vast majority of the address space. it would be interesting to ask arin to give us the cdf of this.
I think CAIDA already did some similar analysis: http://www.caida.org/research/id-consumption/ipv4/concentration.xml Is there additional data that would help? /John
On Tue, 2 Oct 2007, William Herrin wrote:
What should you do about it? Buy stock.
What's your crystal ball say? Which ones and when? :)
And make no mistake: it will drag on and on. Even when everybody is well and truly out, there are a heck of a lot of addresses that can be reclaimed in dialup pools, residential DSL pools and other uses retroactively deemed wasteful by converting them to NAT.
I suppose that's a likely last resort. Reduce, reuse, recycle. If you don't have large dial pools to scavenge, you're SOL? AFAIK, this [NATing consumer access] is already being done by some of the larger providers in Europe. I wonder how the heck they deal with abuse issues. i.e. When complaints come in about abusive/illegal activity from a NAT outside IP, how do you know which inside IP customer is to blame? Keep extensive netflow data generated by the NAT router?
IPv4 forever. One possible price for failing to deliver an IPv6 that customers want today.
Is it really that they don't want it or that they just don't care...as long as the web works, email works, and they can do whatever else they generally do online? A massive installed generally apathetic base is an awful lot of momentum to overcome. And last I read, even that ipv6 free porn thing was vaporware. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On Tue, 2 Oct 2007 12:42:23 -0400 "William Herrin" <herrin-nanog@dirtside.com> wrote:
On 10/2/07, Brian Raaen <braaen@zcorum.com> wrote:
Actually, a better way to push IPv6 is make users want it and feel like they are missing out if they don't have it. I campaign with some kind of slogan like 'got IPv6' or "I've got ultra high tech IPv6 for my internet and you don't" with a web url like www.getipv6.com (oops, some domain squatter already registered it).
Brian,
I offer you two words: Ford Edsel.
It doesn't matter how clever you make the marketing campaign if on finding out what the product actually is the customers decide they don't want it.
This all boils down to simple economics.... supply and demand.
As far as I can tell, IPv6 is at least theoretically capable of offering exactly two things that IPv4 does not offer and can't easily be made to offer:
1. More addresses. 2. Provider independent addresses
At the customer level, #1 has been thoroughly mitigated by NAT, eliminating demand. Indeed, the lack of IPv6 NAT creates a negative demand: folks used to NAT don't want to give it up.
Those people don't know any better, because they probably haven't used a NAT free Internet. Most North Koreans probably aren't asking for democracy either. Have you used a NAT free Internet? So if more addresses was "thoroughly mitigated by NAT", when were these problems that NAT creates fixed? http://www.cs.utk.edu/~moore/what-nats-break.html
This community (network operators) has refused to permit #2, even to the extent that its present in IPv4, eliminating that source of demand as well.
Regards, Bill Herrin
-- William D. Herrin herrin@dirtside.com bill@herrin.us 3005 Crane Dr. Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
-- "Sheep are slow and tasty, and therefore must remain constantly alert." - Bruce Schneier, "Beyond Fear"
Mark, On Oct 2, 2007, at 3:52 PM, Mark Smith wrote:
As far as I can tell, IPv6 is at least theoretically capable of offering exactly two things that IPv4 does not offer and can't easily be made to offer:
1. More addresses. 2. Provider independent addresses
At the customer level, #1 has been thoroughly mitigated by NAT, eliminating demand. Indeed, the lack of IPv6 NAT creates a negative demand: folks used to NAT don't want to give it up.
Those people don't know any better, because they probably haven't used a NAT free Internet.
It isn't that simple. The fact that NAT exists and is seen as useful by many people (whether or not they are even aware of it) means services and applications need to be aware of it. You cannot simply wave a magic wand and say "there shall be no NAT". Even if there weren't NAT, folks interested in security would argue and/or insist on stateful firewalls.
Have you used a NAT free Internet?
Yes, actually.
So if more addresses was "thoroughly mitigated by NAT", when were these problems that NAT creates fixed?
It would seem the market has determined that the issues Keith had concerns with were less important than the advantages NAT provided. And Beta was better than VHS, but VHS won. I will admit that at times it feels a bit like we're trying to push Super Beta. Regards, -drc
drc@virtualized.org (David Conrad) writes:
... You cannot simply wave a magic wand and say "there shall be no NAT". ...
actually, you can. see RFC 4966. don't be fooled by the title, it's not just damning NAT-PT, since it justifies doing so by stating that NAT is damned. (of course, waving a magic wand and saying something doesn't make it so.) -- Paul Vixie
On Tue, 2 Oct 2007 19:15:27 -0700 David Conrad <drc@virtualized.org> wrote:
Mark,
On Oct 2, 2007, at 3:52 PM, Mark Smith wrote:
As far as I can tell, IPv6 is at least theoretically capable of offering exactly two things that IPv4 does not offer and can't easily be made to offer:
1. More addresses. 2. Provider independent addresses
At the customer level, #1 has been thoroughly mitigated by NAT, eliminating demand. Indeed, the lack of IPv6 NAT creates a negative demand: folks used to NAT don't want to give it up.
Those people don't know any better, because they probably haven't used a NAT free Internet.
It isn't that simple. The fact that NAT exists and is seen as useful by many people (whether or not they are even aware of it) means services and applications need to be aware of it.
This is a hidden cost of NAT. Why hack many applications to work around a network layer problem ? The best place to fix a problem is where it actually exists. The problem NAT tries to solve, but doesn't solve very well (see the earlier list), exists in the network layer. IPv6 fixes the network layer problem that IPv4 has, and it fixes it better than NAT does. IPv6 isn't perfect, but nothing ever is.
You cannot simply wave a magic wand and say "there shall be no NAT".
Of course you can't. If I had that wand I'd have already waved it years ago! I think there has to be a "compelling" reason to adopt something. I think the thing that will compel people to move to IPv6 will be the eventual and inevitable squeeze on IPv4 public addresses. At a certain point I think people will ask themselves "why are we going to such effort (and maybe expense) to get a few IPv4 public addresses when we could move to IPv6 and immediately get millions for the same or less effort and cost?" The fact that nearly most of their networking infrastructure will likely to have been IPv6 enabled in the preceeding years will help it be compelling. (We got a new colour photocopier at work today - it's IPv6 capable. None of us techs asked for it as a feature, and I don't think any of us actually got a look at the datasheet for it before it was bought. The first we knew of it supporting IPv6 was when the photocopier tech asked us if we wanted it enabled. I suspect the photocopier tech didn't even quite appreciate what he was asking. To him, it was probably just another photocopier networking option that the customer might want turned on.)
Even if there weren't NAT, folks interested in security would argue and/or insist on stateful firewalls.
Who said anything about getting rid of stateful firewalls? I didn't and never have.
Have you used a NAT free Internet?
Yes, actually.
So if more addresses was "thoroughly mitigated by NAT", when were these problems that NAT creates fixed?
It would seem the market has determined that the issues Keith had concerns with were less important than the advantages NAT provided.
I don't think the market was aware of the hidden costs of NAT. I wasn't in 1995 when I first learned of it, implemented it and recommended it as a solution. I, my employers and my customers over the years have since paid those hidden costs on a number of occasions, which caused me to start questioning why it was "such a great solution" when the limitations it imposes didn't exist in a NAT free Internet. I was fortunate enough to experience a few years of NAT free Internet before NAT came along. Even today, you look at current technical network training materials, when they describe NAT, very rarely do they list the draw backs. I happen to be currently reading the quite well known book, "Diffusion of Innovations". From what I've read the "market" doesn't seem to be all that good at selecting the best solution (Heard of 100baseVG aka. 100VG Anylan? Technically much better than 100BASE-T from what I remember, but even the technical field of networking didn't choose the best technical solution. For many years I've wondered why). The majority of it are followers who base their opinions on what others within the market/social system say. "Change Agents" introduce new innovations, and "Opinion Leaders" influence whether and how that innovation is diffused. I think the change agents were the NAT equipment vendors. With the Internet being a relatively new thing in the mid 90s, when NAT came along, the opinion leaders ended up just assuming that the change agents/vendors, who commonly knew far more about the Internet, were making good and trustworthy recommendations. Maybe even the change agents/vendors thought they were too, at the time. Regards, Mark. -- "Sheep are slow and tasty, and therefore must remain constantly alert." - Bruce Schneier, "Beyond Fear"
It isn't that simple. The fact that NAT exists and is seen as useful by many people (whether or not they are even aware of it) means services and applications need to be aware of it.
This is a hidden cost of NAT. Why hack many applications to work around a network layer problem ?
The best place to fix a problem is where it actually exists. The problem NAT tries to solve, but doesn't solve very well (see the earlier list), exists in the network layer. IPv6 fixes the network layer problem that IPv4 has, and it fixes it better than NAT does. IPv6 isn't perfect, but nothing ever is.
I think that you've misidentified where the problem really exists. I'd suggest that it exists at a higher layer. If I'm a resi broadband subscriber, and I buy an "Internet connection thingamajigger", I may want to hook up more than the one device I'm allowed, in a hypothetical IPv4- only world that works like the one we currently have. And yes, while SOME ISP's do allow you to obtain additional IP addresses, it is certainly not common, nor is it without a monthly cost. Smart end users WILL identify that things like "Internet Connection Sharing" or a NAT gateway will eliminate this cost. So, one of the real problems is that ISP's sell connections "for a single device" to end users. Another problem could be that these are dynamic IP, which makes ever less sense given the nature of always-on Internet access, and the increasing plethora of Internet-capable devices one finds in a home. I realize that these things have typically been differentiators in the service offerings of an ISP, but if you really want to be able to get rid of NAT and truly "go IPv6 native", you're going to have to get rid of the incentives to put a NAT device in, and give end users blocks of address space sufficient to the task. Most proponents of IPv6 seem to be operating under the assumption that an ISP will hand out a block (the latest I recall seeing is RFC 4779, which suggests a /64, IIRC). That would appear to be sufficient to the task, certainly. However, I am left wondering what is going to happen in the event that you're dealing with a service provider who really wants to spec out that a single client is allowed to attach? Because there's a loose correlation between the number of clients behind a connection and actual utilization, carriers have an incentive to limit this... To really encourage the avoidance of NAT, we really need to move to service models where Internet connection sharing is expected and allowed. Limited to within a household? Not technically possible, of course, but you can certainly /write/ such a restriction into the contract. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Thus spake "Daniel Senie" <dts@senie.com>
A number of people have bemoaned the lack of any IPv6-only killer-content that would drive a demand for IPv6. I've thought about this, and about the government's push to make IPv6 a reality. What occurred to me is there is a satellite sitting in storage that would provide such content:
http://en.wikipedia.org/wiki/Triana_(satellite)
Al Gore pushed for this satellite, Triana, to provide those on earth with a view of the planet among its scientific goals. The Republicans referred to it as an "overpriced screen saver," though the effect even of just the camera component on people's lives and how they treat the planet could be considerable.
By combining the launch of Triana with feeding the still images and video from servers only connected to native IPv6 bandwidth, the government would provide both a strong incentive for end users to want to move to IPv6, and a way to get the people of this planet to stop from time to time and ponder the future of the earth.
Here's a simple question that applies to every "killer app" that's been proposed for IPv6: if you're going to the trouble of making a killer app and giving/selling it to the public, why wouldn't you include support for IPv4? Virtually every "unique" feature of IPv6, except the number of bits in the address, has been back-ported to IPv4. There is simply no other advantage left, and thus no room for apps that "require" IPv6. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
At 08:04 PM 10/3/2007, Stephen Sprunk wrote:
Thus spake "Daniel Senie" <dts@senie.com>
A number of people have bemoaned the lack of any IPv6-only killer-content that would drive a demand for IPv6. I've thought about this, and about the government's push to make IPv6 a reality. What occurred to me is there is a satellite sitting in storage that would provide such content:
http://en.wikipedia.org/wiki/Triana_(satellite)
Al Gore pushed for this satellite, Triana, to provide those on earth with a view of the planet among its scientific goals. The Republicans referred to it as an "overpriced screen saver," though the effect even of just the camera component on people's lives and how they treat the planet could be considerable.
By combining the launch of Triana with feeding the still images and video from servers only connected to native IPv6 bandwidth, the government would provide both a strong incentive for end users to want to move to IPv6, and a way to get the people of this planet to stop from time to time and ponder the future of the earth.
Here's a simple question that applies to every "killer app" that's been proposed for IPv6: if you're going to the trouble of making a killer app and giving/selling it to the public, why wouldn't you include support for IPv4?
The US Government has stated an intention to have all equipment supplied to it be capable of IPv6, and networks to run IPv6. (http://www.whitehouse.gov/omb/egov/b-1-information.html#IPV6) That being the case, this would be an opportunity for the government to use something to push that goal along. Clearly there's nothing about a screen saver image from L1 that requires IPv6, but the government owns Triana, and the government wants to push IPv6 (OK, so the government also pushed OSI in the form of GOSIP, and we all know how well that worked out).
Virtually every "unique" feature of IPv6, except the number of bits in the address, has been back-ported to IPv4. There is simply no other advantage left, and thus no room for apps that "require" IPv6.
Agree all the way around. There's no technological reason to tie these items together. There is a political reason, as it fits with the agenda of the government to push IPv6 development and deployment. How the government would prevent proxying of this content into IPv4, well, that's another matter. Perhaps the IPv6 evangelists will be able to convince Congress to outlaw that at the same time as they approve the launch of Triana and provide for the server farm to serve the images. BTW, thanks for bringing this thread back to the question of creating demand for IPv6. There's plenty of anti-NAT activity on other threads. Some constructive discussion over ways to create incentives to deploy IPv6 is worthwhile. The most common argument for deployment of IPv6 is fear, as in "the sky is falling." Yeah, we all heard that, and have for a decade. Got it. Now, is there some POSITIVE reason to push IPv6? Fear is not a positive force. Dan
On Wed, 3 Oct 2007, Daniel Senie wrote:
BTW, thanks for bringing this thread back to the question of creating demand for IPv6. There's plenty of anti-NAT activity on other threads. Some constructive discussion over ways to create incentives to deploy IPv6 is worthwhile. The most common argument for deployment of IPv6 is fear, as in "the sky is falling." Yeah, we all heard that, and have for a decade. Got it. Now, is there some POSITIVE reason to push IPv6? Fear is not a positive force.
Ok, I'll bite and throw out a wacky idea I've been mulling over. As the data at http://bgp.he.net/ipv6-progress-report.cgi shows for the IPv6 and IPv4 nameserver tests, some of the time IPv6 connectivity is *faster* than IPv4 connectivity (66 out of 264 test cases), because of network topology differences due to different peering and transit relationships between IPv4 and IPv6. So you could write a download accelerator for your browser that checked IPv6 vs IPv4 connectivity and used whichever was faster. With only 3 percent of neworks running IPv6 this idea is a little early, still it would be a hilarious browser plug-in. You could imagine it might even have a little "IPv6 accelerator" icon that shows up in your status bar when you've switched on the nitro. (hehehe, shaving off that extra few ms of latency, yo!) Mike. +----------------- H U R R I C A N E - E L E C T R I C -----------------+ | Mike Leber Wholesale IPv4 and IPv6 Transit 510 580 4100 | | Hurricane Electric Web Hosting Colocation AS6939 | | mleber@he.net http://he.net | +-----------------------------------------------------------------------+
On Wed, Oct 03, 2007, Mike Leber wrote:
So you could write a download accelerator for your browser that checked IPv6 vs IPv4 connectivity and used whichever was faster.
With only 3 percent of neworks running IPv6 this idea is a little early, still it would be a hilarious browser plug-in. You could imagine it might even have a little "IPv6 accelerator" icon that shows up in your status bar when you've switched on the nitro.
(hehehe, shaving off that extra few ms of latency, yo!)
The evil bastard in me wonders if developers may focus on speeding up IPv6 processing latency vs IPv4 for things like games on desktops, and let the gamers drive the IPv6 adoption. If you're evil you could envision silicon that did ipv4 vs ipv6 packet identification (via ethertype for NICs?) and then "handle" ipv6 packets with less latency. Ok, thats enough humour for this afternoon. Adrian
On Thu, October 4, 2007 6:49 am, Mike Leber wrote:
As the data at http://bgp.he.net/ipv6-progress-report.cgi shows for the IPv6 and IPv4 nameserver tests, some of the time IPv6 connectivity is *faster* than IPv4 connectivity (66 out of 264 test cases), because of network topology differences due to different peering and transit relationships between IPv4 and IPv6.
Just as a odd data point, I see this for the only IPv6 test-bed I have available now, including tunnels. Home DSL (UK) -> EU tunnel broker -> IPv6 cloud -> US tunnel broker -> hosted server (California) is consistently 10-20ms lower than home -> IPv4 upstream -> IPv4 cloud -> server. Regards, Tim.
participants (26)
-
Adrian Chadd -
Brian Raaen -
Craig Pierantozzi -
Daniel Senie -
David Conrad -
Elmar K. Bins -
Florian Weimer -
Iljitsch van Beijnum -
Jay Hennigan -
Joe Abley -
Joe Greco -
John Curran -
Jon Lewis -
Lucy Lynch -
Mark Smith -
michael.dillon＠bt.com -
Mike Leber -
Nathan Ward -
Paul Vixie -
Randy Bush -
Seth Mattinen -
Simon Lockhart -
Stephen Sprunk -
Tim Franklin -
Tony Finch -
William Herrin