The Choice: IPv4 Exhaustion or Transition to IPv6
Hi all, I've published a document trying to analyze the IPv4 exhaustion problem and what is ahead of us, considering among others, changes in policies. http://www.ipv6tf.org/index.php?page=news/newsroom&id=3004 I guess this could be useful in order to understand possible implications of modifying existing policies, or setting up new ones, or even just to create some debate about those changes. The document was completed last April, but didn't had the time to tidy up until a few days ago. Regards, Jordi ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
On 27-jun-2007, at 21:08, JORDI PALET MARTINEZ wrote:
I've published a document trying to analyze the IPv4 exhaustion problem and what is ahead of us, considering among others, changes in policies.
Ugh, a link to a page with a link... Do you have an executive summary for us?
I'm working on it ... But I think it will be really difficult to capture in a couple of pages what the document try to explain ! Regards, Jordi
De: Iljitsch van Beijnum <iljitsch@muada.com> Responder a: <owner-nanog@merit.edu> Fecha: Thu, 28 Jun 2007 15:25:22 +0200 Para: <jordi.palet@consulintel.es> CC: <nanog@nanog.org> Asunto: Re: The Choice: IPv4 Exhaustion or Transition to IPv6
On 27-jun-2007, at 21:08, JORDI PALET MARTINEZ wrote:
I've published a document trying to analyze the IPv4 exhaustion problem and what is ahead of us, considering among others, changes in policies.
Ugh, a link to a page with a link...
Do you have an executive summary for us?
********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
On Thu, 28 Jun 2007 10:33:25 EDT, JORDI PALET MARTINEZ said:
I'm working on it ... But I think it will be really difficult to capture in a couple of pages what the document try to explain !
The story goes: Richard Feynman, the late Nobel Laureate in physics, was once asked by a Caltech faculty member to explain why spin one-half particles obey Fermi Dirac statistics. Rising to the challenge, he said, "I'll prepare a freshman lecture on it." But a few days later he told the faculty member, "You know, I couldn't do it. I couldn't reduce it to the freshman level. That means we really don't understand it." And he was talking about quantum mechanics. Surely we understand IPv4 exhaustion and IPv6 transitioning well enough to get it down to a few pages?
On 6/28/07, Valdis.Kletnieks@vt.edu <Valdis.Kletnieks@vt.edu> wrote:
On Thu, 28 Jun 2007 10:33:25 EDT, JORDI PALET MARTINEZ said:
I'm working on it ... But I think it will be really difficult to capture in a couple of pages what the document try to explain !
The story goes: Richard Feynman, the late Nobel Laureate in physics, was once asked by a Caltech faculty member to explain why spin one-half particles obey Fermi Dirac statistics. Rising to the challenge, he said, "I'll prepare a freshman lecture on it." But a few days later he told the faculty member, "You know, I couldn't do it. I couldn't reduce it to the freshman level. That means we really don't understand it."
And he was talking about quantum mechanics. Surely we understand IPv4 exhaustion and IPv6 transitioning well enough to get it down to a few pages?
1. IPv4 address space is a scarce resource and it will soon be exhausted. 2. It hasn't run out already due to various efficiency improvements. 3. These are themselves limited. 4. IPv6, though, will provide abundant address space. 5. But there's no incentive to change until enough others do so to make it worthwhile. 6. Economists call this a collective action problem. Traditional solutions include legislation, market leadership, and agreements among small actors to achieve such leadership. OK?
On Thu, 28 Jun 2007 16:00:36 BST, Alexander Harrowell said:
1. IPv4 address space is a scarce resource and it will soon be exhausted.
2. It hasn't run out already due to various efficiency improvements.
3. These are themselves limited.
4. IPv6, though, will provide abundant address space.
5. But there's no incentive to change until enough others do so to make it worthwhile.
6. Economists call this a collective action problem. Traditional solutions include legislation, market leadership, and agreements among small actors to achieve such leadership.
OK?
Ezzactly. :)
Alexander Harrowell wrote:
5. But there's no incentive to change until enough others do so to make it worthwhile.
5a. And consumer access products (aka Linksys-style routers and router equipped DSL/cable modems) make it's implementation simple enough for the average techophobe customer to handle with instructions or over-the-phone assistance.
6. Economists call this a collective action problem. Traditional solutions include legislation, market leadership, and agreements among small actors to achieve such leadership.
OK?
OK. -- Jeff Shultz
6. Economists call this a collective action problem. Traditional solutions include legislation, market leadership, and agreements among small actors to achieve such leadership.
You left out: The "killer-app." Compelling content *only* available via the alternative technology. The IPv-ONLY google/porn/web/tube/iphone/whatever that enough people want/desire/need/are-willing-to-pay-for to move the network to IPv6. --chuck
On Thu, Jun 28, 2007, chuck goolsbee wrote:
6. Economists call this a collective action problem. Traditional solutions include legislation, market leadership, and agreements among small actors to achieve such leadership.
You left out: The "killer-app."
Compelling content *only* available via the alternative technology. The IPv-ONLY google/porn/web/tube/iphone/whatever that enough people want/desire/need/are-willing-to-pay-for to move the network to IPv6.
You don't believe the killer app will be "sorry, no more IP addresses?" Adrian
Adrian Chadd wrote:
You don't believe the killer app will be "sorry, no more IP addresses?"
I bet it won't. There are too many people willing to patch what we have rather than toss it out and start over. As the IP addresses run ever lower, ISPs will probably patrol usage even more and reclaim IPs. Then router vendors will probably propose new routing schemes that don't require bit boundaries, so allocations can be made outside the powers of two, and ISPs will reclaim more and reallocate it. The routing tables will get bigger, but since memory is getting cheaper, we can work around that, too. IPv4 will probably become more and more of a kludge, but until somebody actually comes up with something IPv6 can do that cannot be backported to IPv4, customers are not going to give a rodent's behind about IPv6. There is a chance that some people will be roped in with "IPv6: It's Shiny and the Japanese Are Doing It," but not enough to make IPv6 a customer-driven initiative. IPv6 will most liekly be deployed and refined outside of the mass market: cell phones, personal nets, educational and research facilities, etc. Providers might slowly start building elaborate proxies to allow IPv4 clients to attach to IPv6 hosts (which will be hysterical: now with IPv6, everybody's a NAT client) as they convert their individual backbones to v4, or perhaps those proxies, like digital TV converter boxes, will live at the endpoints. But any dreams anybody may have of a flag day where IPv4 is turned off and IPv6 turned on are never going to come true unless the industry decides to do it en masse, so that all the customers who will be deeply offended have nowhere else to go. If you want IPv6, you're seriously going to need to think of how it can happen slowly and with as much of the pain as possible put upon the network engineers, who know what they are working for, and not the end users, who don't care how it works as long as their flash games, lolcatz, and porn keep working.
On 28-jun-2007, at 19:56, Dave Israel wrote:
You don't believe the killer app will be "sorry, no more IP addresses?"
I bet it won't. There are too many people willing to patch what we have rather than toss it out and start over. As the IP addresses run ever lower, ISPs will probably patrol usage even more and reclaim IPs.
The Comcasts of this world burn addresses by the millions. If they can't have new ones for (almost) free, they'll have to stick multiple customers behind a single IPv4 address. If you have to share your IP address with several of your neighbors, it becomes attractive to add IPv6 to the mix to make peer to peer stuff, including VoIP, work more reliably. QED.
Then router vendors will probably propose new routing schemes that don't require bit boundaries, so allocations can be made outside the powers of two, and ISPs will reclaim more and reallocate it. The routing tables will get bigger, but since memory is getting cheaper, we can work around that, too.
It will sure be interesting to see who attempts to and who succeeds at breaking through the /24 barrier.
customers are not going to give a rodent's behind about IPv6.
True, but they don't care about IPv4, either. They just want to talk to Youtube and Myspace. Whether that happens over IPv4, IPv6, CLNP or avian carriers doesn't matter. Guess what. I turned off IPv4 for half a day a while back. I couldn't print and instant messaging was a problem, but other than that, with a dual stack proxy to take care of the difference, it worked pretty well.
Thus spake "Iljitsch van Beijnum" <iljitsch@muada.com>
The Comcasts of this world burn addresses by the millions. If they can't have new ones for (almost) free, they'll have to stick multiple customers behind a single IPv4 address. If you have to share your IP address with several of your neighbors, it becomes attractive to add IPv6 to the mix to make peer to peer stuff, including VoIP, work more reliably. QED.
More likely, one day $BIG_ISP is going to go to ARIN with justification for another /12 or so and they're going to get a few hundred /20s instead because that's all that's left. Lather, rinse, repeat, and watch the v4 DFZ implode. This will happen _before_ RIR exhaustion hits. Hopefully, the $BIG_ISP folks of the world see this coming and are starting to tell CPE vendors that they will not buy/resell anything that doesn't do v6 after some fixed date. The abject lack of v6 support in ISP-supplied CPE devices shows that if they are, that date is not yet imminent. It's great we all have v6-capable hosts and core routers now, but that isn't enough; it's the CPE boxes (firewalls, DSL modems, etc.) that're going to eat us all alive in 3-4 years if things don't change Real Soon Now(tm). Kudos to Apple for being the first vendor to wake up; let's hope the others follow their lead in time to make a difference. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov
Thus spake "Iljitsch van Beijnum" <iljitsch@muada.com>
The Comcasts of this world burn addresses by the millions. If they can't have new ones for (almost) free, they'll have to stick multiple customers behind a single IPv4 address. If you have to share your IP address with several of your neighbors, it becomes attractive to add IPv6 to the mix to make peer to peer stuff, including VoIP, work more reliably. QED.
More likely, one day $BIG_ISP is going to go to ARIN with justification for another /12 or so and they're going to get a few hundred /20s instead because that's all that's left. Lather, rinse, repeat, and watch the v4 DFZ implode. This will happen _before_ RIR exhaustion hits. Hopefully, the $BIG_ISP folks of the world see this coming and are starting to tell CPE vendors that they will not buy/resell anything that doesn't do v6 after some fixed date. The abject lack of v6 support in ISP-supplied CPE devices shows that if they are, that date is not yet imminent. It's great we all have v6-capable hosts and core routers now, but that isn't enough; it's the CPE boxes (firewalls, DSL modems, etc.) that're going to eat us all alive in 3-4 years if things don't change Real Soon Now(tm). Kudos to Apple for being the first vendor to wake up; let's hope the others follow their lead in time to make a difference. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov
On Jun 28, 2007, at 10:06 AM, chuck goolsbee wrote:
6. Economists call this a collective action problem. Traditional solutions include legislation, market leadership, and agreements among small actors to achieve such leadership.
You left out: The "killer-app."
Compelling content *only* available via the alternative technology. The IPv-ONLY google/porn/web/tube/iphone/whatever that enough people want/desire/need/are-willing-to-pay-for to move the network to IPv6.
Would that be Teredo and a proprietary PNRP? http://blogs.msdn.com/p2p/archive/2007/03/22/teredo-and-the-pnrp- global-cloud.aspx Figuring out how maintain security without a hierarchical namespace, or a trackable address space represent sizable concerns. Would controlling teredo.ipv6.microsoft.com become essential? -Doug
1. IPv4 address space is a scarce resource and it will soon be exhausted.
2. It hasn't run out already due to various efficiency improvements.
3. These are themselves limited.
4. IPv6, though, will provide abundant address space.
5. But there's no incentive to change until enough others do so to make it worthwhile.
6. Economists call this a collective action problem. Traditional solutions include legislation, market leadership, and agreements among small actors to achieve such leadership.
Let's keep in mind here, that a number of "organizations" -- the US Gov't, Japan and a few other places that get pay for things without a real market incentive are moving to support IPv6. They will in turn put more pressure on their transit providers, vendors and IP talkers to talk to them on IPv6. This may help build #5's case up. Cisco (via Linksys), Netgear and other consumer brand router manufacturers may start supporting IPv6 if the ISPs that are providing broadband start it, or the employers of these home customers (vis-a-vis the US Gov't) start making it easier to use their IPv6 VPN vs their IPv4 VPN. Content providers (as response to customer pressure) may opt to make their services available on native IPv6 if the networks that are using IPv6 have crappy IPv6-IPv4 gateways. (e.g. Video distributors, etc). Market forces are already underway here, I fail to see why so many people are so concerned. Yes, we like hierarchical allocations, they are yummy to routers. Yes, we deal with humans and some adopt much slower than others. Maybe I'm missing something, DJ
On Thu, 28 Jun 2007 16:00:36 BST, Alexander Harrowell said:
1. IPv4 address space is a scarce resource and it will soon be exhausted.
2. It hasn't run out already due to various efficiency improvements.
3. These are themselves limited.
4. IPv6, though, will provide abundant address space.
5. But there's no incentive to change until enough others do so to make it worthwhile.
6. Economists call this a collective action problem. Traditional solutions include legislation, market leadership, and agreements among small actors to achieve such leadership.
7. RFC2827 flame-fests on NANOG have gotten boring. Let's have them for IPv6 instead. :)
Hmm I find this topic quite interesting. First is the belief that the Internet will suddenly break on the day when the last IP block is allocated by an RIR - the fact that most of the v4 space is currently not being announced may mean we have many years before there are real widespread shortages Second is the belief that this will prompt a migration to IPv6, as though moving to an entirely different and largely unsupported protocol stack is the logical thing to happen. Surely it is easier and far cheaper by use of existing technology for example for organisations to make efficient use of their public IPs and deploy NATs? As technology people we are looking at v6 as the clean bright future of IP, but the real world is driven by economics and I dont see v6 as being economically viable in the near future.... I'm also yet to hear a convincing explanation of how v6 and v4 are expected to interoperate in a v4 internet that contains v6 islands... Steve On Thu, Jun 28, 2007 at 10:33:25AM -0400, JORDI PALET MARTINEZ wrote:
I'm working on it ... But I think it will be really difficult to capture in a couple of pages what the document try to explain !
Regards, Jordi
De: Iljitsch van Beijnum <iljitsch@muada.com> Responder a: <owner-nanog@merit.edu> Fecha: Thu, 28 Jun 2007 15:25:22 +0200 Para: <jordi.palet@consulintel.es> CC: <nanog@nanog.org> Asunto: Re: The Choice: IPv4 Exhaustion or Transition to IPv6
On 27-jun-2007, at 21:08, JORDI PALET MARTINEZ wrote:
I've published a document trying to analyze the IPv4 exhaustion problem and what is ahead of us, considering among others, changes in policies.
Ugh, a link to a page with a link...
Do you have an executive summary for us?
********************************************** The IPv6 Portal: http://www.ipv6tf.org
Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org
This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
Steve - For the first end site that has to connect via IPv6, it will be very bad if there is not a base of IPv6 web/email sites already in place. While there are going to efforts to recover unused IPv4 space, we're currently going through 10 to 12 blocks of /8 size annually, so you may get an additional year or two, but it doesn't change the end state. There's no reason for end organizations to change their existing IPv4 infrastructure, but they do need to get their public facing servers reachable via IPv6. Anyone who thinks that the ISP's community can continue to grow using smaller and smaller pieces of reclaimed IPv4 address space hasn't considered the resulting routing table. We've build an entire Internet based on the assumption that most new end user sites are getting hierarchical, aggregatable PA assignments. This assumption is soon to fail until there's an option for connecting customers up via new hierarchical address space. Interoperability is achieved by having public facing servers reachable via IPv4 and IPv6. /John At 4:00 PM +0100 6/28/07, Stephen Wilcox wrote:
Hmm I find this topic quite interesting.
First is the belief that the Internet will suddenly break on the day when the last IP block is allocated by an RIR - the fact that most of the v4 space is currently not being announced may mean we have many years before there are real widespread shortages
Second is the belief that this will prompt a migration to IPv6, as though moving to an entirely different and largely unsupported protocol stack is the logical thing to happen. Surely it is easier and far cheaper by use of existing technology for example for organisations to make efficient use of their public IPs and deploy NATs?
As technology people we are looking at v6 as the clean bright future of IP, but the real world is driven by economics and I dont see v6 as being economically viable in the near future....
I'm also yet to hear a convincing explanation of how v6 and v4 are expected to interoperate in a v4 internet that contains v6 islands...
Steve
On Thu, Jun 28, 2007 at 10:33:25AM -0400, JORDI PALET MARTINEZ wrote:
I'm working on it ... But I think it will be really difficult to capture in a couple of pages what the document try to explain !
Regards, Jordi
De: Iljitsch van Beijnum <iljitsch@muada.com> Responder a: <owner-nanog@merit.edu> Fecha: Thu, 28 Jun 2007 15:25:22 +0200 Para: <jordi.palet@consulintel.es> CC: <nanog@nanog.org> Asunto: Re: The Choice: IPv4 Exhaustion or Transition to IPv6
On 27-jun-2007, at 21:08, JORDI PALET MARTINEZ wrote:
I've published a document trying to analyze the IPv4 exhaustion problem and what is ahead of us, considering among others, changes in policies.
Ugh, a link to a page with a link...
Do you have an executive summary for us?
********************************************** The IPv6 Portal: http://www.ipv6tf.org
Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org
This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
Hi John, I wasnt specifically thinking of reclamation of space, I was noting a couple of things: - that less than 50% of the v4 space is currently routed. scarcity will presumably cause these non-routed blocks to be: :- used and routes :- reclaimed and reassigned :- sold on - that much of the space in use within organisations could be optimised :- mop up unused gaps in subnet :- return IPs to the org's pool by forcing departments onto NATs Pushing to NAT is on the face of it similar to pushing for early adoption of v6 whereby v6-v4 gateways provide a translation. However the technology for NATs is well established, widely deployed, cheap and very understandable to any IT guy. You also refer to routing table size. The current routing table is growing quickly but people have been predicting the tables will outgrow the technology for many years but in each case new hardware gets released and on modern routers we can take significant growth (400%?). I dont believe routing table size comes into play in this, the simple reason is that whatever we say there will always be companies willing to take routes for money and it doesnt matter who or where they are because the rest of the world just has to route it. I dont think that hierarchical routing will ever be a reality in todays diverse internet backbone, to not be a top tier carrier with your own ASN, and a full set of routes means you are closing your doors on selling transit. There are many thousand organisations making money from that, I cant see 99% of them bowing out gracefully to leave a few 'tier1s' behind.. that would be like turning back the clock 15 years. Steve On Thu, Jun 28, 2007 at 12:16:51PM -0400, John Curran wrote:
Steve -
For the first end site that has to connect via IPv6, it will be very bad if there is not a base of IPv6 web/email sites already in place.
While there are going to efforts to recover unused IPv4 space, we're currently going through 10 to 12 blocks of /8 size annually, so you may get an additional year or two, but it doesn't change the end state.
There's no reason for end organizations to change their existing IPv4 infrastructure, but they do need to get their public facing servers reachable via IPv6.
Anyone who thinks that the ISP's community can continue to grow using smaller and smaller pieces of reclaimed IPv4 address space hasn't considered the resulting routing table. We've build an entire Internet based on the assumption that most new end user sites are getting hierarchical, aggregatable PA assignments. This assumption is soon to fail until there's an option for connecting customers up via new hierarchical address space.
Interoperability is achieved by having public facing servers reachable via IPv4 and IPv6.
/John
At 4:00 PM +0100 6/28/07, Stephen Wilcox wrote:
Hmm I find this topic quite interesting.
First is the belief that the Internet will suddenly break on the day when the last IP block is allocated by an RIR - the fact that most of the v4 space is currently not being announced may mean we have many years before there are real widespread shortages
Second is the belief that this will prompt a migration to IPv6, as though moving to an entirely different and largely unsupported protocol stack is the logical thing to happen. Surely it is easier and far cheaper by use of existing technology for example for organisations to make efficient use of their public IPs and deploy NATs?
As technology people we are looking at v6 as the clean bright future of IP, but the real world is driven by economics and I dont see v6 as being economically viable in the near future....
I'm also yet to hear a convincing explanation of how v6 and v4 are expected to interoperate in a v4 internet that contains v6 islands...
Steve
On Thu, Jun 28, 2007 at 10:33:25AM -0400, JORDI PALET MARTINEZ wrote:
I'm working on it ... But I think it will be really difficult to capture in a couple of pages what the document try to explain !
Regards, Jordi
De: Iljitsch van Beijnum <iljitsch@muada.com> Responder a: <owner-nanog@merit.edu> Fecha: Thu, 28 Jun 2007 15:25:22 +0200 Para: <jordi.palet@consulintel.es> CC: <nanog@nanog.org> Asunto: Re: The Choice: IPv4 Exhaustion or Transition to IPv6
On 27-jun-2007, at 21:08, JORDI PALET MARTINEZ wrote:
I've published a document trying to analyze the IPv4 exhaustion problem and what is ahead of us, considering among others, changes in policies.
Ugh, a link to a page with a link...
Do you have an executive summary for us?
********************************************** The IPv6 Portal: http://www.ipv6tf.org
Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org
This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
Steve - If you have a plan for continued operation of the Internet during IPv4 depletion, please write it up as an RFC. Our present Internet routing scheme is predominantly working based on hierarchical routing but I'm certain there are alternatives. /John At 5:42 PM +0100 6/28/07, Stephen Wilcox wrote:
Hi John, I wasnt specifically thinking of reclamation of space, I was noting a couple of things:
- that less than 50% of the v4 space is currently routed. scarcity will presumably cause these non-routed blocks to be: :- used and routes :- reclaimed and reassigned :- sold on
- that much of the space in use within organisations could be optimised :- mop up unused gaps in subnet :- return IPs to the org's pool by forcing departments onto NATs
Pushing to NAT is on the face of it similar to pushing for early adoption of v6 whereby v6-v4 gateways provide a translation. However the technology for NATs is well established, widely deployed, cheap and very understandable to any IT guy.
You also refer to routing table size. The current routing table is growing quickly but people have been predicting the tables will outgrow the technology for many years but in each case new hardware gets released and on modern routers we can take significant growth (400%?).
I dont believe routing table size comes into play in this, the simple reason is that whatever we say there will always be companies willing to take routes for money and it doesnt matter who or where they are because the rest of the world just has to route it.
I dont think that hierarchical routing will ever be a reality in todays diverse internet backbone, to not be a top tier carrier with your own ASN, and a full set of routes means you are closing your doors on selling transit. There are many thousand organisations making money from that, I cant see 99% of them bowing out gracefully to leave a few 'tier1s' behind.. that would be like turning back the clock 15 years.
Steve
On Thu, Jun 28, 2007 at 12:16:51PM -0400, John Curran wrote:
Steve -
For the first end site that has to connect via IPv6, it will be very bad if there is not a base of IPv6 web/email sites already in place.
While there are going to efforts to recover unused IPv4 space, we're currently going through 10 to 12 blocks of /8 size annually, so you may get an additional year or two, but it doesn't change the end state.
There's no reason for end organizations to change their existing IPv4 infrastructure, but they do need to get their public facing servers reachable via IPv6.
Anyone who thinks that the ISP's community can continue to grow using smaller and smaller pieces of reclaimed IPv4 address space hasn't considered the resulting routing table. We've build an entire Internet based on the assumption that most new end user sites are getting hierarchical, aggregatable PA assignments. This assumption is soon to fail until there's an option for connecting customers up via new hierarchical address space.
Interoperability is achieved by having public facing servers reachable via IPv4 and IPv6.
/John
At 4:00 PM +0100 6/28/07, Stephen Wilcox wrote:
Hmm I find this topic quite interesting.
First is the belief that the Internet will suddenly break on the day when the last IP block is allocated by an RIR - the fact that most of the v4 space is currently not being announced may mean we have many years before there are real widespread shortages
Second is the belief that this will prompt a migration to IPv6, as though moving to an entirely different and largely unsupported protocol stack is the logical thing to happen. Surely it is easier and far cheaper by use of existing technology for example for organisations to make efficient use of their public IPs and deploy NATs?
As technology people we are looking at v6 as the clean bright future of IP, but the real world is driven by economics and I dont see v6 as being economically viable in the near future....
I'm also yet to hear a convincing explanation of how v6 and v4 are expected to interoperate in a v4 internet that contains v6 islands...
Steve
On Thu, Jun 28, 2007 at 10:33:25AM -0400, JORDI PALET MARTINEZ wrote:
I'm working on it ... But I think it will be really difficult to capture in a couple of pages what the document try to explain !
Regards, Jordi
De: Iljitsch van Beijnum <iljitsch@muada.com> Responder a: <owner-nanog@merit.edu> Fecha: Thu, 28 Jun 2007 15:25:22 +0200 Para: <jordi.palet@consulintel.es> CC: <nanog@nanog.org> Asunto: Re: The Choice: IPv4 Exhaustion or Transition to IPv6
On 27-jun-2007, at 21:08, JORDI PALET MARTINEZ wrote:
I've published a document trying to analyze the IPv4 exhaustion problem and what is ahead of us, considering among others, changes in policies.
Ugh, a link to a page with a link...
Do you have an executive summary for us?
********************************************** The IPv6 Portal: http://www.ipv6tf.org
Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org
This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
Hi John, I am not offering an elegant technical solution that would be worthy of an RFC number! :) But I am saying that the Internet of today will evolve organically and that there are a number of ways you can get by with what we have for a long time until things get really ugly. Justin suggested that ISPs will be hit first because they are the distributors of IPs and when they cant go back for more they will be in trouble. I can turn that around tho, as an ISP if I cant get more IP space but I have customers who NEED public IPs and are willing to pay I will just 'find' some.. if I charge a small nominal monthly fee per IP or start pushing my DSL base onto NAT rather than static or dynamic public IPs I'm sure I can quickly free up a significant portion of IPs that I can capitalise on. I still dont believe the current Internet is a hierarchy. Theres something like 25000 ASNs out there with maybe 3000 of them interconnecting in a serious way (ie peering). If that were a corporate org chart you'd be describing it as flat not hierarchical! Steve On Thu, Jun 28, 2007 at 12:51:48PM -0400, John Curran wrote:
Steve -
If you have a plan for continued operation of the Internet during IPv4 depletion, please write it up as an RFC. Our present Internet routing scheme is predominantly working based on hierarchical routing but I'm certain there are alternatives.
/John
At 5:42 PM +0100 6/28/07, Stephen Wilcox wrote:
Hi John, I wasnt specifically thinking of reclamation of space, I was noting a couple of things:
- that less than 50% of the v4 space is currently routed. scarcity will presumably cause these non-routed blocks to be: :- used and routes :- reclaimed and reassigned :- sold on
- that much of the space in use within organisations could be optimised :- mop up unused gaps in subnet :- return IPs to the org's pool by forcing departments onto NATs
Pushing to NAT is on the face of it similar to pushing for early adoption of v6 whereby v6-v4 gateways provide a translation. However the technology for NATs is well established, widely deployed, cheap and very understandable to any IT guy.
You also refer to routing table size. The current routing table is growing quickly but people have been predicting the tables will outgrow the technology for many years but in each case new hardware gets released and on modern routers we can take significant growth (400%?).
I dont believe routing table size comes into play in this, the simple reason is that whatever we say there will always be companies willing to take routes for money and it doesnt matter who or where they are because the rest of the world just has to route it.
I dont think that hierarchical routing will ever be a reality in todays diverse internet backbone, to not be a top tier carrier with your own ASN, and a full set of routes means you are closing your doors on selling transit. There are many thousand organisations making money from that, I cant see 99% of them bowing out gracefully to leave a few 'tier1s' behind.. that would be like turning back the clock 15 years.
Steve
On Thu, Jun 28, 2007 at 12:16:51PM -0400, John Curran wrote:
Steve -
For the first end site that has to connect via IPv6, it will be very bad if there is not a base of IPv6 web/email sites already in place.
While there are going to efforts to recover unused IPv4 space, we're currently going through 10 to 12 blocks of /8 size annually, so you may get an additional year or two, but it doesn't change the end state.
There's no reason for end organizations to change their existing IPv4 infrastructure, but they do need to get their public facing servers reachable via IPv6.
Anyone who thinks that the ISP's community can continue to grow using smaller and smaller pieces of reclaimed IPv4 address space hasn't considered the resulting routing table. We've build an entire Internet based on the assumption that most new end user sites are getting hierarchical, aggregatable PA assignments. This assumption is soon to fail until there's an option for connecting customers up via new hierarchical address space.
Interoperability is achieved by having public facing servers reachable via IPv4 and IPv6.
/John
At 4:00 PM +0100 6/28/07, Stephen Wilcox wrote:
Hmm I find this topic quite interesting.
First is the belief that the Internet will suddenly break on the day when the last IP block is allocated by an RIR - the fact that most of the v4 space is currently not being announced may mean we have many years before there are real widespread shortages
Second is the belief that this will prompt a migration to IPv6, as though moving to an entirely different and largely unsupported protocol stack is the logical thing to happen. Surely it is easier and far cheaper by use of existing technology for example for organisations to make efficient use of their public IPs and deploy NATs?
As technology people we are looking at v6 as the clean bright future of IP, but the real world is driven by economics and I dont see v6 as being economically viable in the near future....
I'm also yet to hear a convincing explanation of how v6 and v4 are expected to interoperate in a v4 internet that contains v6 islands...
Steve
On Thu, Jun 28, 2007 at 10:33:25AM -0400, JORDI PALET MARTINEZ wrote:
I'm working on it ... But I think it will be really difficult to capture in a couple of pages what the document try to explain !
Regards, Jordi
De: Iljitsch van Beijnum <iljitsch@muada.com> Responder a: <owner-nanog@merit.edu> Fecha: Thu, 28 Jun 2007 15:25:22 +0200 Para: <jordi.palet@consulintel.es> CC: <nanog@nanog.org> Asunto: Re: The Choice: IPv4 Exhaustion or Transition to IPv6
On 27-jun-2007, at 21:08, JORDI PALET MARTINEZ wrote:
> I've published a document trying to analyze the IPv4 exhaustion > problem and > what is ahead of us, considering among others, changes in policies.
> http://www.ipv6tf.org/index.php?page=news/newsroom&id=3004
Ugh, a link to a page with a link...
Do you have an executive summary for us?
********************************************** The IPv6 Portal: http://www.ipv6tf.org
Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org
This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
At 6:09 PM +0100 6/28/07, Stephen Wilcox wrote:
Hi John, I am not offering an elegant technical solution that would be worthy of an RFC number! :) But I am saying that the Internet of today will evolve organically and that there are a number of ways you can get by with what we have for a long time until things get really ugly.
Interesting... We likely differ on how long "a long time" is, and definitions of what happens when things get really ugly.
Justin suggested that ISPs will be hit first because they are the distributors of IPs and when they cant go back for more they will be in trouble. I can turn that around tho, as an ISP if I cant get more IP space but I have customers who NEED public IPs and are willing to pay I will just 'find' some.. if I charge a small nominal monthly fee per IP or start pushing my DSL base onto NAT rather than static or dynamic public IPs I'm sure I can quickly free up a significant portion of IPs that I can capitalise on.
You can, and this will work for a while. When it stops working (which is not at all predictable) you're going to need a fairly sizable IPv6 Internet so that you can continue to connect new customers up, and unfortunately, that means we need to start getting folks moving ahead of time since we don't exactly know how long your workarounds will last.
I still dont believe the current Internet is a hierarchy. Theres something like 25000 ASNs out there with maybe 3000 of them interconnecting in a serious way (ie peering). If that were a corporate org chart you'd be describing it as flat not hierarchical!
I'm guessing we've got tens of millions (if not hundreds of millions) of organizations connected to the Internet, and that's being done with 25000 ASN's and 400000 routes... That's absolutely the result of hierarchical provider assigned addressing in extensive use. /John
You can, and this will work for a while. When it stops working (which is not at all predictable) you're going to need a fairly sizable IPv6 Internet so that you can continue to connect new customers up, and unfortunately, that means we need to start getting folks moving ahead of time since we don't exactly know how long your workarounds will last. I'd like to know when Google is going to go IPv6. Vint Cerf's answer was (essentially) "I'm pushing for it."
The problem is twofold. First, if Google isn't going to index IPv6 content, no one cares if their content isn't available that way. Second, when other people try to explain IPv6 to management they often hear "Is Google using IPv6?" Heck, Google could offer incentives for IPv6 deployment and suddenly people would clamor for it- say side by side results. Most appropriate IPv4 on the left, most appropriate IPv6 on the right. (Even just an IPv6 icon that people could click on to learn about IPv6 would help). -Don
On 28 Jun 2007, at 19:17, Donald Stahl wrote:
The problem is twofold. First, if Google isn't going to index IPv6 content, no one cares if their content isn't available that way.
That's the thing .. google's crawlers and search app runs at layer 7, v6 is an addressing system that runs at layer 3. If we'd (the community) got everything right with v6, it wouldn't matter to Google's applications whether the content came from a site hosted on a v4 address, or a v6 address, or even both. I don't think we have got everything right at all.
That's the thing .. google's crawlers and search app runs at layer 7, v6 is an addressing system that runs at layer 3. If we'd (the community) got everything right with v6, it wouldn't matter to Google's applications whether the content came from a site hosted on a v4 address, or a v6 address, or even both. If Google does not have v6 connectivity then how are they going to crawl
those v6 sites? -Don
On 29 Jun 2007, at 14:24, Donald Stahl wrote:
That's the thing .. google's crawlers and search app runs at layer 7, v6 is an addressing system that runs at layer 3. If we'd (the community) got everything right with v6, it wouldn't matter to Google's applications whether the content came from a site hosted on a v4 address, or a v6 address, or even both. If Google does not have v6 connectivity then how are they going to crawl those v6 sites?
I think we're debating from very similar positions... v6 isn't the ideal scenario of '96 extra bits for free', because if life was so simple, we wouldn't need to ask this question. Andy
Until there's a practical solution for multihoming, this whole discussion is pretty pointless. -- Sent from my BlackBerry. -----Original Message----- From: Andy Davidson <andy@nosignal.org> Date: Fri, 29 Jun 2007 14:27:33 To:Donald Stahl <don@calis.blacksun.org> Cc:nanog@nanog.org Subject: Re: The Choice: IPv4 Exhaustion or Transition to IPv6 On 29 Jun 2007, at 14:24, Donald Stahl wrote:
That's the thing .. google's crawlers and search app runs at layer 7, v6 is an addressing system that runs at layer 3. If we'd (the community) got everything right with v6, it wouldn't matter to Google's applications whether the content came from a site hosted on a v4 address, or a v6 address, or even both. If Google does not have v6 connectivity then how are they going to crawl those v6 sites?
I think we're debating from very similar positions... v6 isn't the ideal scenario of '96 extra bits for free', because if life was so simple, we wouldn't need to ask this question. Andy
multihoming is simple, you get an address block and route it to your upstreams. the policy surrounding that is another debate, possibly for another group this thread is discussing how v4 to v6 migration can operate on a network level Steve On Fri, Jun 29, 2007 at 01:37:23PM +0000, Christian Kuhtz wrote:
Until there's a practical solution for multihoming, this whole discussion is pretty pointless.
-- Sent from my BlackBerry.
-----Original Message----- From: Andy Davidson <andy@nosignal.org>
Date: Fri, 29 Jun 2007 14:27:33 To:Donald Stahl <don@calis.blacksun.org> Cc:nanog@nanog.org Subject: Re: The Choice: IPv4 Exhaustion or Transition to IPv6
On 29 Jun 2007, at 14:24, Donald Stahl wrote:
That's the thing .. google's crawlers and search app runs at layer 7, v6 is an addressing system that runs at layer 3. If we'd (the community) got everything right with v6, it wouldn't matter to Google's applications whether the content came from a site hosted on a v4 address, or a v6 address, or even both. If Google does not have v6 connectivity then how are they going to crawl those v6 sites?
I think we're debating from very similar positions...
v6 isn't the ideal scenario of '96 extra bits for free', because if life was so simple, we wouldn't need to ask this question.
Andy
Amazink! Some things on NANOG _never_ change. Trawling for trolls I must be. If you want to emulate IPv4 and destroy the DFZ, yes, this is trivial. And you should go ahead and plan that migration. As you well known, one of the core assumptions of IPv6 is that the DFZ policy stay intact, ostensibly to solve a very specific scaling problem. So, go ahead and continue talking about migration while ignoring the very policies within which that is permitted to take place and don't let me interrupt that ranting. Best Regards, Christian -- Sent from my BlackBerry. -----Original Message----- From: Stephen Wilcox <steve.wilcox@packetrade.com> Date: Fri, 29 Jun 2007 14:55:06 To:Christian Kuhtz <kuhtzch@corp.earthlink.net> Cc:Andy Davidson <andy@nosignal.org>, owner-nanog@merit.edu, Donald Stahl <don@calis.blacksun.org>, nanog@nanog.org Subject: Re: The Choice: IPv4 Exhaustion or Transition to IPv6 multihoming is simple, you get an address block and route it to your upstreams. the policy surrounding that is another debate, possibly for another group this thread is discussing how v4 to v6 migration can operate on a network level Steve On Fri, Jun 29, 2007 at 01:37:23PM +0000, Christian Kuhtz wrote:
Until there's a practical solution for multihoming, this whole discussion is pretty pointless.
-- Sent from my BlackBerry.
-----Original Message----- From: Andy Davidson <andy@nosignal.org>
Date: Fri, 29 Jun 2007 14:27:33 To:Donald Stahl <don@calis.blacksun.org> Cc:nanog@nanog.org Subject: Re: The Choice: IPv4 Exhaustion or Transition to IPv6
On 29 Jun 2007, at 14:24, Donald Stahl wrote:
That's the thing .. google's crawlers and search app runs at layer 7, v6 is an addressing system that runs at layer 3. If we'd (the community) got everything right with v6, it wouldn't matter to Google's applications whether the content came from a site hosted on a v4 address, or a v6 address, or even both. If Google does not have v6 connectivity then how are they going to crawl those v6 sites?
I think we're debating from very similar positions...
v6 isn't the ideal scenario of '96 extra bits for free', because if life was so simple, we wouldn't need to ask this question.
Andy
Hi Christian, I am not seeing how v4 exhaustion, transition to v6, multihoming in v6 and destruction ov DFZ are correlated. If you took everything on v4 today and migrated it to v6 tomoro the routing table would not grow - actually by my calculation it should shrink (every ASN would only need one prefix to cover its current and anticipated growth). So we'll see 220000 routes reduce to 25000. The technology we have now is not driving multihoming directly and v4 vs v6 is not a factor there. So in what way is v6 destroying DFZ? Steve On Fri, Jun 29, 2007 at 02:13:50PM +0000, Christian Kuhtz wrote:
Amazink! Some things on NANOG _never_ change. Trawling for trolls I must be.
If you want to emulate IPv4 and destroy the DFZ, yes, this is trivial. And you should go ahead and plan that migration.
As you well known, one of the core assumptions of IPv6 is that the DFZ policy stay intact, ostensibly to solve a very specific scaling problem.
So, go ahead and continue talking about migration while ignoring the very policies within which that is permitted to take place and don't let me interrupt that ranting.
Best Regards, Christian
-- Sent from my BlackBerry.
-----Original Message----- From: Stephen Wilcox <steve.wilcox@packetrade.com>
Date: Fri, 29 Jun 2007 14:55:06 To:Christian Kuhtz <kuhtzch@corp.earthlink.net> Cc:Andy Davidson <andy@nosignal.org>, owner-nanog@merit.edu, Donald Stahl <don@calis.blacksun.org>, nanog@nanog.org Subject: Re: The Choice: IPv4 Exhaustion or Transition to IPv6
multihoming is simple, you get an address block and route it to your upstreams.
the policy surrounding that is another debate, possibly for another group
this thread is discussing how v4 to v6 migration can operate on a network level
Steve
On Fri, Jun 29, 2007 at 01:37:23PM +0000, Christian Kuhtz wrote:
Until there's a practical solution for multihoming, this whole discussion is pretty pointless.
-- Sent from my BlackBerry.
-----Original Message----- From: Andy Davidson <andy@nosignal.org>
Date: Fri, 29 Jun 2007 14:27:33 To:Donald Stahl <don@calis.blacksun.org> Cc:nanog@nanog.org Subject: Re: The Choice: IPv4 Exhaustion or Transition to IPv6
On 29 Jun 2007, at 14:24, Donald Stahl wrote:
That's the thing .. google's crawlers and search app runs at layer 7, v6 is an addressing system that runs at layer 3. If we'd (the community) got everything right with v6, it wouldn't matter to Google's applications whether the content came from a site hosted on a v4 address, or a v6 address, or even both. If Google does not have v6 connectivity then how are they going to crawl those v6 sites?
I think we're debating from very similar positions...
v6 isn't the ideal scenario of '96 extra bits for free', because if life was so simple, we wouldn't need to ask this question.
Andy
If you took everything on v4 today and migrated it to v6 tomoro the routing table would not grow - actually by my calculation it should shrink (every ASN would only need one prefix to cover its current and anticipated growth). So we'll see 220000 routes reduce to 25000. Even if you gave everyone 2 or 3 bits to deaggregate with for TE purposes
the table would _still_ be smaller. As the majority of people multihoming would never use more than 1 bit for TE purposes you would only end up with 50k routes. TCAM's and routers in general have always been able to keep up with table growth. As long as we don't do anything mind numbingly stupid they will continue to keep up. They won't be able to keep up, however, if we run out of addresses and ISP's start getting allocations of 200 separate /24's or if we need to start announcing /25's and longer. -Don
Hi Stephen, Supose you have STM4 links, ok? And you have 2G of trafic from your 100000 ADSL customers, ok? And those STM4 go to 3 dif carriers in USA. Then, how you advertise only one IPv6 prefix to all and make the 2G go trough one STM4 ? On Fri, 29 Jun 2007, Stephen Wilcox wrote: steve. > steve. >Hi Christian, steve. > I am not seeing how v4 exhaustion, transition to v6, multihoming in v6 and destruction ov DFZ are correlated. steve. > steve. >If you took everything on v4 today and migrated it to v6 tomoro the routing table would not grow - actually by my calculation it should shrink (every ASN would only need one prefix to cover its current and anticipated growth). So we'll see 220000 routes reduce to 25000. steve. > steve. >The technology we have now is not driving multihoming directly and v4 vs v6 is not a factor there. steve. > steve. >So in what way is v6 destroying DFZ? steve. > steve. >Steve steve. > steve. >On Fri, Jun 29, 2007 at 02:13:50PM +0000, Christian Kuhtz wrote: steve. >> steve. >> Amazink! Some things on NANOG _never_ change. Trawling for trolls I must be. steve. >> steve. >> If you want to emulate IPv4 and destroy the DFZ, yes, this is trivial. And you should go ahead and plan that migration. steve. >> steve. >> As you well known, one of the core assumptions of IPv6 is that the DFZ policy stay intact, ostensibly to solve a very specific scaling problem. steve. >> steve. >> So, go ahead and continue talking about migration while ignoring the very policies within which that is permitted to take place and don't let me interrupt that ranting. steve. >> steve. >> Best Regards, steve. >> Christian steve. >> steve. >> -- steve. >> Sent from my BlackBerry. steve. >> steve. >> -----Original Message----- steve. >> From: Stephen Wilcox <steve.wilcox@packetrade.com> steve. >> steve. >> Date: Fri, 29 Jun 2007 14:55:06 steve. >> To:Christian Kuhtz <kuhtzch@corp.earthlink.net> steve. >> Cc:Andy Davidson <andy@nosignal.org>, owner-nanog@merit.edu, Donald Stahl <don@calis.blacksun.org>, nanog@nanog.org steve. >> Subject: Re: The Choice: IPv4 Exhaustion or Transition to IPv6 steve. >> steve. >> steve. >> multihoming is simple, you get an address block and route it to your upstreams. steve. >> steve. >> the policy surrounding that is another debate, possibly for another group steve. >> steve. >> this thread is discussing how v4 to v6 migration can operate on a network level steve. >> steve. >> Steve steve. >> steve. >> On Fri, Jun 29, 2007 at 01:37:23PM +0000, Christian Kuhtz wrote: steve. >> > Until there's a practical solution for multihoming, this whole discussion is pretty pointless. steve. >> > steve. >> > -- steve. >> > Sent from my BlackBerry. steve. >> > steve. >> > -----Original Message----- steve. >> > From: Andy Davidson <andy@nosignal.org> steve. >> > steve. >> > Date: Fri, 29 Jun 2007 14:27:33 steve. >> > To:Donald Stahl <don@calis.blacksun.org> steve. >> > Cc:nanog@nanog.org steve. >> > Subject: Re: The Choice: IPv4 Exhaustion or Transition to IPv6 steve. >> > steve. >> > steve. >> > steve. >> > steve. >> > On 29 Jun 2007, at 14:24, Donald Stahl wrote: steve. >> > steve. >> > >> That's the thing .. google's crawlers and search app runs at layer steve. >> > >> 7, v6 is an addressing system that runs at layer 3. If we'd (the steve. >> > >> community) got everything right with v6, it wouldn't matter to steve. >> > >> Google's applications whether the content came from a site hosted steve. >> > >> on a v4 address, or a v6 address, or even both. steve. >> > > If Google does not have v6 connectivity then how are they going to steve. >> > > crawl those v6 sites? steve. >> > steve. >> > I think we're debating from very similar positions... steve. >> > steve. >> > v6 isn't the ideal scenario of '96 extra bits for free', because if steve. >> > life was so simple, we wouldn't need to ask this question. steve. >> > steve. >> > Andy steve. >> > steve. >
Hi Nicolas, you will never make 2GB of traffic go down one STM4 or even 3x STM4! But you are asking me about load balancing amongst 3 upstreams... Deaggregation of your prefix is an ugly way to do TE. If you buy from carriers that support BGP communities there are much nicer ways to manage this. I've never deaggregated and I have had and do have individual prefixes that generate more traffic than any single GE link. Steve On Fri, Jun 29, 2007 at 12:11:58PM -0300, Nicolás Antoniello wrote:
Hi Stephen,
Supose you have STM4 links, ok? And you have 2G of trafic from your 100000 ADSL customers, ok? And those STM4 go to 3 dif carriers in USA. Then, how you advertise only one IPv6 prefix to all and make the 2G go trough one STM4 ?
On Fri, 29 Jun 2007, Stephen Wilcox wrote:
steve. > steve. >Hi Christian, steve. > I am not seeing how v4 exhaustion, transition to v6, multihoming in v6 and destruction ov DFZ are correlated. steve. > steve. >If you took everything on v4 today and migrated it to v6 tomoro the routing table would not grow - actually by my calculation it should shrink (every ASN would only need one prefix to cover its current and anticipated growth). So we'll see 220000 routes reduce to 25000. steve. > steve. >The technology we have now is not driving multihoming directly and v4 vs v6 is not a factor there. steve. > steve. >So in what way is v6 destroying DFZ? steve. > steve. >Steve steve. > steve. >On Fri, Jun 29, 2007 at 02:13:50PM +0000, Christian Kuhtz wrote: steve. >> steve. >> Amazink! Some things on NANOG _never_ change. Trawling for trolls I must be. steve. >> steve. >> If you want to emulate IPv4 and destroy the DFZ, yes, this is trivial. And you should go ahead and plan that migration. steve. >> steve. >> As you well known, one of the core assumptions of IPv6 is that the DFZ policy stay intact, ostensibly to solve a very specific scaling problem. steve. >> steve. >> So, go ahead and continue talking about migration while ignoring the very policies within which that is permitted to take place and don't let me interrupt that ranting. steve. >> steve. >> Best Regards, steve. >> Christian steve. >> steve. >> -- steve. >> Sent from my BlackBerry. steve. >> steve. >> -----Original Message----- steve. >> From: Stephen Wilcox <steve.wilcox@packetrade.com> steve. >> steve. >> Date: Fri, 29 Jun 2007 14:55:06 steve. >> To:Christian Kuhtz <kuhtzch@corp.earthlink.net> steve. >> Cc:Andy Davidson <andy@nosignal.org>, owner-nanog@merit.edu, Donald Stahl <don@calis.blacksun.org>, nanog@nanog.org steve. >> Subject: Re: The Choice: IPv4 Exhaustion or Transition to IPv6 steve. >> steve. >> steve. >> multihoming is simple, you get an address block and route it to your upstreams. steve. >> steve. >> the policy surrounding that is another debate, possibly for another group steve. >> steve. >> this thread is discussing how v4 to v6 migration can operate on a network level steve. >> steve. >> Steve steve. >> steve. >> On Fri, Jun 29, 2007 at 01:37:23PM +0000, Christian Kuhtz wrote: steve. >> > Until there's a practical solution for multihoming, this whole discussion is pretty pointless. steve. >> > steve. >> > -- steve. >> > Sent from my BlackBerry. steve. >> > steve. >> > -----Original Message----- steve. >> > From: Andy Davidson <andy@nosignal.org> steve. >> > steve. >> > Date: Fri, 29 Jun 2007 14:27:33 steve. >> > To:Donald Stahl <don@calis.blacksun.org> steve. >> > Cc:nanog@nanog.org steve. >> > Subject: Re: The Choice: IPv4 Exhaustion or Transition to IPv6 steve. >> > steve. >> > steve. >> > steve. >> > steve. >> > On 29 Jun 2007, at 14:24, Donald Stahl wrote: steve. >> > steve. >> > >> That's the thing .. google's crawlers and search app runs at layer steve. >> > >> 7, v6 is an addressing system that runs at layer 3. If we'd (the steve. >> > >> community) got everything right with v6, it wouldn't matter to steve. >> > >> Google's applications whether the content came from a site hosted steve. >> > >> on a v4 address, or a v6 address, or even both. steve. >> > > If Google does not have v6 connectivity then how are they going to steve. >> > > crawl those v6 sites? steve. >> > steve. >> > I think we're debating from very similar positions... steve. >> > steve. >> > v6 isn't the ideal scenario of '96 extra bits for free', because if steve. >> > life was so simple, we wouldn't need to ask this question. steve. >> > steve. >> > Andy steve. >> > steve. >
Hi Steve, Sure... I've never mention 3 STM4... the example said 3 carriers. OK, you may do it with communities, but if you advertise all in just one prefix, even with communities, I find it very difficult to control the trafic when it pass through 2 or more AS (it may be quite easy for the peer AS, but what about the other ASs)? Nicolas. On Fri, 29 Jun 2007, Stephen Wilcox wrote: steve. >Hi Nicolas, steve. > you will never make 2GB of traffic go down one STM4 or even 3x STM4! steve. > steve. >But you are asking me about load balancing amongst 3 upstreams... steve. > steve. >Deaggregation of your prefix is an ugly way to do TE. If you buy steve. >from carriers that support BGP communities there are much nicer steve. >ways to manage this. I've never deaggregated and I have had and do steve. >have individual prefixes that generate more traffic than any steve. >single GE link. steve. > steve. >Steve steve. > steve. >On Fri, Jun 29, 2007 at 12:11:58PM -0300, Nicolás Antoniello wrote: steve. >> Hi Stephen, steve. >> steve. >> Supose you have STM4 links, ok? steve. >> And you have 2G of trafic from your 100000 ADSL customers, ok? steve. >> And those STM4 go to 3 dif carriers in USA. steve. >> Then, how you advertise only one IPv6 prefix to all and make the 2G go steve. >> trough one STM4 ? steve. >> steve. >> steve. >> On Fri, 29 Jun 2007, Stephen Wilcox wrote: steve. >> steve. >> steve. > steve. >> steve. >Hi Christian, steve. >> steve. > I am not seeing how v4 exhaustion, transition to v6, multihoming in v6 and destruction ov DFZ are correlated. steve. >> steve. > steve. >> steve. >If you took everything on v4 today and migrated it to v6 tomoro the routing table would not grow - actually by my calculation it should shrink (every ASN would only need one prefix to cover its current and anticipated growth). So we'll see 220000 routes reduce to 25000. steve. >> steve. > steve. >> steve. >The technology we have now is not driving multihoming directly and v4 vs v6 is not a factor there. steve. >> steve. > steve. >> steve. >So in what way is v6 destroying DFZ? steve. >> steve. > steve. >> steve. >Steve steve. >> steve. > steve. >> steve. >On Fri, Jun 29, 2007 at 02:13:50PM +0000, Christian Kuhtz wrote: steve. >> steve. >> steve. >> steve. >> Amazink! Some things on NANOG _never_ change. Trawling for trolls I must be. steve. >> steve. >> steve. >> steve. >> If you want to emulate IPv4 and destroy the DFZ, yes, this is trivial. And you should go ahead and plan that migration. steve. >> steve. >> steve. >> steve. >> As you well known, one of the core assumptions of IPv6 is that the DFZ policy stay intact, ostensibly to solve a very specific scaling problem. steve. >> steve. >> steve. >> steve. >> So, go ahead and continue talking about migration while ignoring the very policies within which that is permitted to take place and don't let me interrupt that ranting. steve. >> steve. >> steve. >> steve. >> Best Regards, steve. >> steve. >> Christian steve. >> steve. >> steve. >> steve. >> -- steve. >> steve. >> Sent from my BlackBerry. steve. >> steve. >> steve. >> steve. >> -----Original Message----- steve. >> steve. >> From: Stephen Wilcox <steve.wilcox@packetrade.com> steve. >> steve. >> steve. >> steve. >> Date: Fri, 29 Jun 2007 14:55:06 steve. >> steve. >> To:Christian Kuhtz <kuhtzch@corp.earthlink.net> steve. >> steve. >> Cc:Andy Davidson <andy@nosignal.org>, owner-nanog@merit.edu, Donald Stahl <don@calis.blacksun.org>, nanog@nanog.org steve. >> steve. >> Subject: Re: The Choice: IPv4 Exhaustion or Transition to IPv6 steve. >> steve. >> steve. >> steve. >> steve. >> steve. >> multihoming is simple, you get an address block and route it to your upstreams. steve. >> steve. >> steve. >> steve. >> the policy surrounding that is another debate, possibly for another group steve. >> steve. >> steve. >> steve. >> this thread is discussing how v4 to v6 migration can operate on a network level steve. >> steve. >> steve. >> steve. >> Steve steve. >> steve. >> steve. >> steve. >> On Fri, Jun 29, 2007 at 01:37:23PM +0000, Christian Kuhtz wrote: steve. >> steve. >> > Until there's a practical solution for multihoming, this whole discussion is pretty pointless. steve. >> steve. >> > steve. >> steve. >> > -- steve. >> steve. >> > Sent from my BlackBerry. steve. >> steve. >> > steve. >> steve. >> > -----Original Message----- steve. >> steve. >> > From: Andy Davidson <andy@nosignal.org> steve. >> steve. >> > steve. >> steve. >> > Date: Fri, 29 Jun 2007 14:27:33 steve. >> steve. >> > To:Donald Stahl <don@calis.blacksun.org> steve. >> steve. >> > Cc:nanog@nanog.org steve. >> steve. >> > Subject: Re: The Choice: IPv4 Exhaustion or Transition to IPv6 steve. >> steve. >> > steve. >> steve. >> > steve. >> steve. >> > steve. >> steve. >> > steve. >> steve. >> > On 29 Jun 2007, at 14:24, Donald Stahl wrote: steve. >> steve. >> > steve. >> steve. >> > >> That's the thing .. google's crawlers and search app runs at layer steve. >> steve. >> > >> 7, v6 is an addressing system that runs at layer 3. If we'd (the steve. >> steve. >> > >> community) got everything right with v6, it wouldn't matter to steve. >> steve. >> > >> Google's applications whether the content came from a site hosted steve. >> steve. >> > >> on a v4 address, or a v6 address, or even both. steve. >> steve. >> > > If Google does not have v6 connectivity then how are they going to steve. >> steve. >> > > crawl those v6 sites? steve. >> steve. >> > steve. >> steve. >> > I think we're debating from very similar positions... steve. >> steve. >> > steve. >> steve. >> > v6 isn't the ideal scenario of '96 extra bits for free', because if steve. >> steve. >> > life was so simple, we wouldn't need to ask this question. steve. >> steve. >> > steve. >> steve. >> > Andy steve. >> steve. >> > steve. >> steve. > steve. >
Nicolás Antoniello wrote:
Hi Steve,
Sure... I've never mention 3 STM4... the example said 3 carriers.
OK, you may do it with communities, but if you advertise all in just one prefix, even with communities, I find it very difficult to control the trafic when it pass through 2 or more AS (it may be quite easy for the peer AS, but what about the other ASs)?
AS path prepend? It's a gross nob. But it's not like there's no precedent for it's use. joelja
Nicolas.
On Fri, 29 Jun 2007, Stephen Wilcox wrote:
steve. >Hi Nicolas, steve. > you will never make 2GB of traffic go down one STM4 or even 3x STM4! steve. > steve. >But you are asking me about load balancing amongst 3 upstreams... steve. > steve. >Deaggregation of your prefix is an ugly way to do TE. If you buy steve. >from carriers that support BGP communities there are much nicer steve. >ways to manage this. I've never deaggregated and I have had and do steve. >have individual prefixes that generate more traffic than any steve. >single GE link. steve. > steve. >Steve steve. > steve. >On Fri, Jun 29, 2007 at 12:11:58PM -0300, Nicolás Antoniello wrote: steve. >> Hi Stephen, steve. >> steve. >> Supose you have STM4 links, ok? steve. >> And you have 2G of trafic from your 100000 ADSL customers, ok? steve. >> And those STM4 go to 3 dif carriers in USA. steve. >> Then, how you advertise only one IPv6 prefix to all and make the 2G go steve. >> trough one STM4 ? steve. >> steve. >> steve. >> On Fri, 29 Jun 2007, Stephen Wilcox wrote: steve. >> steve. >> steve. > steve. >> steve. >Hi Christian, steve. >> steve. > I am not seeing how v4 exhaustion, transition to v6, multihoming in v6 and destruction ov DFZ are correlated. steve. >> steve. > steve. >> steve. >If you took everything on v4 today and migrated it to v6 tomoro the routing table would not grow - actually by my calculation it should shrink (every ASN would only need one prefix to cover its current and anticipated growth). So we'll see 220000 routes reduce to 25000. steve. >> steve. > steve. >> steve. >The technology we have now is not driving multihoming directly and v4 vs v6 is not a factor there. steve. >> steve. > steve. >> steve. >So in what way is v6 destroying DFZ? steve. >> steve. > steve. >> steve. >Steve steve. >> steve. > steve. >> steve. >On Fri, Jun 29, 2007 at 02:13:50PM +0000, Christian Kuhtz wrote: steve. >> steve. >> steve. >> steve. >> Amazink! Some things on NANOG _never_ change. Trawling for trolls I must be. steve. >> steve. >> steve. >> steve. >> If you want to emulate IPv4 and destroy the DFZ, yes, this is trivial. And you should go ahead and plan that migration. steve. >> steve. >> steve. >> steve. >> As you well known, one of the core assumptions of IPv6 is that the DFZ policy stay intact, ostensibly to solve a very specific scaling problem. steve. >> steve. >> steve. >> steve. >> So, go ahead and continue talking about migration while ignoring the very policies within which that is permitted to take place and don't let me interrupt that ranting. steve. >> steve. >> steve. >> steve. >> Best Regards, steve. >> steve. >> Christian steve. >> steve. >> steve. >> steve. >> -- steve. >> steve. >> Sent from my BlackBerry. steve. >> steve. >> steve. >> steve. >> -----Original Message----- steve. >> steve. >> From: Stephen Wilcox <steve.wilcox@packetrade.com> steve. >> steve. >> steve. >> steve. >> Date: Fri, 29 Jun 2007 14:55:06 steve. >> steve. >> To:Christian Kuhtz <kuhtzch@corp.earthlink.net> steve. >> steve. >> Cc:Andy Davidson <andy@nosignal.org>, owner-nanog@merit.edu, Donald Stahl <don@calis.blacksun.org>, nanog@nanog.org steve. >> steve. >> Subject: Re: The Choice: IPv4 Exhaustion or Transition to IPv6 steve. >> steve. >> steve. >> steve. >> steve. >> steve. >> multihoming is simple, you get an address block and route it to your upstreams. steve. >> steve. >> steve. >> steve. >> the policy surrounding that is another debate, possibly for another group steve. >> steve. >> steve. >> steve. >> this thread is discussing how v4 to v6 migration can operate on a network level steve. >> steve. >> steve. >> steve. >> Steve steve. >> steve. >> steve. >> steve. >> On Fri, Jun 29, 2007 at 01:37:23PM +0000, Christian Kuhtz wrote: steve. >> steve. >> > Until there's a practical solution for multihoming, this whole discussion is pretty pointless. steve. >> steve. >> > steve. >> steve. >> > -- steve. >> steve. >> > Sent from my BlackBerry. steve. >> steve. >> > steve. >> steve. >> > -----Original Message----- steve. >> steve. >> > From: Andy Davidson <andy@nosignal.org> steve. >> steve. >> > steve. >> steve. >> > Date: Fri, 29 Jun 2007 14:27:33 steve. >> steve. >> > To:Donald Stahl <don@calis.blacksun.org> steve. >> steve. >> > Cc:nanog@nanog.org steve. >> steve. >> > Subject: Re: The Choice: IPv4 Exhaustion or Transition to IPv6 steve. >> steve. >> > steve. >> steve. >> > steve. >> steve. >> > steve. >> steve. >> > steve. >> steve. >> > On 29 Jun 2007, at 14:24, Donald Stahl wrote: steve. >> steve. >> > steve. >> steve. >> > >> That's the thing .. google's crawlers and search app runs at layer steve. >> steve. >> > >> 7, v6 is an addressing system that runs at layer 3. If we'd (the steve. >> steve. >> > >> community) got everything right with v6, it wouldn't matter to steve. >> steve. >> > >> Google's applications whether the content came from a site hosted steve. >> steve. >> > >> on a v4 address, or a v6 address, or even both. steve. >> steve. >> > > If Google does not have v6 connectivity then how are they going to steve. >> steve. >> > > crawl those v6 sites? steve. >> steve. >> > steve. >> steve. >> > I think we're debating from very similar positions... steve. >> steve. >> > steve. >> steve. >> > v6 isn't the ideal scenario of '96 extra bits for free', because if steve. >> steve. >> > life was so simple, we wouldn't need to ask this question. steve. >> steve. >> > steve. >> steve. >> > Andy steve. >> steve. >> > steve. >> steve. > steve. >
Hi Joel, To use AS path prepend when you advertise just one prefix does not solve the problem...in this case it actually make it worth, 'cos you may find all your trafic coming from only one of your uplinks. Nicolas. On Fri, 29 Jun 2007, Joel Jaeggli wrote: joelja >Nicolás Antoniello wrote: joelja >> Hi Steve, joelja >> joelja >> Sure... I've never mention 3 STM4... the example said 3 carriers. joelja >> joelja >> OK, you may do it with communities, but if you advertise all in just one joelja >> prefix, even with communities, I find it very difficult to control the joelja >> trafic when it pass through 2 or more AS (it may be quite easy for the joelja >> peer AS, but what about the other ASs)? joelja > joelja >AS path prepend? joelja > joelja >It's a gross nob. But it's not like there's no precedent for it's use. joelja > joelja >joelja joelja > joelja >> Nicolas. joelja >> joelja >> joelja >> On Fri, 29 Jun 2007, Stephen Wilcox wrote: joelja >> joelja >> steve. >Hi Nicolas, joelja >> steve. > you will never make 2GB of traffic go down one STM4 or even 3x STM4! joelja >> steve. > joelja >> steve. >But you are asking me about load balancing amongst 3 upstreams... joelja >> steve. > joelja >> steve. >Deaggregation of your prefix is an ugly way to do TE. If you buy joelja >> steve. >from carriers that support BGP communities there are much nicer joelja >> steve. >ways to manage this. I've never deaggregated and I have had and do joelja >> steve. >have individual prefixes that generate more traffic than any joelja >> steve. >single GE link. joelja >> steve. > joelja >> steve. >Steve joelja >> steve. > joelja >> steve. >On Fri, Jun 29, 2007 at 12:11:58PM -0300, Nicolás Antoniello wrote: joelja >> steve. >> Hi Stephen, joelja >> steve. >> joelja >> steve. >> Supose you have STM4 links, ok? joelja >> steve. >> And you have 2G of trafic from your 100000 ADSL customers, ok? joelja >> steve. >> And those STM4 go to 3 dif carriers in USA. joelja >> steve. >> Then, how you advertise only one IPv6 prefix to all and make the 2G go joelja >> steve. >> trough one STM4 ? joelja >> steve. >> joelja >> steve. >> joelja >> steve. >> On Fri, 29 Jun 2007, Stephen Wilcox wrote: joelja >> steve. >> joelja >> steve. >> steve. > joelja >> steve. >> steve. >Hi Christian, joelja >> steve. >> steve. > I am not seeing how v4 exhaustion, transition to v6, multihoming in v6 and destruction ov DFZ are correlated. joelja >> steve. >> steve. > joelja >> steve. >> steve. >If you took everything on v4 today and migrated it to v6 tomoro the routing table would not grow - actually by my calculation it should shrink (every ASN would only need one prefix to cover its current and anticipated growth). So we'll see 220000 routes reduce to 25000. joelja >> steve. >> steve. > joelja >> steve. >> steve. >The technology we have now is not driving multihoming directly and v4 vs v6 is not a factor there. joelja >> steve. >> steve. > joelja >> steve. >> steve. >So in what way is v6 destroying DFZ? joelja >> steve. >> steve. > joelja >> steve. >> steve. >Steve joelja >> steve. >> steve. > joelja >> steve. >> steve. >On Fri, Jun 29, 2007 at 02:13:50PM +0000, Christian Kuhtz wrote: joelja >> steve. >> steve. >> joelja >> steve. >> steve. >> Amazink! Some things on NANOG _never_ change. Trawling for trolls I must be. joelja >> steve. >> steve. >> joelja >> steve. >> steve. >> If you want to emulate IPv4 and destroy the DFZ, yes, this is trivial. And you should go ahead and plan that migration. joelja >> steve. >> steve. >> joelja >> steve. >> steve. >> As you well known, one of the core assumptions of IPv6 is that the DFZ policy stay intact, ostensibly to solve a very specific scaling problem. joelja >> steve. >> steve. >> joelja >> steve. >> steve. >> So, go ahead and continue talking about migration while ignoring the very policies within which that is permitted to take place and don't let me interrupt that ranting. joelja >> steve. >> steve. >> joelja >> steve. >> steve. >> Best Regards, joelja >> steve. >> steve. >> Christian joelja >> steve. >> steve. >> joelja >> steve. >> steve. >> -- joelja >> steve. >> steve. >> Sent from my BlackBerry. joelja >> steve. >> steve. >> joelja >> steve. >> steve. >> -----Original Message----- joelja >> steve. >> steve. >> From: Stephen Wilcox <steve.wilcox@packetrade.com> joelja >> steve. >> steve. >> joelja >> steve. >> steve. >> Date: Fri, 29 Jun 2007 14:55:06 joelja >> steve. >> steve. >> To:Christian Kuhtz <kuhtzch@corp.earthlink.net> joelja >> steve. >> steve. >> Cc:Andy Davidson <andy@nosignal.org>, owner-nanog@merit.edu, Donald Stahl <don@calis.blacksun.org>, nanog@nanog.org joelja >> steve. >> steve. >> Subject: Re: The Choice: IPv4 Exhaustion or Transition to IPv6 joelja >> steve. >> steve. >> joelja >> steve. >> steve. >> joelja >> steve. >> steve. >> multihoming is simple, you get an address block and route it to your upstreams. joelja >> steve. >> steve. >> joelja >> steve. >> steve. >> the policy surrounding that is another debate, possibly for another group joelja >> steve. >> steve. >> joelja >> steve. >> steve. >> this thread is discussing how v4 to v6 migration can operate on a network level joelja >> steve. >> steve. >> joelja >> steve. >> steve. >> Steve joelja >> steve. >> steve. >> joelja >> steve. >> steve. >> On Fri, Jun 29, 2007 at 01:37:23PM +0000, Christian Kuhtz wrote: joelja >> steve. >> steve. >> > Until there's a practical solution for multihoming, this whole discussion is pretty pointless. joelja >> steve. >> steve. >> > joelja >> steve. >> steve. >> > -- joelja >> steve. >> steve. >> > Sent from my BlackBerry. joelja >> steve. >> steve. >> > joelja >> steve. >> steve. >> > -----Original Message----- joelja >> steve. >> steve. >> > From: Andy Davidson <andy@nosignal.org> joelja >> steve. >> steve. >> > joelja >> steve. >> steve. >> > Date: Fri, 29 Jun 2007 14:27:33 joelja >> steve. >> steve. >> > To:Donald Stahl <don@calis.blacksun.org> joelja >> steve. >> steve. >> > Cc:nanog@nanog.org joelja >> steve. >> steve. >> > Subject: Re: The Choice: IPv4 Exhaustion or Transition to IPv6 joelja >> steve. >> steve. >> > joelja >> steve. >> steve. >> > joelja >> steve. >> steve. >> > joelja >> steve. >> steve. >> > joelja >> steve. >> steve. >> > On 29 Jun 2007, at 14:24, Donald Stahl wrote: joelja >> steve. >> steve. >> > joelja >> steve. >> steve. >> > >> That's the thing .. google's crawlers and search app runs at layer joelja >> steve. >> steve. >> > >> 7, v6 is an addressing system that runs at layer 3. If we'd (the joelja >> steve. >> steve. >> > >> community) got everything right with v6, it wouldn't matter to joelja >> steve. >> steve. >> > >> Google's applications whether the content came from a site hosted joelja >> steve. >> steve. >> > >> on a v4 address, or a v6 address, or even both. joelja >> steve. >> steve. >> > > If Google does not have v6 connectivity then how are they going to joelja >> steve. >> steve. >> > > crawl those v6 sites? joelja >> steve. >> steve. >> > joelja >> steve. >> steve. >> > I think we're debating from very similar positions... joelja >> steve. >> steve. >> > joelja >> steve. >> steve. >> > v6 isn't the ideal scenario of '96 extra bits for free', because if joelja >> steve. >> steve. >> > life was so simple, we wouldn't need to ask this question. joelja >> steve. >> steve. >> > joelja >> steve. >> steve. >> > Andy joelja >> steve. >> steve. >> > joelja >> steve. >> steve. > joelja >> steve. > joelja >
No, I specifically said you need to buy from upstreams who support BGP communities. You do not prepend to your upstreams but have them prepend to their peers such that you adjust which are selected to get the appropriate ratio on your inbound Steve On Fri, Jun 29, 2007 at 02:46:00PM -0300, Nicolás Antoniello wrote:
Hi Joel,
To use AS path prepend when you advertise just one prefix does not solve the problem...in this case it actually make it worth, 'cos you may find all your trafic coming from only one of your uplinks.
Nicolas.
On Fri, 29 Jun 2007, Joel Jaeggli wrote:
joelja >Nicolás Antoniello wrote: joelja >> Hi Steve, joelja >> joelja >> Sure... I've never mention 3 STM4... the example said 3 carriers. joelja >> joelja >> OK, you may do it with communities, but if you advertise all in just one joelja >> prefix, even with communities, I find it very difficult to control the joelja >> trafic when it pass through 2 or more AS (it may be quite easy for the joelja >> peer AS, but what about the other ASs)? joelja > joelja >AS path prepend? joelja > joelja >It's a gross nob. But it's not like there's no precedent for it's use. joelja > joelja >joelja joelja > joelja >> Nicolas. joelja >> joelja >> joelja >> On Fri, 29 Jun 2007, Stephen Wilcox wrote: joelja >> joelja >> steve. >Hi Nicolas, joelja >> steve. > you will never make 2GB of traffic go down one STM4 or even 3x STM4! joelja >> steve. > joelja >> steve. >But you are asking me about load balancing amongst 3 upstreams... joelja >> steve. > joelja >> steve. >Deaggregation of your prefix is an ugly way to do TE. If you buy joelja >> steve. >from carriers that support BGP communities there are much nicer joelja >> steve. >ways to manage this. I've never deaggregated and I have had and do joelja >> steve. >have individual prefixes that generate more traffic than any joelja >> steve. >single GE link. joelja >> steve. > joelja >> steve. >Steve joelja >> steve. > joelja >> steve. >On Fri, Jun 29, 2007 at 12:11:58PM -0300, Nicolás Antoniello wrote: joelja >> steve. >> Hi Stephen, joelja >> steve. >> joelja >> steve. >> Supose you have STM4 links, ok? joelja >> steve. >> And you have 2G of trafic from your 100000 ADSL customers, ok? joelja >> steve. >> And those STM4 go to 3 dif carriers in USA. joelja >> steve. >> Then, how you advertise only one IPv6 prefix to all and make the 2G go joelja >> steve. >> trough one STM4 ? joelja >> steve. >> joelja >> steve. >> joelja >> steve. >> On Fri, 29 Jun 2007, Stephen Wilcox wrote: joelja >> steve. >> joelja >> steve. >> steve. > joelja >> steve. >> steve. >Hi Christian, joelja >> steve. >> steve. > I am not seeing how v4 exhaustion, transition to v6, multihoming in v6 and destruction ov DFZ are correlated. joelja >> steve. >> steve. > joelja >> steve. >> steve. >If you took everything on v4 today and migrated it to v6 tomoro the routing table would not grow - actually by my calculation it should shrink (every ASN would only need one prefix to cover its current and anticipated growth). So we'll see 220000 routes reduce to 25000. joelja >> steve. >> steve. > joelja >> steve. >> steve. >The technology we have now is not driving multihoming directly and v4 vs v6 is not a factor there. joelja >> steve. >> steve. > joelja >> steve. >> steve. >So in what way is v6 destroying DFZ? joelja >> steve. >> steve. > joelja >> steve. >> steve. >Steve joelja >> steve. >> steve. > joelja >> steve. >> steve. >On Fri, Jun 29, 2007 at 02:13:50PM +0000, Christian Kuhtz wrote: joelja >> steve. >> steve. >> joelja >> steve. >> steve. >> Amazink! Some things on NANOG _never_ change. Trawling for trolls I must be. joelja >> steve. >> steve. >> joelja >> steve. >> steve. >> If you want to emulate IPv4 and destroy the DFZ, yes, this is trivial. And you should go ahead and plan that migration. joelja >> steve. >> steve. >> joelja >> steve. >> steve. >> As you well known, one of the core assumptions of IPv6 is that the DFZ policy stay intact, ostensibly to solve a very specific scaling problem. joelja >> steve. >> steve. >> joelja >> steve. >> steve. >> So, go ahead and continue talking about migration while ignoring the very policies within which that is permitted to take place and don't let me interrupt that ranting. joelja >> steve. >> steve. >> joelja >> steve. >> steve. >> Best Regards, joelja >> steve. >> steve. >> Christian joelja >> steve. >> steve. >> joelja >> steve. >> steve. >> -- joelja >> steve. >> steve. >> Sent from my BlackBerry. joelja >> steve. >> steve. >> joelja >> steve. >> steve. >> -----Original Message----- joelja >> steve. >> steve. >> From: Stephen Wilcox <steve.wilcox@packetrade.com> joelja >> steve. >> steve. >> joelja >> steve. >> steve. >> Date: Fri, 29 Jun 2007 14:55:06 joelja >> steve. >> steve. >> To:Christian Kuhtz <kuhtzch@corp.earthlink.net> joelja >> steve. >> steve. >> Cc:Andy Davidson <andy@nosignal.org>, owner-nanog@merit.edu, Donald Stahl <don@calis.blacksun.org>, nanog@nanog.org joelja >> steve. >> steve. >> Subject: Re: The Choice: IPv4 Exhaustion or Transition to IPv6 joelja >> steve. >> steve. >> joelja >> steve. >> steve. >> joelja >> steve. >> steve. >> multihoming is simple, you get an address block and route it to your upstreams. joelja >> steve. >> steve. >> joelja >> steve. >> steve. >> the policy surrounding that is another debate, possibly for another group joelja >> steve. >> steve. >> joelja >> steve. >> steve. >> this thread is discussing how v4 to v6 migration can operate on a network level joelja >> steve. >> steve. >> joelja >> steve. >> steve. >> Steve joelja >> steve. >> steve. >> joelja >> steve. >> steve. >> On Fri, Jun 29, 2007 at 01:37:23PM +0000, Christian Kuhtz wrote: joelja >> steve. >> steve. >> > Until there's a practical solution for multihoming, this whole discussion is pretty pointless. joelja >> steve. >> steve. >> > joelja >> steve. >> steve. >> > -- joelja >> steve. >> steve. >> > Sent from my BlackBerry. joelja >> steve. >> steve. >> > joelja >> steve. >> steve. >> > -----Original Message----- joelja >> steve. >> steve. >> > From: Andy Davidson <andy@nosignal.org> joelja >> steve. >> steve. >> > joelja >> steve. >> steve. >> > Date: Fri, 29 Jun 2007 14:27:33 joelja >> steve. >> steve. >> > To:Donald Stahl <don@calis.blacksun.org> joelja >> steve. >> steve. >> > Cc:nanog@nanog.org joelja >> steve. >> steve. >> > Subject: Re: The Choice: IPv4 Exhaustion or Transition to IPv6 joelja >> steve. >> steve. >> > joelja >> steve. >> steve. >> > joelja >> steve. >> steve. >> > joelja >> steve. >> steve. >> > joelja >> steve. >> steve. >> > On 29 Jun 2007, at 14:24, Donald Stahl wrote: joelja >> steve. >> steve. >> > joelja >> steve. >> steve. >> > >> That's the thing .. google's crawlers and search app runs at layer joelja >> steve. >> steve. >> > >> 7, v6 is an addressing system that runs at layer 3. If we'd (the joelja >> steve. >> steve. >> > >> community) got everything right with v6, it wouldn't matter to joelja >> steve. >> steve. >> > >> Google's applications whether the content came from a site hosted joelja >> steve. >> steve. >> > >> on a v4 address, or a v6 address, or even both. joelja >> steve. >> steve. >> > > If Google does not have v6 connectivity then how are they going to joelja >> steve. >> steve. >> > > crawl those v6 sites? joelja >> steve. >> steve. >> > joelja >> steve. >> steve. >> > I think we're debating from very similar positions... joelja >> steve. >> steve. >> > joelja >> steve. >> steve. >> > v6 isn't the ideal scenario of '96 extra bits for free', because if joelja >> steve. >> steve. >> > life was so simple, we wouldn't need to ask this question. joelja >> steve. >> steve. >> > joelja >> steve. >> steve. >> > Andy joelja >> steve. >> steve. >> > joelja >> steve. >> steve. > joelja >> steve. > joelja >
Nicolás Antoniello wrote:
Hi Joel,
To use AS path prepend when you advertise just one prefix does not solve the problem...in this case it actually make it worth, 'cos you may find all your trafic coming from only one of your uplinks.
Sure if you overdo it... Like I said It's a fairly gross knob. you're attempting to manipulate the path selection algorithm of autonomous systems you're not directly connected to. Your upstream may offer knobs in the form of communities that you can use to do prepending on their peers. which gives you a lot more exits to control... I'll pick on savvis because their attributes came up first in google. http://savvis-rr.savvis.net/Routing_Registry/community_receive.htm I think the subtext of what you were saying was that you needed to de-agregate down /24 in order to do proper traffic engineering and that is manifestly untrue despite what some network operators seem to believe. joelja
Nicolas.
On Fri, 29 Jun 2007, Joel Jaeggli wrote:
joelja >Nicolás Antoniello wrote: joelja >> Hi Steve, joelja >> joelja >> Sure... I've never mention 3 STM4... the example said 3 carriers. joelja >> joelja >> OK, you may do it with communities, but if you advertise all in just one joelja >> prefix, even with communities, I find it very difficult to control the joelja >> trafic when it pass through 2 or more AS (it may be quite easy for the joelja >> peer AS, but what about the other ASs)? joelja > joelja >AS path prepend? joelja > joelja >It's a gross nob. But it's not like there's no precedent for it's use. joelja > joelja >joelja joelja > joelja >> Nicolas. joelja >> joelja >> joelja >> On Fri, 29 Jun 2007, Stephen Wilcox wrote: joelja >> joelja >> steve. >Hi Nicolas, joelja >> steve. > you will never make 2GB of traffic go down one STM4 or even 3x STM4! joelja >> steve. > joelja >> steve. >But you are asking me about load balancing amongst 3 upstreams... joelja >> steve. > joelja >> steve. >Deaggregation of your prefix is an ugly way to do TE. If you buy joelja >> steve. >from carriers that support BGP communities there are much nicer joelja >> steve. >ways to manage this. I've never deaggregated and I have had and do joelja >> steve. >have individual prefixes that generate more traffic than any joelja >> steve. >single GE link. joelja >> steve. > joelja >> steve. >Steve joelja >> steve. > joelja >> steve. >On Fri, Jun 29, 2007 at 12:11:58PM -0300, Nicolás Antoniello wrote: joelja >> steve. >> Hi Stephen, joelja >> steve. >> joelja >> steve. >> Supose you have STM4 links, ok? joelja >> steve. >> And you have 2G of trafic from your 100000 ADSL customers, ok? joelja >> steve. >> And those STM4 go to 3 dif carriers in USA. joelja >> steve. >> Then, how you advertise only one IPv6 prefix to all and make the 2G go joelja >> steve. >> trough one STM4 ? joelja >> steve. >> joelja >> steve. >> joelja >> steve. >> On Fri, 29 Jun 2007, Stephen Wilcox wrote: joelja >> steve. >> joelja >> steve. >> steve. > joelja >> steve. >> steve. >Hi Christian, joelja >> steve. >> steve. > I am not seeing how v4 exhaustion, transition to v6, multihoming in v6 and destruction ov DFZ are correlated. joelja >> steve. >> steve. > joelja >> steve. >> steve. >If you took everything on v4 today and migrated it to v6 tomoro the routing table would not grow - actually by my calculation it should shrink (every ASN would only need one prefix to cover its current and anticipated growth). So we'll see 220000 routes reduce to 25000. joelja >> steve. >> steve. > joelja >> steve. >> steve. >The technology we have now is not driving multihoming directly and v4 vs v6 is not a factor there. joelja >> steve. >> steve. > joelja >> steve. >> steve. >So in what way is v6 destroying DFZ? joelja >> steve. >> steve. > joelja >> steve. >> steve. >Steve joelja >> steve. >> steve. > joelja >> steve. >> steve. >On Fri, Jun 29, 2007 at 02:13:50PM +0000, Christian Kuhtz wrote: joelja >> steve. >> steve. >> joelja >> steve. >> steve. >> Amazink! Some things on NANOG _never_ change. Trawling for trolls I must be. joelja >> steve. >> steve. >> joelja >> steve. >> steve. >> If you want to emulate IPv4 and destroy the DFZ, yes, this is trivial. And you should go ahead and plan that migration. joelja >> steve. >> steve. >> joelja >> steve. >> steve. >> As you well known, one of the core assumptions of IPv6 is that the DFZ policy stay intact, ostensibly to solve a very specific scaling problem. joelja >> steve. >> steve. >> joelja >> steve. >> steve. >> So, go ahead and continue talking about migration while ignoring the very policies within which that is permitted to take place and don't let me interrupt that ranting. joelja >> steve. >> steve. >> joelja >> steve. >> steve. >> Best Regards, joelja >> steve. >> steve. >> Christian joelja >> steve. >> steve. >> joelja >> steve. >> steve. >> -- joelja >> steve. >> steve. >> Sent from my BlackBerry. joelja >> steve. >> steve. >> joelja >> steve. >> steve. >> -----Original Message----- joelja >> steve. >> steve. >> From: Stephen Wilcox <steve.wilcox@packetrade.com> joelja >> steve. >> steve. >> joelja >> steve. >> steve. >> Date: Fri, 29 Jun 2007 14:55:06 joelja >> steve. >> steve. >> To:Christian Kuhtz <kuhtzch@corp.earthlink.net> joelja >> steve. >> steve. >> Cc:Andy Davidson <andy@nosignal.org>, owner-nanog@merit.edu, Donald Stahl <don@calis.blacksun.org>, nanog@nanog.org joelja >> steve. >> steve. >> Subject: Re: The Choice: IPv4 Exhaustion or Transition to IPv6 joelja >> steve. >> steve. >> joelja >> steve. >> steve. >> joelja >> steve. >> steve. >> multihoming is simple, you get an address block and route it to your upstreams. joelja >> steve. >> steve. >> joelja >> steve. >> steve. >> the policy surrounding that is another debate, possibly for another group joelja >> steve. >> steve. >> joelja >> steve. >> steve. >> this thread is discussing how v4 to v6 migration can operate on a network level joelja >> steve. >> steve. >> joelja >> steve. >> steve. >> Steve joelja >> steve. >> steve. >> joelja >> steve. >> steve. >> On Fri, Jun 29, 2007 at 01:37:23PM +0000, Christian Kuhtz wrote: joelja >> steve. >> steve. >> > Until there's a practical solution for multihoming, this whole discussion is pretty pointless. joelja >> steve. >> steve. >> > joelja >> steve. >> steve. >> > -- joelja >> steve. >> steve. >> > Sent from my BlackBerry. joelja >> steve. >> steve. >> > joelja >> steve. >> steve. >> > -----Original Message----- joelja >> steve. >> steve. >> > From: Andy Davidson <andy@nosignal.org> joelja >> steve. >> steve. >> > joelja >> steve. >> steve. >> > Date: Fri, 29 Jun 2007 14:27:33 joelja >> steve. >> steve. >> > To:Donald Stahl <don@calis.blacksun.org> joelja >> steve. >> steve. >> > Cc:nanog@nanog.org joelja >> steve. >> steve. >> > Subject: Re: The Choice: IPv4 Exhaustion or Transition to IPv6 joelja >> steve. >> steve. >> > joelja >> steve. >> steve. >> > joelja >> steve. >> steve. >> > joelja >> steve. >> steve. >> > joelja >> steve. >> steve. >> > On 29 Jun 2007, at 14:24, Donald Stahl wrote: joelja >> steve. >> steve. >> > joelja >> steve. >> steve. >> > >> That's the thing .. google's crawlers and search app runs at layer joelja >> steve. >> steve. >> > >> 7, v6 is an addressing system that runs at layer 3. If we'd (the joelja >> steve. >> steve. >> > >> community) got everything right with v6, it wouldn't matter to joelja >> steve. >> steve. >> > >> Google's applications whether the content came from a site hosted joelja >> steve. >> steve. >> > >> on a v4 address, or a v6 address, or even both. joelja >> steve. >> steve. >> > > If Google does not have v6 connectivity then how are they going to joelja >> steve. >> steve. >> > > crawl those v6 sites? joelja >> steve. >> steve. >> > joelja >> steve. >> steve. >> > I think we're debating from very similar positions... joelja >> steve. >> steve. >> > joelja >> steve. >> steve. >> > v6 isn't the ideal scenario of '96 extra bits for free', because if joelja >> steve. >> steve. >> > life was so simple, we wouldn't need to ask this question. joelja >> steve. >> steve. >> > joelja >> steve. >> steve. >> > Andy joelja >> steve. >> steve. >> > joelja >> steve. >> steve. > joelja >> steve. > joelja >
On Fri, 29 Jun 2007, [ISO-8859-1] Nicol�s Antoniello wrote:
To use AS path prepend when you advertise just one prefix does not solve the problem...in this case it actually make it worth, 'cos you may find all your trafic coming from only one of your uplinks.
Despite being a v6 skeptic, I'm not sure I understand what the issue is here. Lots of networks multihome with only single v4 prefixes. In general, different upsteram providers are close to different portions of the Internet, so you end up with some traffic coming on each connection. If there's a serious imbalance, it's usually somewhat adjustable with AS path prepending, and if that doesn't work it probably means you should have a more diverse set of upstream providers. No, you don't get as much granularity as you do when adjusting outbound traffic flows, or as much as you'd get by manipulating lots of little announcements, but it's often close enough.
[ As it is Friday: IPv4 doomsday clock: http://penrose.uk6x.com/ ] Christian Kuhtz wrote:
If you want to emulate IPv4 and destroy the DFZ, yes, this is trivial. And you should go ahead and plan that migration.
As you well known, one of the core assumptions of IPv6 is that the DFZ policy stay intact, ostensibly to solve a very specific scaling problem.
So, go ahead and continue talking about migration while ignoring the very policies within which that is permitted to take place and don't let me interrupt that ranting.
Actually the policies that are in place at the various RIR's are still quite strict as not every endsite that actually would want to get address space can apparently get it (In ARIN you need >/22 IPv4 for instance and some other rules). These policies have been chosen by their membership, or did you not agree with these policies? If you don't raise that on ppml@. Nevertheless, even if everybody could get a prefix with ease, then it would still not become a big problem quickly as several routing vendors have already announced that they are currently able to handle 2M routes in their current gear. I know that is only a factor 10 over IPv4 (assuming 200k routes) but that is quite a bit of time we have have left before that fills up completely. Note also that IPv6 only has 800 routes at the moment, compare that to the 200k in IPv6. This definitely has to grow quite a bit still, but I would not be surprised if it sticks below 50k with ease for the coming years. When we do really reach the maximums of that hardware though, we are down the road another 10 years. In that timeframe, id/loc mechanisms will have hopefully been developed and also nicely been made available to a lot of hard/software around the world. [..]
Sent from my BlackBerry.
I guess NANOG is really important ;) Now if that line would contain "Sent from my pico computer that I built myself" or something in that area, or then at least added something like ".. as I am in the pub, not working and drinking beer", then I would like it quite a bit more ;) Greets, Jeroen
Christian, On Jun 29, 2007, at 10:13 AM, Christian Kuhtz wrote:
If you want to emulate IPv4
Given IPv6 is IPv4 with 96 more bits (or, if you prefer 16 more bits from the ISP perspective), why would you assume there is a choice?
and destroy the DFZ,
I'm not sure what "destroy the DFZ" means. The DFZ will get bigger, no question. Routing flux will go up. Routers will have to work harder. Router vendors will be happy. However, I'm not sure how that could be interpreted as "destroyed". Just call it the Everglades and move on. Yes, it sucks and is painfully stupid, but we've been here before around the mid 90's. Same solutions apply. In any event, the IPv4 free pool will be exhausted "soon". We're looking at gobs of NAT or vast tracts of swamp. Actually most likely both. You ready? Rgds, -drc
On 29-jun-2007, at 17:05, David Conrad wrote:
and destroy the DFZ,
I'm not sure what "destroy the DFZ" means. The DFZ will get bigger, no question. Routing flux will go up. Routers will have to work harder. Router vendors will be happy. However, I'm not sure how that could be interpreted as "destroyed".
Ok, explain this to me. Router capacity will grow. The number of routing table entries will grow. How do we know that the latter growth is necessarily slower than the former? And if we can't know that in the current situation, isn't the responsible path forward one towards the situation where we CAN know that?
steve. >multihoming is simple, you get an address block and route it to your upstreams Hey, that's a very "simplistic" IGP point of view !! I'm afraid I disagree :) On Fri, 29 Jun 2007, Stephen Wilcox wrote: steve. > steve. >multihoming is simple, you get an address block and route it to your upstreams. steve. > steve. >the policy surrounding that is another debate, possibly for another group steve. > steve. >this thread is discussing how v4 to v6 migration can operate on a network level steve. > steve. >Steve steve. > steve. >On Fri, Jun 29, 2007 at 01:37:23PM +0000, Christian Kuhtz wrote: steve. >> Until there's a practical solution for multihoming, this whole discussion is pretty pointless. steve. >> steve. >> -- steve. >> Sent from my BlackBerry. steve. >> steve. >> -----Original Message----- steve. >> From: Andy Davidson <andy@nosignal.org> steve. >> steve. >> Date: Fri, 29 Jun 2007 14:27:33 steve. >> To:Donald Stahl <don@calis.blacksun.org> steve. >> Cc:nanog@nanog.org steve. >> Subject: Re: The Choice: IPv4 Exhaustion or Transition to IPv6 steve. >> steve. >> steve. >> steve. >> steve. >> On 29 Jun 2007, at 14:24, Donald Stahl wrote: steve. >> steve. >> >> That's the thing .. google's crawlers and search app runs at layer steve. >> >> 7, v6 is an addressing system that runs at layer 3. If we'd (the steve. >> >> community) got everything right with v6, it wouldn't matter to steve. >> >> Google's applications whether the content came from a site hosted steve. >> >> on a v4 address, or a v6 address, or even both. steve. >> > If Google does not have v6 connectivity then how are they going to steve. >> > crawl those v6 sites? steve. >> steve. >> I think we're debating from very similar positions... steve. >> steve. >> v6 isn't the ideal scenario of '96 extra bits for free', because if steve. >> life was so simple, we wouldn't need to ask this question. steve. >> steve. >> Andy steve. >> steve. >
Christian, On Jun 29, 2007, at 9:37 AM, Christian Kuhtz wrote:
Until there's a practical solution for multihoming, this whole discussion is pretty pointless
The fact that a practical multihoming solution for IPv6 does not exist doesn't mean that the IPv4 free pool will not be exhausted. Rgds, -drc
In ARIN you have a policy to request IPv6 PI. So what is the problem ? Regards, Jordi
De: Christian Kuhtz <kuhtzch@corp.earthlink.net> Responder a: <owner-nanog@merit.edu> Fecha: Fri, 29 Jun 2007 13:37:23 +0000 Para: Andy Davidson <andy@nosignal.org>, <owner-nanog@merit.edu>, Donald Stahl <don@calis.blacksun.org> CC: <nanog@nanog.org> Asunto: Re: The Choice: IPv4 Exhaustion or Transition to IPv6
Until there's a practical solution for multihoming, this whole discussion is pretty pointless.
-- Sent from my BlackBerry.
-----Original Message----- From: Andy Davidson <andy@nosignal.org>
Date: Fri, 29 Jun 2007 14:27:33 To:Donald Stahl <don@calis.blacksun.org> Cc:nanog@nanog.org Subject: Re: The Choice: IPv4 Exhaustion or Transition to IPv6
On 29 Jun 2007, at 14:24, Donald Stahl wrote:
That's the thing .. google's crawlers and search app runs at layer 7, v6 is an addressing system that runs at layer 3. If we'd (the community) got everything right with v6, it wouldn't matter to Google's applications whether the content came from a site hosted on a v4 address, or a v6 address, or even both. If Google does not have v6 connectivity then how are they going to crawl those v6 sites?
I think we're debating from very similar positions...
v6 isn't the ideal scenario of '96 extra bits for free', because if life was so simple, we wouldn't need to ask this question.
Andy
********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
On 28-jun-2007, at 18:51, John Curran wrote:
If you have a plan for continued operation of the Internet during IPv4 depletion, please write it up as an RFC. Our present Internet routing scheme is predominantly working based on hierarchical routing but I'm certain there are alternatives.
How about this: when the OS only has an IPv6 address, and an application wants to talk to an IPv4-only destination, automatically proxy the TCP session through an HTTPS proxy. This catches anything that uses TCP and doesn't need to know its own IPv4 address (hard to know if you don't have one) which would be upwards of 95% of all protocols in widespread use. So we only have to fix that other 5%.
Thus spake "Iljitsch van Beijnum" <iljitsch@muada.com>
How about this: when the OS only has an IPv6 address, and an application wants to talk to an IPv4-only destination, automatically proxy the TCP session through an HTTPS proxy. This catches anything that uses TCP and doesn't need to know its own IPv4 address (hard to know if you don't have one) which would be upwards of 95% of all protocols in widespread use. So we only have to fix that other 5%.
If you're going to go that route, you might as well just deploy a v6-to-v4 NAT device. It'll break all the same protocols (though you could add ALG code for popular ones if desired) and, for those that won't, doesn't require any end host or application knowledge of what's going on. I've bounced around some ideas privately on how such devices would work, probably have it defined well enough now to make a draft, and even managed to come up with a snappy backronym for it, but the IETF does not appear to be interested in any v6 transition model that doesn't require dual-stacking every single existing host on the Internet before the first v6-only host appears -- and certainly not one that's an adaptation of that evil NAT stuff. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov
Date: Thu, 28 Jun 2007 17:42:47 +0100 From: Stephen Wilcox <steve.wilcox@packetrade.com> Sender: owner-nanog@merit.edu
Hi John, I wasnt specifically thinking of reclamation of space, I was noting a couple of things:
- that less than 50% of the v4 space is currently routed. scarcity will presumably cause these non-routed blocks to be: :- used and routes :- reclaimed and reassigned :- sold on
Some of it, but a large part of the "missing" space belongs to the US Government, mostly the military. It is very much in use and is routed carefully such that it does not show up in the public Internet. It might be replaced with RFC1918 space, but I'm not sure that there is enough 1918 space to do the job as the address space needed is quite large. Also, some is used where 1918 space certainly could be used, but I have spoken with those responsible to ask them to move to 1918 space and the answer is an unequivocal "NO", not now or ever. I don't understand this, but I know it exists. One research lab has multiple /16s and several are used by classified nets that lack any external connectivity. While these are wasted, getting them back is essentially impossible.
- that much of the space in use within organisations could be optimised :- mop up unused gaps in subnet :- return IPs to the org's pool by forcing departments onto NATs
Pushing to NAT is on the face of it similar to pushing for early adoption of v6 whereby v6-v4 gateways provide a translation. However the technology for NATs is well established, widely deployed, cheap and very understandable to any IT guy.
You also refer to routing table size. The current routing table is growing quickly but people have been predicting the tables will outgrow the technology for many years but in each case new hardware gets released and on modern routers we can take significant growth (400%?).
Not really. See the presentations by the major router vendors on FIB size from NANOG39 in Toronto at <http://www.nanog.org/mtg-0702/jaeggli.html>. Most large network operators are truly frightened at the prospect of what we are facing. There are some very real issues beyond adding more TCAM. Issues that IPv6 will probably make worse. Right now the available TCAM is mostly allocated to IPv4 unicast and very little to IPv6. If the IPv6 table gets very large (and each IPv6 entry takes up four times the space in TCAM as an IPv4 entry), the choice is rather painful.
I dont believe routing table size comes into play in this, the simple reason is that whatever we say there will always be companies willing to take routes for money and it doesnt matter who or where they are because the rest of the world just has to route it.
I dont think that hierarchical routing will ever be a reality in todays diverse internet backbone, to not be a top tier carrier with your own ASN, and a full set of routes means you are closing your doors on selling transit. There are many thousand organisations making money from that, I cant see 99% of them bowing out gracefully to leave a few 'tier1s' behind.. that would be like turning back the clock 15 years.
In the current routing schemes there is a large issue here. Hierarchical routing simply won't do the job in a global fashion, but there is work going on on new techniques that could deal with this. Vince Fuller, Dave Meyer, Dave Oran, and Dino Farinacci presented an approach at the last NANOG: <http://www.nanog.org/mtg-0706/Presentations/lightning-farinacci.pdf> They are not the only ones working on resolving this issue. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Kevin Oberman wrote: <SNIP>
While these are wasted, getting them back is essentially impossible.
The term wasted is being used way to freely on this list. If by waste you mean: To use, consume, spend, or expend thoughtlessly or carelessly. Then I have to disagree. If you mean they (unannounced addresses) are being underutilized. Then say so. Note that even the current ARIN NRPM can be used a basis for assigning addresses based on need that are not intended to be announced (4.3.5) it does assume that they will be routed but not where they will be routed to.
Kevin Oberman wrote:
From: Stephen Wilcox <steve.wilcox@packetrade.com>
I wasnt specifically thinking of reclamation of space, I was noting a couple of things:
- that less than 50% of the v4 space is currently routed. scarcity will presumably cause these non-routed blocks to be: :- used and routes :- reclaimed and reassigned :- sold on
Some of it, but a large part of the "missing" space belongs to the US Government, mostly the military. It is very much in use and is routed carefully such that it does not show up in the public Internet.
There's another set of missing space, here. It seems to be the elephant in the room. While I can't (or won't) speak to the routing issues mentioned in the thread, I wonder that no one has brought up all the legacy space that is held by a few large conglomerates. No, I'm not talking about AT&T, here. I refer to the early days, when class B networks were handed out like penny candy, and when organizations could get class C space equivalent to a class B. When Company A has, say, 5 or 6 of those, and then acquires Company B, and then C and D, and all of them have that same allotment, it becomes a non-trivial amount of space. If there's really only 5 or 6 big companies, where there used to be 50 or so, we are suddenly talking about a non-trivial amount of space. Unfortunately, there's no good way to make them give it up. When you can see that they could easily make do with a single /8 (or less), it's rather sad that we don't have a mechanism in place that punishes for greed, and rewards for surrender of unused (or at least completely unnecessary) space. I only know about the industry I came from, of course, and I suspect that the lion's share of over-allocation is in it. I rather doubt that such things as banking, which came late to the table, have that characteristic. I know it's not a permanent answer, but it seems that (unlike the black space over on milnet et al) there's a temporary reprieve to exhaustion in there somewhere. -- The more sand has escaped from the hourglass of our life, the clearer we should see through it. Niccolo Machiavelli
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Kevin Oberman Sent: Thursday, June 28, 2007 1:15 PM To: Stephen Wilcox Cc: John Curran; nanog@nanog.org Subject: Re: The Choice: IPv4 Exhaustion or Transition to IPv6
Date: Thu, 28 Jun 2007 17:42:47 +0100 From: Stephen Wilcox <steve.wilcox@packetrade.com> Sender: owner-nanog@merit.edu
Hi John, I wasnt specifically thinking of reclamation of space, I was noting a couple of things:
- that less than 50% of the v4 space is currently routed. scarcity will presumably cause these non-routed blocks to be: :- used and routes :- reclaimed and reassigned :- sold on
Some of it, but a large part of the "missing" space belongs to the US Government, mostly the military. It is very much in use and is routed carefully such that it does not show up in the public Internet. It might be replaced with RFC1918 space, but I'm not sure that there is enough 1918 space to do the job as the address space needed is quite large. Also, some is used where 1918 space certainly could be used, but I have spoken with those responsible to ask them to move to 1918 space and the answer is an unequivocal "NO", not now or ever. I don't understand this, but I know it exists. One research lab has multiple /16s and several are used by classified nets that lack any external connectivity. While these are wasted, getting them back is essentially impossible. ------------------------------------------------------------------- Sorry for the horrid formatting, but LookOut is corp. standard. As for your claim that these are wasted, I take issue with this. I have connectivity to several different classified networks, and all of them are segregated, but they DO have gateways so that specific things can pass between them. There isn't enough 1918 space to reconcile the number to .gov and contractor sites on these networks without hitting collisions, and they can't be aggregated despite overlap (like I said at the beginning, we have several coming in...) because they aren't all at the same classification level (which is why they have strictly controlled gateways between them). Jamie Bowden -- "It was half way to Rivendell when the drugs began to take hold" Hunter S Tolkien "Fear and Loathing in Barad Dur" Iain Bowen <alaric@alaric.org.uk>
At 17:42 +0100 6/28/07, Stephen Wilcox wrote:
- that less than 50% of the v4 space is currently routed. scarcity will presumably cause these non-routed blocks to be: :- used and routes :- reclaimed and reassigned :- sold on
There's also the possibility: :- continued to be used as they are, just not seen on the Internet. Unrouted address space isn't always missing matter. (E.g., see GSMA PRD IR.40, http://www.gsmworld.com/documents/ireg/ir4040.pdf) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Think glocally. Act confused.
- that less than 50% of the v4 space is currently routed. scarcity will presumably cause these non-routed blocks to be: :- used and routes :- reclaimed and reassigned :- sold on
Uh, no. Just because the address space is not visible in the public Internet's default free zone does not mean that it is sitting on a shelf in a dusty warehouse. Most of that space is actively in use by organizations who explicitly want an IP internetwork that is disconnected from the Internet, or by organizations who can achieve multihomed connectivity from two upstreams without needing their routes to be propogated between those upstreams. This kind of thing happens way out at the edges of the network, far from the core, where two upstreams maintain peering links (possible at a local Internet exchanges). So to sum up. They are used and routed already. They cannot be reclaimed since they are fully justified. And they can't be sold because they are used for mission critical networks.
- that much of the space in use within organisations could be optimised :- mop up unused gaps in subnet
This will cause routing table scaling problems inside organizations, exacerbated by the greater amount of legacy hardware found in such environments. --Michael Dillon
Interoperability is achieved by having public facing servers reachable via IPv4 and IPv6.
that may be what it looks like from the view of an address allocator. but if you actually have to deliver data from servers you need a path where data from/in both protocols is supported on every link of the chain that goes all the way to every bit of back end data in your system. and if one link in that chain is missing, <sound of glib idea imploding>. randy
At 10:16 AM -0700 6/28/07, Randy Bush wrote:
Interoperability is achieved by having public facing servers reachable via IPv4 and IPv6.
that may be what it looks like from the view of an address allocator.
but if you actually have to deliver data from servers you need a path where data from/in both protocols is supported on every link of the chain that goes all the way to every bit of back end data in your system. and if one link in that chain is missing, <sound of glib idea imploding>.
Randy, Organizations need to have IPv6 on their DMZ servers. ISP's needs to provide IPv6 to these organizations, either directly or via tunnel. It's actually rather simple. /John
At 10:16 AM -0700 6/28/07, Randy Bush wrote:
Interoperability is achieved by having public facing servers reachable via IPv4 and IPv6.
that may be what it looks like from the view of an address allocator.
but if you actually have to deliver data from servers you need a path where data from/in both protocols is supported on every link of the chain that goes all the way to every bit of back end data in your system. and if one link in that chain is missing, <sound of glib idea imploding>.
Randy,
Organizations need to have IPv6 on their DMZ servers.
ISP's needs to provide IPv6 to these organizations, either directly or via tunnel.
It's actually rather simple.
repetition of an incomplete analysis does not make it complete. maybe an example will help if the data on one of those servers is derived from peoplesoft, sap,m siebold, ... running within my infrastructure, either peoplesoft et alia speak v6 and v4 or i need an alg or other payload translation mechanism. think real time bank account data for another example, i.e. a slow batch data write don't cut it. randy
On Thu, 28 Jun 2007 13:27:15 -0400 John Curran <jcurran@mail.com> wrote:
At 10:16 AM -0700 6/28/07, Randy Bush wrote:
Interoperability is achieved by having public facing servers reachable via IPv4 and IPv6.
that may be what it looks like from the view of an address allocator.
but if you actually have to deliver data from servers you need a path where data from/in both protocols is supported on every link of the chain that goes all the way to every bit of back end data in your system. and if one link in that chain is missing, <sound of glib idea imploding>.
Randy,
Organizations need to have IPv6 on their DMZ servers.
ISP's needs to provide IPv6 to these organizations, either directly or via tunnel.
It's actually rather simple.
Randy is right. It's very simple from 30,000 feet; it's a lot messier in detail if done at scale. I'll give just example, using your suggestion of converting DMZ: how do you keep your firewall rules consistent between v4 and v6 addresses and prefixes? This involves vendor technology (the firewall box), communication with your ISP (handling prefix changes), local technology (you do have a change control process for firewall rules, right, and perhaps a database of machines and addresses?), and training. It may also involve upgrading some of the servers because of the rapid changes in v6 support. (I'll cite a personal example: I upgraded the OS on a machine of mine recently, and found that my mailing lists weren't working. Why? Because the version of Postfix had been changed to one with v6 support, and I had to specify v6 loopback addresses in some mysterious place.) That's not to say this is an excuse for delay. Converting is going to get harder when you acquire more gear, not easier. Planning and back-end conversions (i.e., ISP databases that hold customer IP address ranges) should have been done years ago. It's now become urgent; I'm glad people are finally starting to take it seriously. (Metanote: IPv6 is far from the best possible design. Given all of the constraints, including the political ones, it may be, as Bjarne Stroustrup said of C++, the best design possible. Whatever -- it exists as a reasonably stable design; starting over would cost us 15 more years that we just don't have.) --Steve Bellovin, http://www.cs.columbia.edu/~smb
On Jun 28, 2007, at 11:44 AM, Steven M. Bellovin wrote:
Whatever -- it exists as a reasonably stable design; starting over would cost us 15 more years that we just don't have.)
Are you saying we (collectively) would take yet *another* 15 years to come up with another and/or better design? -brett
Whatever -- it exists as a reasonably stable design; starting over would cost us 15 more years that we just don't have.) Are you saying we (collectively) would take yet *another* 15 years to come up with another and/or better design?
i have always wanted to see third system syndrome randy
On Thu, 28 Jun 2007 12:23:30 -0700 brett watson <brett@the-watsons.org> wrote:
On Jun 28, 2007, at 11:44 AM, Steven M. Bellovin wrote:
Whatever -- it exists as a reasonably stable design; starting over would cost us 15 more years that we just don't have.)
Are you saying we (collectively) would take yet *another* 15 years to come up with another and/or better design?
Not so much to design it as to reach this point of maturity. More precisely, I don't see any reason why it would take significantly less. In fact, it can't take much less, no matter what. Figure two years for the basic design, 3-5 years for the IETF (or whomever) to engineer all the pieces (it's more than just the IP header, and until we have a new design we won't even be able to start identifying the pieces), 3 years for design/code/test (in the NANOG world, that includes new ASICs, line cards, etc.), and 3-5 years for much existing gear (routers, end systems, etc.) to be replaced with the IPvN stuff. That adds up to 11-15. I have a lot of confidence in those figures; if anything, I suspect that I'm being too optimistic. IPv6 isn't what I wanted it to be (and I was on the IPng directorate). That said, it's what we have, and I think we *really* need something with a lot more address space. --Steve Bellovin, http://www.cs.columbia.edu/~smb
IPv6 isn't what I wanted it to be (and I was on the IPng directorate). That said, it's what we have, and I think we *really* need something with a lot more address space.
At a very low, hardware centric level, IPv6 would be a lot easier to implement if 1) The addresses were 64 bits instead of 128 bits. 2) The extension headers architecture was completely revamped to be more hardware friendly. I hear a lot of noise about wanting to do 40GE/100GE with L2/L3 switching, but it is difficult to extremely difficult to implement hardware that can accommodate all the flexibility of v6 and keep up. IPv6 is a software architect's dream and a hardware architect's nightmare ;-) Bora
On Thu, 28 Jun 2007 13:08:52 PDT, Bora Akyol said:
At a very low, hardware centric level, IPv6 would be a lot easier to implement if
1) The addresses were 64 bits instead of 128 bits. 2) The extension headers architecture was completely revamped to be more hardware friendly.
Wow, a blast from the past. The *current* IPv6 design was selected to a good extent because it was *easier* to do in hardware than some of the other contenders. You think 64 versus 128 is tough - think about the ASIC fun and games to support *variable length* addresses (not necessarily even a multiple of 4 bytes, in some of the proposals. Could be 7, could be 11, check the address length field for details. Yee. Hah).
The length of the address (64 vs 128) is not the hard part. Just increases the cost and the complexity of the ASIC ;-) The extension headers become a real problem when L4 filtering is desired. Bora On 6/28/07 2:46 PM, "Valdis.Kletnieks@vt.edu" <Valdis.Kletnieks@vt.edu> wrote:
On Thu, 28 Jun 2007 13:08:52 PDT, Bora Akyol said:
At a very low, hardware centric level, IPv6 would be a lot easier to implement if
1) The addresses were 64 bits instead of 128 bits. 2) The extension headers architecture was completely revamped to be more hardware friendly.
Wow, a blast from the past. The *current* IPv6 design was selected to a good extent because it was *easier* to do in hardware than some of the other contenders. You think 64 versus 128 is tough - think about the ASIC fun and games to support *variable length* addresses (not necessarily even a multiple of 4 bytes, in some of the proposals. Could be 7, could be 11, check the address length field for details. Yee. Hah).
On Thu, 28 Jun 2007 17:46:53 -0400 Valdis.Kletnieks@vt.edu wrote:
On Thu, 28 Jun 2007 13:08:52 PDT, Bora Akyol said:
At a very low, hardware centric level, IPv6 would be a lot easier to implement if
1) The addresses were 64 bits instead of 128 bits. 2) The extension headers architecture was completely revamped to be more hardware friendly.
Wow, a blast from the past. The *current* IPv6 design was selected to a good extent because it was *easier* to do in hardware than some of the other contenders. You think 64 versus 128 is tough - think about the ASIC fun and games to support *variable length* addresses (not necessarily even a multiple of 4 bytes, in some of the proposals. Could be 7, could be 11, check the address length field for details. Yee. Hah).
I'm not going to revist all of the design issues; as I said, at this point IPv6 is what is is. On that point, you're mostly right; there were indeed a class of CLNP-derived solutions that were rejected. That said, some of us -- including me -- wanted to use the two high-order bits of the address to select among {64,128,192,256}-bit addresses. Settling on 128 bits was a compromise between that group and advocates of a 64-bit fixed-length address. History since then persuades me that sticking with 64 bits would have been a very bad mistake. --Steve Bellovin, http://www.cs.columbia.edu/~smb
On 28-jun-2007, at 21:55, Steven M. Bellovin wrote:
More precisely, I don't see any reason why it would take significantly less. In fact, it can't take much less, no matter what. Figure two years for the basic design, 3-5 years for the IETF (or whomever) to engineer all the pieces (it's more than just the IP header, and until we have a new design we won't even be able to start identifying the pieces), 3 years for design/code/test (in the NANOG world, that includes new ASICs, line cards, etc.), and 3-5 years for much existing gear (routers, end systems, etc.) to be replaced with the IPvN stuff. That adds up to 11-15.
That assumes that the next next IP will be as different from IPv6 (and IPv4) as IPv6 is from IPv4. I don't think that's necessary. Most of the complications in the IPv4->IPv6 transition come from the fact that addresses are now 128 bits long where they used to be 32 bits long. If the new protocol also uses 128 bit addresses, all the stuff that lives at layer 4 and above can probably be fooled into thinking that it's talking IPv6 while the packets are actually IPv9. Sure, IPv6 isn't the best design we could have, but it's good enough and until we can agree on address policies that make more sense than "everyone with a few thousand dollars/euros to spend can get a seat at the top of the routing hierarchy", we should probably steer clear of inventing new IP versions.
Steven M Bellovin writes:
I'll give just example, using your suggestion of converting DMZ: how do you keep your firewall rules consistent between v4 and v6 addresses and prefixes?
This is indeed a major issue in our (internal) dual-stack deployment. Our firewall rules (actually just stateless ACLs on our data-center routers) are generated from high-level rules, but the generator can only generate IPv4 ACLs. Since we failed to convince the responsible team to add IPv6 ACL generation, we wrote a script that converts IPv4 ACLs into IPv6 ACLs. The script extracts the IPv4->IPv6 address mapping from router configurations (for subnets), the DNS (for hosts), and itself (hardcoded exceptions)-: Works surprisingly well.
This involves vendor technology (the firewall box), communication with your ISP (handling prefix changes), local technology (you do have a change control process for firewall rules, right, and perhaps a database of machines and addresses?), and training.
But those are all issues that have to be addressed whether you are dual-stack or not. Our current mechanism (while a hack) is pretty transparent - the firewall rule update procedure is the same from the points of view of both the ruleset producers (security team) and consumers (who install the rules on the routers). It's just that the change reports now include IPv6 ACL changes. (Actually, the IPv6 ACLs don't "diff" as nicely as the IPv4 ones, because of an implementation shortcoming in our routers.)
It may also involve upgrading some of the servers because of the rapid changes in v6 support. (I'll cite a personal example: I upgraded the OS on a machine of mine recently, and found that my mailing lists weren't working. Why? Because the version of Postfix had been changed to one with v6 support, and I had to specify v6 loopback addresses in some mysterious place.)
This is typical for the kind of problems you will encounter when going dual-stack.
That's not to say this is an excuse for delay. Converting is going to get harder when you acquire more gear, not easier.
Right, but it's going to become easier as there are more (early) adopters that help iron out these issues for the community. -- Simon.
Steven M. Bellovin wrote:
Randy is right. It's very simple from 30,000 feet; it's a lot messier in detail if done at scale. I'll give just example, using your suggestion of converting DMZ: how do you keep your firewall rules consistent between v4 and v6 addresses and prefixes?
We actually cover some of this ground in RFC 4192, which talks about v6 renumbering. Also not fun, but v4 is somewhat less fun. This having been said, and as Simon has noted in a later message, you need to abstract addresses to make all of this stuff work smoothly. That has to happen both in the network management tools and within the operating system. I know that scares the hell out of some people but there is a high price being paid for not doing it. Eliot
On 28 Jun 2007, at 18:27, John Curran wrote:
Interoperability is achieved by having public facing servers reachable via IPv4 and IPv6.
that may be what it looks like from the view of an address allocator. but if you actually have to deliver data from servers you need a path where data from/in both protocols is supported on every link of the chain that goes all the way to every bit of back end data in your system. and if one link in that chain is missing, <sound of glib idea imploding>. Organizations need to have IPv6 on their DMZ servers. ISP's needs to provide IPv6 to these organizations, either
At 10:16 AM -0700 6/28/07, Randy Bush wrote: directly or via tunnel. It's actually rather simple.
*That* sounds simple, but that method doesn't bear any resemblance to reality. * Software that does not support v6 needs to be rewritten (I used to herd some reverse proxies owned by a Juniper company that did not support v6 addressing. I don't 100% convincingly know whether my monitoring tools do. I don't think my IP phone does.) * Operational staff need to be retrained. Hostmasters need to be retrained. Support staff need to be retrained. Your customers' technical contacts need to be retrained. Everything has to keep working whilst your staff are learning these new skills. 2009 might be a great year for consultants. ;-) * If you don't already have v6, then rolling out your v6 assignment to peers and upstreams will feel a lot like building a network from scratch all over again. A big co-ordinated effort involving a lot of third parties. * Testing budgets will need to swell seriously. If you host an online application, you need to start your testing from scratch. * Policy for v6 assignment and allocation needs to be finished and agreed upon. If you read the address policy lists you'll know that this is not going to happen for some time. (c.f. Afrinic's decision to give themselves a five-hundredth of their assignment - something they could have done for each of their ~250 or so members without impact, and the bruhaha this caused.) I daren't even mention ULA- Central policy. * Your security policy needs auditing and reworking for v6. * It needs to be rolled transparently to end users, unless you want to increase your support burden. I'm not saying that v6 should be binned in favour of turning off the internet when we run out of v4, but this is a non-exhaustive list of projects we all should be undertaking. Is everyone on the list working through their own list ? I'd wager not. Best regards, Andy Davidson
On Jun 29, 2007, at 4:51 AM, Andy Davidson wrote:
I'm not saying that v6 should be binned in favour of turning off the internet when we run out of v4, but this is a non-exhaustive list of projects we all should be undertaking. Is everyone on the list working through their own list ? I'd wager not.
And you don't need to be pushing this to customers immediately to be getting ready. As discussed at NANOG37, Comcast is pushing out IPv6 initially to manage cable modems and set-top boxes (http:// www.nanog.org/mtg-0606/durand.html). While this doesn't benefit customers directly, it gets the routing environment set up to handle IPv6, it gets the operational staff up to speed, and lays the groundwork and infrastructure for when consumer IPv6 is more of a reality. Bob
On 28-Jun-2007, at 13:16, Randy Bush wrote:
Interoperability is achieved by having public facing servers reachable via IPv4 and IPv6.
that may be what it looks like from the view of an address allocator.
but if you actually have to deliver data from servers you need a path where data from/in both protocols is supported on every link of the chain that goes all the way to every bit of back end data in your system. and if one link in that chain is missing, <sound of glib idea imploding>.
I think this is one reason why the transition is hard: supporting dual stacks in clients when the demonstrated quality of the v6 network is noticably worse than the v4 network is a difficult business case to sell. When you depends on users being able to talk to you reliably, having them use a low-quality transport when a high-quality transport is also available has a direct impact on the bottom line, without even considering the capex/opex costs of supporting IPv6. The difference in performance/reliability might be relatively small to a single user, but to a company who is trying to service millions of clients every minute (and is earning revenue from each visit) the aggregate effect is surely much more significant. Providing access to (e.g.) web services over both IPv4 and IPv6 using (e.g.) a single URL hence reduces revenue when serving the non-zero (but small) set of dual-stack clients, and does not increase revenue from the set of IPv6-only clients in any practical sense since that set is (to all intents and purposes) empty. Providing separate URLs for services over IPv6 requires user education, which is arguably even more expensive. The way to avoid this scenario is presumably to improve the quality of the IPv6 network such that the risk of revenue loss from IPv6 support falls below an acceptable threshold. Which would be much easier to do if people were using it, and opening trouble tickets when things need to be fixed :-) Joe
John Curran wrote:
Steve -
For the first end site that has to connect via IPv6, it will be very bad if there is not a base of IPv6 web/email sites already in place.
As the network administrator for a Web hosting company, I've not seen any coherent (and useful) information about how I can provide both IPv6 addressing and IPv4 addressing for the sites I host. I'm in the process of doing OS upgrades, and IPv6 is included...but currently I shut off IPv6 because I don't have a IPv6 firewall solution yet. That includes DNS, by the way. I'm deploying new DNS servers, and would be *very* interested in how to convince BIND 9.2.4 to answer IPv6 queries. Another issue: the Plesk Web control panel software from SW-Soft doesn't seem to have any support for IPv6. The CPanel Web Host Manager at least lets me create AAAA records in zone files, so roughly 1/3 of my customers *could* have IPv6 capability. Lurkers: tutorials welcome.
On 30-jun-2007, at 7:04, Stephen Satchell wrote:
That includes DNS, by the way. I'm deploying new DNS servers, and would be *very* interested in how to convince BIND 9.2.4 to answer IPv6 queries.
If you give the box BIND runs on an IPv6 address, it'll use IPv6 to perform queries when remote nameservers have IPv6 glue records. If you have your DNS server's address put into glue records, it will receive IPv6 queries and hence send out replies over IPv6. More info: http://www.apress.com/book/supplementDownload.html?bID=10026&sID=3120
In article <4685E472.4050200@satchell.net> you write:
John Curran wrote:
Steve -
For the first end site that has to connect via IPv6, it will be very bad if there is not a base of IPv6 web/email sites already in place.
As the network administrator for a Web hosting company, I've not seen any coherent (and useful) information about how I can provide both IPv6 addressing and IPv4 addressing for the sites I host. I'm in the process of doing OS upgrades, and IPv6 is included...but currently I shut off IPv6 because I don't have a IPv6 firewall solution yet.
Well there are lots of firewalls that support IPv6. If you can't find one you really have not searched.
That includes DNS, by the way. I'm deploying new DNS servers, and would be *very* interested in how to convince BIND 9.2.4 to answer IPv6 queries.
listen-on-v6 { any; }; If you want finer acls than that in listen-on-v6 then you want BIND 9.3 (currently 9.3.4) or BIND 9.4 (currently 9.4.1).
Another issue: the Plesk Web control panel software from SW-Soft doesn't seem to have any support for IPv6. The CPanel Web Host Manager at least lets me create AAAA records in zone files, so roughly 1/3 of my customers *could* have IPv6 capability.
Lurkers: tutorials welcome.
I don't see the problem. I've deployed IPv6 in may web servers, and nothing failed, we had firewall support for IPv6 most of the time, and otherwise we used iptables6. The DNS thing has been replied already as I can see. I think we have lots of documents on-line explaining all this, including our own IPv6 Portal (http://www.ipv6tf.org). And if answer is not there, let me know and I will try to create a new document for you about that specific topic. In fact, the problem may be that there are *too many* documents, and too much to read, so my recommendation is *start now* with a very practical mind set, at least with a pilot. Regards, Jordi
De: Stephen Satchell <list@satchell.net> Responder a: <owner-nanog@merit.edu> Fecha: Fri, 29 Jun 2007 22:04:50 -0700 Para: John Curran <jcurran@mail.com> CC: Stephen Wilcox <steve.wilcox@packetrade.com>, <nanog@nanog.org> Asunto: Re: The Choice: IPv4 Exhaustion or Transition to IPv6
John Curran wrote:
Steve -
For the first end site that has to connect via IPv6, it will be very bad if there is not a base of IPv6 web/email sites already in place.
As the network administrator for a Web hosting company, I've not seen any coherent (and useful) information about how I can provide both IPv6 addressing and IPv4 addressing for the sites I host. I'm in the process of doing OS upgrades, and IPv6 is included...but currently I shut off IPv6 because I don't have a IPv6 firewall solution yet.
That includes DNS, by the way. I'm deploying new DNS servers, and would be *very* interested in how to convince BIND 9.2.4 to answer IPv6 queries.
Another issue: the Plesk Web control panel software from SW-Soft doesn't seem to have any support for IPv6. The CPanel Web Host Manager at least lets me create AAAA records in zone files, so roughly 1/3 of my customers *could* have IPv6 capability.
Lurkers: tutorials welcome.
********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
On Thu, 28 Jun 2007, Stephen Wilcox wrote:
First is the belief that the Internet will suddenly break on the day when the last IP block is allocated by an RIR - the fact that most of the v4 space is currently not being announced may mean we have many years before there are real widespread shortages
Widespread? No. Pockets of problems? Yes. A large corporation or .edu that got n x /16s or even a /8 of v4 space in som cases and is only using a small fraction of that has no motivation based on address exhaustion to migrate to v6. ISPs and other organizations that regularly 'go back to the well' for more address space are in a different boat. They want to be ready with a plan well in advance of the day they'd go back to the well again and have have $RIR tell them there are no more blocks to assign.
Second is the belief that this will prompt a migration to IPv6, as though moving to an entirely different and largely unsupported protocol stack is the logical thing to happen. Surely it is easier and far cheaper by use of existing technology for example for organisations to make efficient use of their public IPs and deploy NATs?
Large-scale NATs introduce their own large-scale problems. Many modern OSes include v6 stacks already, but it needs to be enabled in a lot lf those cases. Where you'll run into problems are either older machines or hardware devices with built-in IP stacks. Running a dual-stack backbone can ease some of those transitional headaches.
As technology people we are looking at v6 as the clean bright future of IP, but the real world is driven by economics and I dont see v6 as being economically viable in the near future....
That will change over time. Last I heard, the US government is in the midst of a big push to v6. I wouldn't be at all surprised to see some federal grants come with riders requiring v6 connectivity in the not-too-distant future. That will get the attention of the large .edus with legacy v4 assignments and the businesses that have federal research grant funding as a significant part of their cash flow. jms
participants (37)
-
Adrian Chadd -
Alexander Harrowell -
Andy Davidson -
Bob Snyder -
Bora Akyol -
brett watson -
Christian Kuhtz -
chuck goolsbee -
Dave Israel -
David Conrad -
Deepak Jain -
Donald Stahl -
Douglas Otis -
Edward Lewis -
Eliot Lear -
Iljitsch van Beijnum -
Jamie Bowden -
Jeff Shultz -
Jeroen Massar -
Joe Abley -
Joel Jaeggli -
John Curran -
JORDI PALET MARTINEZ -
Justin M. Streiner -
Kevin Oberman -
Lynda True (aka Etaoin Shrdlu) -
Mark Andrews -
michael.dillon＠bt.com -
Nicolás Antoniello -
Randy Bush -
Simon Leinen -
Stephen Satchell -
Stephen Sprunk -
Stephen Wilcox -
Steve Gibbard -
Steven M. Bellovin -
Valdis.Kletnieks＠vt.edu