RE: [address-policy-wg] IPv6 allocations for 6RD
All, My main goal with supporting 6rd is to see IPv6 deployed by Service Providers, preferably before the onslaught of CGNs leading to RFC1918 Private IPv4 as the new default Internet Access. As such, the fact that we are even having this conversation is rather encouraging. At the moment, 6rd accounts for the largest residential IPv6 Internet deployment to date. It's natural that some SPs are interested in replicating what has shown to work well for a neighboring SP. Not all of them want to go this route, but some do, and I’m thrilled as this very likely means a sooner IPv6 deployment in the world (at least among those SPs who see 6rd as their most viable alternative). I want to underscore here that we are not talking about forever allocating space away to a transition mechanism as was done with the /16 for 6to4, or the /32 for Teredo. Those address spaces will never be used for anything else, ever. The 6rd-related requests are, of course, for allocations to SPs that actually want to deploy IPv6 to their subscriber population in relative short order. One day, I hope that 6rd is not necessary for IPv6 deployment, but for the moment I'm firmly convinced that it is in a number of cases. Perhaps the WG could consider a temporary "early adopter" 6rd policy... e.g., for the next 3-5 years, those SPs that can show that native service is not economically viable for them, but commit that they can and will deploy with 6rd, will be allocated space necessary to get off the ground. At the end of this period, the WG could re-evaluate whether to abandon the more liberal policy in light of the ability to deploy natively at that time. As for the status of 6rd in the IETF, draft-townsley… is expired, and has been replaced by the Softwires Working Group document draft-ietf-softwire-ipv6-6rd-01.txt. Many Thanks, - Mark
* Mark Townsley
I want to underscore here that we are not talking about forever allocating space away to a transition mechanism as was done with the /16 for 6to4, or the /32 for Teredo. Those address spaces will never be used for anything else, ever.
Free has 2a01:0e00::/26 allocated. Of this only one /28 is in use for 6rd (2a01:0e30::/28), the rest is network infrastructure and reserved for future use. To me that seems like a lot for even a big SP like Free. Perhaps allocation requests from Swisscom and other SPs that wants to use 6rd as a transition mechanism, could be handled like this instead: - A normal allocation of /32 (or whatever Swisscom would normally qualify for when disregarding 6rd) is granted. - A transition/6rd-only allocation of /28 valid only for as long as 6rd remains in use, is also granted. Later, when Swisscom complete their transition to native v6 and no longer use 6rd, the /28 can be easily reclaimed. Would something like this work for you, Jan? The two allocations could possibly be from the same /27 so that they can be announced as an aggregate, but in that case the unallocated space in that /27 would of course be unavailable for allocation to other SPs, and then there's always the chance that it will end up in use anyway (whether maliciously or not), so I'm not sure if would be worth it. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27
* Mark Townsley wrote:
As for the status of 6rd in the IETF, draft-townsley… is expired, and has been replaced by the Softwires Working Group document draft-ietf-softwire-ipv6-6rd-01.txt.
I still reading this draft and try hard to find the benefit over announcing more specific routes in 2002::/16. Can you please hit me into the right direction?
Perhaps the WG could consider a temporary "early adopter" 6rd policy... e.g., for the next 3-5 years, those SPs that can show that native service is not economically viable for them, but commit that they can and will deploy with 6rd, will be allocated space necessary to get off
I oppose handing out huge amounts of address space which is guaranteed to fit into a single prefix when removing protocol inherent holes. I'd favor inserting RPSL route objects below 2002::/16 by the RIR based on the corresponding IPv4 allocations. This process can be requested by the LIR and has a limited timescale (multiple renew allowed).
Hi, On Thu, Nov 26, 2009 at 12:17:13PM +0000, Lutz Donnerhacke wrote:
* Mark Townsley wrote:
As for the status of 6rd in the IETF, draft-townsley??? is expired, and has been replaced by the Softwires Working Group document draft-ietf-softwire-ipv6-6rd-01.txt.
I still reading this draft and try hard to find the benefit over announcing more specific routes in 2002::/16.
Can you please hit me into the right direction?
Use of the same (known and working) technology without extra global routes (assuming that the ISP has a "normal" prefix in addition to the prefix used for 6rd) and without the mess created by not-really-working 6to4 relays and asymmetric paths. With 2002:: in use inside an ISP, packets from 6to4 aware peer hosts out in the world will be encapsulated into IPv4 at the sending host, and then travel over potentially broken IPv4 paths, instead of travelling natively IPv6 up to the ISPs relay... Gert Doering -- just argueing technology -- Total number of prefixes smaller than registry allocations: 144438 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
* Gert Doering wrote:
Use of the same (known and working) technology without extra global routes (assuming that the ISP has a "normal" prefix in addition to the prefix used for 6rd) and without the mess created by not-really-working 6to4 relays and asymmetric paths.
You are suggesting to assign a new IP prefix every time, some implemtations out there fucked up? If you can't live with anycast, go and announce our unicast more specific!
With 2002:: in use inside an ISP, packets from 6to4 aware peer hosts out in the world will be encapsulated into IPv4 at the sending host, and then travel over potentially broken IPv4 paths, instead of travelling natively IPv6 up to the ISPs relay...
No, they don't otherwise firewalls would not work with IPv6 and 6to4 at all. Any nativly IPv6 connected host respond to any request from IPv6 addresses using IPv6. I see you point, that more specifics of 2002::/16 are disallowed by RFC3056, but this can easily be changed. 6rd uses the same way to modify RFC3056: It requires a huge parallel prefix (and route) per ISP. In order to overcome the situation I submitted a draft to the IETF. http://www.ietf.org/id/draft-donnerhacke-softwire-ipv6-6to4-00.txt Have fun.
Hi,
I see you point, that more specifics of 2002::/16 are disallowed by RFC3056, but this can easily be changed. 6rd uses the same way to modify RFC3056: It requires a huge parallel prefix (and route) per ISP.
In order to overcome the situation I submitted a draft to the IETF. http://www.ietf.org/id/draft-donnerhacke-softwire-ipv6-6to4-00.txt
Yeah, nice idea. Why not have router implementations do that by default? We just have hit 300k routes in IPv4, I see no reason why we should not have that amount in IPv6 as well. Bernhard
Hi, On Thu, Nov 26, 2009 at 04:53:22PM +0000, Lutz Donnerhacke wrote:
I see you point, that more specifics of 2002::/16 are disallowed by RFC3056, but this can easily be changed. 6rd uses the same way to modify RFC3056: It requires a huge parallel prefix (and route) per ISP.
Well, the point is that 6rd does *not* require another prefix per ISP, if done within their LIR allocation. As opposed to announce umpteen IPv4 prefixes that this LIR holds as more-specifics under 2002::/16. A second prefix for 6rd is only required under the proposal that a LIR could get a second (larger) temporary prefix to deploy IPv6 via 6rd, and later return that when all the network has migrated to "native" internal IPv6. I'm not convinced that this is a workable approach, as the criteria for "this has to be returned, if ...!" are usually quite hard to judge from the outside, and people tend to forget about good intentions... Gert Doering -- technologist -- Total number of prefixes smaller than registry allocations: 144438 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
I read in the paragraph 4 (IPv6 Policy Principles) of the IPv6 Address Allocation and Assignment Policy : --------------- 4.4. Consideration of IPv4 infrastructure Where an existing IPv4 service provider requests IPv6 space for eventual transition of existing services to IPv6, the number of present IPv4 customers may be used to justify a larger request than would be justified if based solely on the IPv6 infrastructure. ------------- I suppose this justifies the request, no ? I don't see any problem in allocating an ipv6 allocation bigger than /32 for ISP with millions of existing customers. Who knows how many subnets we will assign in 10, 20 years. A /32 is only 2^16 or 16 million /56 subnets or 65536 /48. I prefer this than allocate now a /32, in 2 years extend to a /30 and then to a /27 and then an other /27. (even if the other /32 in the /27 are not allocated to other LIR) It all depends on how future-proof the address plan is. What is used now for 6rd and transition can be reused in the LIR for extra customers / applications in 5 years. Marc Neuckens Belgacom **** DISCLAIMER **** http://www.belgacom.be/maildisclaimer
I fully agree with Marc: the policy currently allows allocating more than /32, so I see no need to change it. We are facing here a principle discussion. - the "R" in 6RD stays for "Rapid". And this is the most important point to consider. If we can rapidly bring millions of users to IPv6 without investing in big hardware/design changes (part. in these crisis times), combined with guys like Google/Youtube bringing traffic, then (and only then) v6 will become a reality. So this is in the interest of the RIPE community to make that happens. We have a successful POC with Free.fr - For the RIPE-NCC, this is imho even more important to push for v6 deployment and therefore to remove any potential obstacle for the ISPs and encourage them to implement 6-RD or similar solutions. If even getting IPv6 addresses becomes a fight, most ISPs may give up, since there is still no business case to justify it. Otherwise, in 2 years, the RIPE-NCC will have to be staffed with only 2-3 IPRAs and about 50 lawyers, since the market-price for IPv4 addresses will drive a huge business. (and to pay the lawyers, the membership fees will have to be about x10) André marc.neuckens@belgacom.be wrote:
I read in the paragraph 4 (IPv6 Policy Principles) of the IPv6 Address Allocation and Assignment Policy :
--------------- 4.4. Consideration of IPv4 infrastructure Where an existing IPv4 service provider requests IPv6 space for eventual transition of existing services to IPv6, the number of present IPv4 customers may be used to justify a larger request than would be justified if based solely on the IPv6 infrastructure. -------------
I suppose this justifies the request, no ?
I don't see any problem in allocating an ipv6 allocation bigger than /32 for ISP with millions of existing customers. Who knows how many subnets we will assign in 10, 20 years.
A /32 is only 2^16 or 16 million /56 subnets or 65536 /48.
I prefer this than allocate now a /32, in 2 years extend to a /30 and then to a /27 and then an other /27. (even if the other /32 in the /27 are not allocated to other LIR)
It all depends on how future-proof the address plan is.
What is used now for 6rd and transition can be reused in the LIR for extra customers / applications in 5 years.
Marc Neuckens Belgacom
**** DISCLAIMER **** http://www.belgacom.be/maildisclaimer
On Fri, 27 Nov 2009, Andre Chapuis wrote:
- For the RIPE-NCC, this is imho even more important to push for v6 deployment and therefore to remove any potential obstacle for the ISPs and encourage them to implement 6-RD or similar solutions.
6RD can be adapted to work without mapping the entire 32 bits of IPv4 into IPv6. Also, if someone wants to deploy 6RD and do map entire IPv4 into IPv6 then I think they should be incetivised to get rid of it quickly as well, thus not allow /56 or /60 to each customer, but only a /64. This would mean ISPs could make do with their /32 they already have, and then they can put their native IPv6 customers into the IPv6 equivalent of 224.0.0.0/3 because there will be no 6RD traffic there. If someone wants to offer larger networks then they need to do 6RD smarter, instead of mapping the entire IPv4 space into IPv6. I do *not* think 6RD bad design (or implementation) should warrant giving each ISP a /24 or /28. -- Mikael Abrahamsson email: swmike@swm.pp.se
Mikael Abrahamsson wrote:
On Fri, 27 Nov 2009, Andre Chapuis wrote:
- For the RIPE-NCC, this is imho even more important to push for v6 deployment and therefore to remove any potential obstacle for the ISPs and encourage them to implement 6-RD or similar solutions.
6RD can be adapted to work without mapping the entire 32 bits of IPv4 into IPv6. Also, if someone wants to deploy 6RD and do map entire IPv4 into IPv6 then I think they should be incetivised to get rid of it quickly as well, thus not allow /56 or /60 to each customer, but only a /64. This would mean ISPs could make do with their /32 they already have, and then they can put their native IPv6 customers into the IPv6 equivalent of 224.0.0.0/3 because there will be no 6RD traffic there. I don't think that incentive is terribly realistic, and is if anything a recipe for IPv6 forever remaining a bridged service in the home, or worse, a further incentive for the adoption of IPv6 NAT.
The incentive to move away from 6rd will be when IPv6 traffic and subscriber adoption reach levels where the associated economies of scale for IPv6-enabled equipment, applications, operational knowledge, etc. are at the point where it is economically viable to deploy natively vs. IPv4 alone. We're not there yet, but 6rd is helping. - Mark
If someone wants to offer larger networks then they need to do 6RD smarter, instead of mapping the entire IPv4 space into IPv6.
I do *not* think 6RD bad design (or implementation) should warrant giving each ISP a /24 or /28.
On Fri, 27 Nov 2009, Andre Chapuis wrote:
I fully agree with Marc: the policy currently allows allocating more than /32, so I see no need to change it.
We are facing here a principle discussion. - the "R" in 6RD stays for "Rapid". And this is the most important point to consider. If we can rapidly bring millions of users to IPv6 without investing in big hardware/design changes (part. in these crisis times), combined with guys like Google/Youtube bringing traffic, then (and only then) v6 will become a reality. So this is in the interest of the RIPE community to make that happens. We have a successful POC with Free.fr
Wrong: You need 6RD capable SOHO router. Free could dot it easily since Free is the owner and maintainer of the SOHO routers. The customers only leasing their CPEs. If your business modell is not similar you need big hardware changes....
- For the RIPE-NCC, this is imho even more important to push for v6 deployment and therefore to remove any potential obstacle for the ISPs and encourage them to implement 6-RD or similar solutions. If even getting IPv6 addresses becomes a fight, most ISPs may give up, since there is still no business case to justify it.
No fight for getting IPv6 address: simple rules, If you are a LIR just read them, and fill out the form. Best Regards, Janos Mohacsi
marc.neuckens@belgacom.be wrote:
I read in the paragraph 4 (IPv6 Policy Principles) of the IPv6 Address Allocation and Assignment Policy :
--------------- 4.4. Consideration of IPv4 infrastructure Where an existing IPv4 service provider requests IPv6 space for eventual transition of existing services to IPv6, the number of present IPv4 customers may be used to justify a larger request than would be justified if based solely on the IPv6 infrastructure. -------------
I suppose this justifies the request, no ?
It does seem to allow for quite a bit of leeway. I wonder though if smaller ISPs (without many IPv4 users to base upon) might get stuck out in the cold though. One argument given on this thread was that smaller ISPs might be more able to natively deploy, but on the other hand it's smaller ISPs that may not have the (legal or otherwise) ability to upgrade the non-IPv6 capable access network that 6rd is so good at getting around. Small ISPs also happen to be the kind that typically can deploy bleeding edge new services like IPv6. So, before saying we're done on this alone, I'd like to at least know that we are not holding up small ISPs willing to deploy IPv6 to all their customers in, say, 2010 iff they can use 6rd.
I don't see any problem in allocating an ipv6 allocation bigger than /32 for ISP with millions of existing customers. Who knows how many subnets we will assign in 10, 20 years.
A /32 is only 2^16 or 16 million /56 subnets or 65536 /48.
So strictly speaking, for a /28 prefix (6rd /60 to the customer with no IPv4 compression), basing upon eventual service of /48 to all sites when the transition is gone, an ISP needs 2^20 IPv4 customers today. That seems to be the bar: If you are an ISP with one million subscribers, you have the option of a /28 to deploy 6rd under current policy (two or four million to sit comfortably with a /27 or /26 like Free). I'd like to know if there are smaller ISPs wanting to deploy with 6rd, and whether compression is an option, etc. I'm pretty sure there are at least one or two, but a I doubt all that many. If I'm right, opening the door a little more widely to just these few I cannot imagine is all that dangerous, and perhaps could even happen under current policy.
I prefer this than allocate now a /32, in 2 years extend to a /30 and then to a /27 and then an other /27. (even if the other /32 in the /27 are not allocated to other LIR)
It all depends on how future-proof the address plan is.
What is used now for 6rd and transition can be reused in the LIR for extra customers / applications in 5 years.
Absolutely. And, if you give a little extra space to someone who *actually* deploys IPv6 now vs. later, I'd say that's a prize worth giving :-) - Mark
Marc Neuckens Belgacom
**** DISCLAIMER **** http://www.belgacom.be/maildisclaimer
* Lutz Donnerhacke
I still reading this draft and try hard to find the benefit over announcing more specific routes in 2002::/16.
Can you please hit me into the right direction?
RFC 3068. Modern client applications will prefer using IPv4 over IPv6 to connect to remote servers, if the local systems' IPv6 address is within 2002::/16. Even when behind IPv4 NAT. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27
On 26 nov 2009, at 14:48, Tore Anderson wrote:
* Lutz Donnerhacke
I still reading this draft and try hard to find the benefit over announcing more specific routes in 2002::/16.
Can you please hit me into the right direction?
RFC 3068. Modern client applications will prefer using IPv4 over IPv6 to connect to remote servers, if the local systems' IPv6 address is within 2002::/16. Even when behind IPv4 NAT.
Doesn't seem to be a problem in running 6rd since it's all designed to keep running IPv4 instead of IPv6. Groet, MarcoH
2009/11/26 Lutz Donnerhacke <lutz@iks-jena.de>:
I still reading this draft and try hard to find the benefit over announcing more specific routes in 2002::/16.
Other networks might not accept more specifics of 2002::/16 because they don't want to replicate the IPv4 routing table into the IPv6 routing table.
Hi Mark, thanks for your response. I'm also happy to see a feasible way of doing IPv6 deployment being developed; however I think this audience (including me) needs some guidance on how to apply address policy in this particular case. I agree that 6rd probably won't be the long term way of deploying IPv6. However, what's being suggested now is that 6rd in an environment with non-contiguous allocations pretty much *requires* reserving 32 bits (plus 4-8 bits for user prefixes) of v6-space for every single ISP out there because the aggregate set of IPv4 allocations to that ISP can't be compressed. I don't think that was how it was intended or how it should work. I hope you can help us shed some light here. Best, Remco -----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Mark Townsley Sent: donderdag 26 november 2009 12:00 To: address-policy-wg@ripe.net Subject: RE: [address-policy-wg] IPv6 allocations for 6RD All, My main goal with supporting 6rd is to see IPv6 deployed by Service Providers, preferably before the onslaught of CGNs leading to RFC1918 Private IPv4 as the new default Internet Access. As such, the fact that we are even having this conversation is rather encouraging. At the moment, 6rd accounts for the largest residential IPv6 Internet deployment to date. It's natural that some SPs are interested in replicating what has shown to work well for a neighboring SP. Not all of them want to go this route, but some do, and I'm thrilled as this very likely means a sooner IPv6 deployment in the world (at least among those SPs who see 6rd as their most viable alternative). I want to underscore here that we are not talking about forever allocating space away to a transition mechanism as was done with the /16 for 6to4, or the /32 for Teredo. Those address spaces will never be used for anything else, ever. The 6rd-related requests are, of course, for allocations to SPs that actually want to deploy IPv6 to their subscriber population in relative short order. One day, I hope that 6rd is not necessary for IPv6 deployment, but for the moment I'm firmly convinced that it is in a number of cases. Perhaps the WG could consider a temporary "early adopter" 6rd policy... e.g., for the next 3-5 years, those SPs that can show that native service is not economically viable for them, but commit that they can and will deploy with 6rd, will be allocated space necessary to get off the ground. At the end of this period, the WG could re-evaluate whether to abandon the more liberal policy in light of the ability to deploy natively at that time. As for the status of 6rd in the IETF, draft-townsley... is expired, and has been replaced by the Softwires Working Group document draft-ietf-softwire-ipv6-6rd-01.txt. Many Thanks, - Mark This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, Floor 6, 17 Thomas More Street, Thomas More Square, London E1W 1YW. Registered in England and Wales No. 6293383.
Remco van Mook wrote:
Hi Mark,
thanks for your response. I'm also happy to see a feasible way of doing IPv6 deployment being developed; however I think this audience (including me) needs some guidance on how to apply address policy in this particular case. I agree that 6rd probably won't be the long term way of deploying IPv6.
I've seen a couple of suggestions so far. One from me, another from Tore, that allow an SP the 6rd option without unduly polluting the address space. And that's just day one, so it looks like there might be some viable options here.
However, what's being suggested now is that 6rd in an environment with non-contiguous allocations pretty much *requires* reserving 32 bits (plus 4-8 bits for user prefixes) of v6-space for every single ISP out there because the aggregate set of IPv4 allocations to that ISP can't be compressed. Not every single ISP out there, but for every single ISP that intends to use 6rd. Not all will, but some will, particularly those who want to move more quickly down the IPv6 delivery path - something that I can't help but be in passionate support of. I don't think that was how it was intended or how it should work.
Well, *intentions* were that native IPv6 service would be possible to everyone many years ago. So much for good intentions. I'd like to see the WG at least consider the various options for SPs that want to replicate Free's success in IPv6 deployment. The large SPs that already claimed their /19 or /20 years ago don't have to worry about that whether they are using the space or not, but the other SPs should get a fair shake as well.
I hope you can help us shed some light here.
Hope that helps, and that the WG can come up with some constructive options here. - Mark
Best,
Remco
-----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Mark Townsley Sent: donderdag 26 november 2009 12:00 To: address-policy-wg@ripe.net Subject: RE: [address-policy-wg] IPv6 allocations for 6RD
All,
My main goal with supporting 6rd is to see IPv6 deployed by Service Providers, preferably before the onslaught of CGNs leading to RFC1918 Private IPv4 as the new default Internet Access. As such, the fact that we are even having this conversation is rather encouraging.
At the moment, 6rd accounts for the largest residential IPv6 Internet deployment to date. It's natural that some SPs are interested in replicating what has shown to work well for a neighboring SP. Not all of
them want to go this route, but some do, and I'm thrilled as this very likely means a sooner IPv6 deployment in the world (at least among those
SPs who see 6rd as their most viable alternative). I want to underscore here that we are not talking about forever allocating space away to a transition mechanism as was done with the /16 for 6to4, or the /32 for Teredo. Those address spaces will never be used for anything else, ever.
The 6rd-related requests are, of course, for allocations to SPs that actually want to deploy IPv6 to their subscriber population in relative short order. One day, I hope that 6rd is not necessary for IPv6 deployment, but for the moment I'm firmly convinced that it is in a number of cases.
Perhaps the WG could consider a temporary "early adopter" 6rd policy... e.g., for the next 3-5 years, those SPs that can show that native service is not economically viable for them, but commit that they can and will deploy with 6rd, will be allocated space necessary to get off the ground. At the end of this period, the WG could re-evaluate whether to abandon the more liberal policy in light of the ability to deploy natively at that time.
As for the status of 6rd in the IETF, draft-townsley... is expired, and has been replaced by the Softwires Working Group document draft-ietf-softwire-ipv6-6rd-01.txt.
Many Thanks,
- Mark
This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, Floor 6, 17 Thomas More Street, Thomas More Square, London E1W 1YW. Registered in England and Wales No. 6293383.
My main goal with supporting 6rd is to see IPv6 deployed by Service Providers, preferably before the onslaught of CGNs leading to RFC1918 Private IPv4 as the new default Internet Access.
excuse that i am a little slow. how does 6rd address/obviate the issue which seem to drive ntt and others to cgn? from my understanding, it just lets end sites, who could care less, live in an ipv6 world through the nat4444444 core. randy
Hi Randy, This statement refers back to something I presented at the last AMS RIPE meeting. There, I tried to underscore the point that we are at an inflection point in IPv4 NAT deployment, similar to the one we entered 10 years ago or so when the first level of NAT came on the scene. Then, the first level of NAT broke some applications that expected a global IPv4 address, and they eventually evolved to work around it (and so did perception of the average Internet user). The second level of NAT will break more, and there will be more evolution and change of perception. What I'd like to see is enough IPv6 out there at the same time this turmoil is taking place that the applications see value in including IPv6 in their repertoire of connectivity options. Hence the deadline in my mind that IPv6 needs to reach some level of critical mass to the end user before NAT44444 reaches a certain level of prevalence. It's essentially a war between these two, and I see 6rd as a weapon on the side of IPv6. Viable IPv6-only service to the residential home is a long way off, and that's not what I am suggesting. What I am suggesting is that 6rd moves up the timeline for dual-stack IPv4 (perhaps natted) and IPv6 deployment for at least some SPs. And, that this may be critically important for the success of IPv6. - Mark Randy Bush wrote:
My main goal with supporting 6rd is to see IPv6 deployed by Service Providers, preferably before the onslaught of CGNs leading to RFC1918 Private IPv4 as the new default Internet Access.
excuse that i am a little slow. how does 6rd address/obviate the issue which seem to drive ntt and others to cgn? from my understanding, it just lets end sites, who could care less, live in an ipv6 world through the nat4444444 core.
randy
This statement refers back to something I presented at the last AMS RIPE meeting. There, I tried to underscore the point that we are at an inflection point in IPv4 NAT deployment, similar to the one we entered 10 years ago or so when the first level of NAT came on the scene. Then, the first level of NAT broke some applications that expected a global IPv4 address, and they eventually evolved to work around it (and so did perception of the average Internet user). The second level of NAT will break more, and there will be more evolution and change of perception. What I'd like to see is enough IPv6 out there at the same time this turmoil is taking place that the applications see value in including IPv6 in their repertoire of connectivity options. Hence the deadline in my mind that IPv6 needs to reach some level of critical mass to the end user before NAT44444 reaches a certain level of prevalence. It's essentially a war between these two, and I see 6rd as a weapon on the side of IPv6.
Viable IPv6-only service to the residential home is a long way off, and that's not what I am suggesting. What I am suggesting is that 6rd moves up the timeline for dual-stack IPv4 (perhaps natted) and IPv6 deployment for at least some SPs. And, that this may be critically important for the success of IPv6.
- Mark
Randy Bush wrote:
My main goal with supporting 6rd is to see IPv6 deployed by Service Providers, preferably before the onslaught of CGNs leading to RFC1918 Private IPv4 as the new default Internet Access.
excuse that i am a little slow. how does 6rd address/obviate the issue which seem to drive ntt and others to cgn? from my understanding, it just lets end sites, who could care less, live in an ipv6 world through the nat4444444 core.
lemme try once more. i think 6rd is cool. and it certainly is better than teredo and similar <bleep>. but ... it does nothing to stave off nat44444 deployment as it does not address the big broadband provider's cloud address space issue. it lets an end site punch ipv6 through the nat44444, but why does the home user care if they're in 1918 space or ipv6 space? as you say, end user apps may be encouraged to become v6 capable. but aren't almost all v6 capable now, or moving quickly? so no harm. it's cool. but nothing to slow the horror of nat44444, which is gonna essentially break the internet. randy
participants (13)
-
Andre Chapuis -
Bernhard Schmidt -
Gert Doering -
Lorenzo Colitti -
Lutz Donnerhacke -
marc.neuckens＠belgacom.be -
Marco Hogewoning -
Mark Townsley -
Mikael Abrahamsson -
Mohacsi Janos -
Randy Bush -
Remco van Mook -
Tore Anderson