On 05/03/2010, at 12:25 PM, Owen DeLong wrote:

The most we could achieve would be to extend IPv4 freepool lifespan by roughly 26 days. Given the amount of effort sqeezing useful addresses out of such a conversion would require, I proffer that such effort is better spent moving towards IPv6 dual stack on your networks.

... and, unstated behind that, is the observation that pretty much any proposed effort to squeeze more time out of IPv4 will inevitably have the same answer :-) - mark -- Mark Newton Email: newton@internode.com.au (W) Network Engineer Email: newton@atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223

The most we could achieve would be to extend IPv4 freepool lifespan by roughly 26 days. Given the amount of effort sqeezing useful addresses out of such a conversion would require, I proffer that such effort is better spent moving towards IPv6 dual stack on your networks.

A /8 sounded like a decent amount until you put it that way. Nice empirical data, even though its based completely on assumptions. But if it is even in the ballpark.. It is pretty obvious it isn't worth the effort. I just didn't have even have a guess at the number /30s out there. I've been on board with rolling out IP6 but the SPs I've talked to are all '...about to start trying to possibly think about extending a beta to a small portion of some customers' or something along those lines. This led me to believe that SPs are way behind on this considering the expected exhaustion of IP4 space. Also, and not sure how to phrase this, but is there any behind-the-scenes push to start moving closed systems that run over the Internet to IP6 with the goal of freeing up any of the IP4 space for more public-facing systems and end-users? Is the thought of anyone giving up IP4 space after they have moved to IP6 just a silly notion? I could see a future where infrastructure services like voice run on IP6 while common 'web services' stay on IP4. Once again, sorry if I'm bringing up anything that has been beaten to death. I just come from the corporate side of this and the SP side is just a point of interest for me so I like to hear that point of view.

On 05/03/2010, at 2:50 PM, David Conrad wrote:

When the IPv4 free pool is exhausted, I have a sneaking suspicion you'll quickly find that reclaiming pretty much any IPv4 space will quickly become worth the effort.

Only to the extent that the cost of IPv6 migration exceeds the cost of recovering space. There's sure to be an upper-bound on the cost of v4 space, limited by the magnitude of effort required to do whatever you want to do without v4. - mark -- Mark Newton Email: newton@internode.com.au (W) Network Engineer Email: newton@atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223

On Mar 5, 2010, at 10:36 PM, David Conrad wrote:

Mark,

On Mar 4, 2010, at 11:46 PM, Mark Newton wrote:

...

On 05/03/2010, at 2:50 PM, David Conrad wrote:

...

When the IPv4 free pool is exhausted, I have a sneaking suspicion you'll quickly find that reclaiming pretty much any IPv4 space will quickly become worth the effort.

Only to the extent that the cost of IPv6 migration exceeds the cost of recovering space.

You're remembering to include the cost of migrating both sides, for all combinations of sides interested in communicating, right? In some cases, that cost for one of those sides will be quite high.

...

There's sure to be an upper-bound on the cost of v4 space, limited by the magnitude of effort required to do whatever you want to do without v4.

The interesting question is at what point _can_ you do what you want without IPv4. It seems obvious that that point will be after the IPv4 free pool is exhausted, and as such, allocated-but-not-efficiently-used addresses will likely become worth the effort to reclaim.

Ah, but, that assumes that the need is located in a similar part of the network to the reclamation, or, that the point of reclamation can be sufficiently motivated to do so by the money offered by the point of need. I suspect the organizations that have excess space and know where it is are likely to hold onto it as a hedge against their future needs, or, try to extract a very high market premium for it. Owen

On Mar 6, 2010, at 6:08 AM, David Conrad wrote:

On Mar 5, 2010, at 1:21 PM, Owen DeLong wrote:

...

...

The interesting question is at what point _can_ you do what you want without IPv4. It seems obvious that that point will be after the IPv4 free pool is exhausted, and as such, allocated-but-not-efficiently-used addresses will likely become worth the effort to reclaim.

Ah, but, that assumes that the need is located in a similar part of the network to the reclamation, or, that the point of reclamation can be sufficiently motivated to do so by the money offered by the point of need.

Actually, no, not really. When you're dying of thirst, even muddy water can be mighty appealing. The fact that some prefixes you obtain may be filtered because they're too short merely means you have additional costs to reach the sites you care about. Don't know many ISPs that guarantee universal connectivity outside their own network today. Not sure why that would change in the future.

I think you mean long, not short. While there aren't many ISPs that guarantee that today (any?) it's still generally expected by customers and they are very unhappy when $SITE_THEY_CARE_ABOUT is unreachable. While the underlying guarantee likely won't change, I think it is even less likely that customer expectations will degrade even further. I could be wrong. However, my point was that if the organization with need is not the organization able to do the reclamation, or, at least a customer of the organization doing the reclamation, I expect the $$ they can offer to be a less than effective motivator for an external unrelated organization to give up their space.

...

I suspect the organizations that have excess space and know where it is are likely to hold onto it as a hedge against their future needs, or, try to extract a very high market premium for it.

Such folks will also have to take into consideration opportunity cost. Or they could make the strategic decision that all they really need is one or two ISP-provided public IPv4 addresses (in addition to IPv6) for their NATv4 box and public servers is all they really need and lease to their ISP the blocks they currently have in exchange for free connectivity or whatever. Etc. Myriad of possibilities.

Which comes back to my proximity argument -- If they leas to their provider, then, their provider can only offer those addresses to their immediate customers. What happens in such a lease when the lease expires and the original organization decides they want the addresses back? I'd hat to be the organization that received such addresses and suddenly faces a massive and urgent renumbering project.

The point is that when the IPv4 free pool is exhausted, there will be disruptive change. It isn't clear to me that pretty much any of the existing policies or practices regarding IPv4 addressing will continue to apply. I've been disappointed that some folks in the RIR communities have been unable to understand this. Gave up arguing as I figure time will tell one way or the other.

I understand it, but, I think that the most likely disruptive change will be that new users mostly end up behind IPv6 and some form of LSN solution. I'm hoping that it's mostly something like DS-Lite which gets the hell out of the way as soon as the content the customer wants is available on IPv6, but, I'm sure there will be providers that make uglier decisions for their customers. As such, I'm trying to do every thing I can to reach out to as many content and services providers as possible to encourage them to add IPv6 capabilities to their content and services. The more of these we can get dual-stack ready (even if they do something akin to Google, where it's ready and essentially available except for the DNS entries). The more content and services that are prepared in this manner, the less disruptive runout will be. Additionally, content and services are MUCH easier to roll out than enterprise networks. Almost as easy as end-user networks will be in about a year. (I think that you'll see relatively complete IPv6 solutions from most of the last-mile CPE and Head-End (DSLAM, DOCSIS, [BG]PON, etc.) vendors within the next 12 months. Some sooner than others. Owen

Regards, -drc

On 06/03/2010, at 1:06 AM, David Conrad wrote:

Mark,

On Mar 4, 2010, at 11:46 PM, Mark Newton wrote:

...

On 05/03/2010, at 2:50 PM, David Conrad wrote:

...

When the IPv4 free pool is exhausted, I have a sneaking suspicion you'll quickly find that reclaiming pretty much any IPv4 space will quickly become worth the effort.

Only to the extent that the cost of IPv6 migration exceeds the cost of recovering space.

You're remembering to include the cost of migrating both sides, for all combinations of sides interested in communicating, right? In some cases, that cost for one of those sides will be quite high.

Yes, but I only need to pay the cost of my side.

...

There's sure to be an upper-bound on the cost of v4 space, limited by the magnitude of effort required to do whatever you want to do without v4.

The interesting question is at what point _can_ you do what you want without IPv4. It seems obvious that that point will be after the IPv4 free pool is exhausted, and as such, allocated-but-not-efficiently-used addresses will likely become worth the effort to reclaim.

That isn't a likely outcome, though. We'll never need to do "without IPv4", it'll always be available, just in a SP-NATted form which doesn't work very well. Continuing to put up with that state of affairs comes with its own set of costs and obstacles which need to be weighed up against the cost of migrating to dual-stack (unicast global IPv6 + SPNAT IPv4) to extract yourself from the IPv4 tar-baby. Not migrating will be increasingly expensive over time, the costs of migrating will diminish, each individual operator will reach their own point when staying where they are is more expensive than getting with the program. And most of the participants on this mailing list will probably reach that point sooner than they think. My mom will probably never see a need to move beyond IPv4. But her next door neighbor with the bittorrent client and WoW habit probably will, and any content provider who's interested in having a relationship with their eyeballs which isn't intermediated by bollocky SPNAT boxes probably will too. Horses for courses. What I do know is that this "migrating to IPv6 is expensive so nobody wants to do it," is a canard that's been trotted out for most of the last decade as a justification for doing nothing. As an ISP that's running dual-stack right now, I can tell you from personal experience that the cost impact is grossly overstated, and under the circumstances is probably better off ignored. Just sayin'. - mark -- Mark Newton Email: newton@internode.com.au (W) Network Engineer Email: newton@atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223

On 3/6/10 1:32 PM, Shon Elliott wrote:

My first reply to this thread. I've been kind of tracking it.

I would love to move to IPv6. However, the IPv6 addressing, I have to say, is really tough to remember and understand for most people. Where is a four number dotted quad was easy to remember, an IPv6 address.. not so much. I wished they had made that a little easier when they were drafting up the protocol specs. basically, you need technical knowledge to even understand how the IP address is split up. I wished ARIN would waive the fee for service provider's first block of IPv6 as well. It would help make the dual stack deployment easier.

There *is* a fee waiver in effect as introduced in 2008. However, if you've waited until now you only get 50% waived in 2010 and 25% waived in 2011. The waiver expires in 2012. Also, if your IPv4 fees are higher than the IPv6 fees would be, you only pay the higher one so the IPv6 block would be effectively free. ~Seth

On Mar 7, 2010, at 5:32 AM, Shon Elliott wrote:

My first reply to this thread. I've been kind of tracking it.

I would love to move to IPv6. However, the IPv6 addressing, I have to say, is really tough to remember and understand for most people. Where is a four number dotted quad was easy to remember, an IPv6 address.. not so much. I wished they had made that a little easier when they were drafting up the protocol specs. basically, you need technical knowledge to even understand how the IP address is split up. I wished ARIN would waive the fee for service provider's first block of IPv6 as well. It would help make the dual stack deployment easier.

I'm not sure how you think they could have. 128 bits is a really big number no matter how you represent it. For the most part, attempting to remember IP addresses of either form is error-prone and ill-advised. It's actually much easier to understand how an IPv6 address should be split up than an IPv4 address. The rules are virtually identical to IPv4, and the recommendations are even easier to understand than the IPv4 rules. Rule: A netmask is expressed as a / followed by the number of contiguous bits at the MSB end of the number which comprise the network number. The remaining bits at the LSB end of the number comprise the host address. (Hint: This is the same rule as modern IPv4 and has largely the same mapping: For example, a /8 is 0xff000000 in IPv4 and 0xff00000000000000000000000000 in IPv6. (notice just more 0s to the right of the 0xff) ) Recommendations: End networks containing hosts should be /64. End-User organizations of very small size should receive a /56, or, on request, a /48. End-User organizations which are not very small should receive a /48, or, larger with appropriate justification. ISPs and LIRs should receive a /32, or, larger with appropriate justification. Because IPv6 addresses are always represented in hex, it is even easier to match up subnets to digits. Each hex digit is exactly 4 bits. (In IPv4, every 1, 2, or 3 digits, separated by a . was 8 bits and required a not insignificant amount of mental arithmetic to match an IP address and netmask to a prefix) IPv6 netmasks which do not line up with nibble boundaries still require some mental arithmetic, but, it is much much easier: Mask Value (MV) = /xx XX = Mask match portion of address. yy... = Remainder of 64 MSb of address. zz... = Host portion of /64 MV % 4 Mapping: 0 Full digit. /0 = default 1 First bit /1 = [0-7]yyy:yyyy:yyyy:yyyy:zzzz:zzzz:zzzz:zzzz or [8-f]yyy:yyyy:yyyy:yyyy:zzzz:zzzz:zzzz:zzzz 2 Two bits /2 = [0-3], [4-7], [8-b], or [c-f]... 3 Three bits /3 = [0-1], [2-3], [4-5], [6-7], [8-9], [a-b], [c-d], or [e-f]... 0 Full digit /4 = Xyyy:yyyy:yyyy:yyyy:zzzz:zzzz:zzzz:zzzz 1 First bit /5 = X[0-7]yy:yyyy:yyyy:yyyy:zzzz:zzzz:zzzz:zzzz or X[8-f]yy:yyyy:yyyy:yyyy:zzzz:zzzz:zzzz:zzzz 2 Two bits /6 = X[0-3]yy, X[4-7]yy, X[8-b]yy, or X[c-f]yy... etc. Personally, I recommend the KISS approach and keeping the boundaries aligned to the nibble wherever possible (/4, /8, /12, /16...)

I know IPv4 is running out. I understand the situation. I just wished they had put a little more thought into the user experience side of the addressing. You can all flog me now if you want. I expect it. I'm green on IPv6. I would love the education if I am wrong.

I'm not trying to flog you. I'm trying to help you. If you have more questions, feel free to email me off-list. Owen

-S

Mark Newton wrote:

...

On 06/03/2010, at 1:06 AM, David Conrad wrote:

...

Mark,

On Mar 4, 2010, at 11:46 PM, Mark Newton wrote:

...

On 05/03/2010, at 2:50 PM, David Conrad wrote:

...

When the IPv4 free pool is exhausted, I have a sneaking suspicion you'll quickly find that reclaiming pretty much any IPv4 space will quickly become worth the effort. Only to the extent that the cost of IPv6 migration exceeds the cost of recovering space. You're remembering to include the cost of migrating both sides, for all combinations of sides interested in communicating, right? In some cases, that cost for one of those sides will be quite high.

Yes, but I only need to pay the cost of my side.

...

...

There's sure to be an upper-bound on the cost of v4 space, limited by the magnitude of effort required to do whatever you want to do without v4. The interesting question is at what point _can_ you do what you want without IPv4. It seems obvious that that point will be after the IPv4 free pool is exhausted, and as such, allocated-but-not-efficiently-used addresses will likely become worth the effort to reclaim.

That isn't a likely outcome, though. We'll never need to do "without IPv4", it'll always be available, just in a SP-NATted form which doesn't work very well.

Continuing to put up with that state of affairs comes with its own set of costs and obstacles which need to be weighed up against the cost of migrating to dual-stack (unicast global IPv6 + SPNAT IPv4) to extract yourself from the IPv4 tar-baby. Not migrating will be increasingly expensive over time, the costs of migrating will diminish, each individual operator will reach their own point when staying where they are is more expensive than getting with the program.

And most of the participants on this mailing list will probably reach that point sooner than they think.

My mom will probably never see a need to move beyond IPv4. But her next door neighbor with the bittorrent client and WoW habit probably will, and any content provider who's interested in having a relationship with their eyeballs which isn't intermediated by bollocky SPNAT boxes probably will too.

Horses for courses.

What I do know is that this "migrating to IPv6 is expensive so nobody wants to do it," is a canard that's been trotted out for most of the last decade as a justification for doing nothing.

As an ISP that's running dual-stack right now, I can tell you from personal experience that the cost impact is grossly overstated, and under the circumstances is probably better off ignored.

Just sayin'.

- mark

-- Mark Newton Email: newton@internode.com.au (W) Network Engineer Email: newton@atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223

On Sat, 6 Mar 2010, Shon Elliott wrote:

I would love to move to IPv6. However, the IPv6 addressing, I have to say, is really tough to remember and understand for most people. Where

Hi Shon. But we have a system in place which allows non-technical people to ignore IP addresses entirely. Up to this point the ease of remembering IPv4 addresses has allowed their use to leak out in to the user community. It is quite common today for users to ssh to servers by IP address in many organisations. I consider this an historical accident. When setting up or upgrading corporate networks (even for small companies) I use split-view DNS. I like to point out that once IPv6 is mainstream no one is going to remember IP addresses ever again :)

is a four number dotted quad was easy to remember, an IPv6 address.. not so much. I wished they had made that a little easier when they were drafting up the protocol specs.

I don't believe making it easier for humans to remember or understand IP addresses would have been a good design criteria. IP addresses are principally designed for computers to understand. We humans have a parrallel structure of names that we can use. In any case humans got a break with the :: notation in IPv6 :)

basically, you need technical knowledge to even understand how the IP address is split up. I wished ARIN would waive the fee for service

That's actually still true in IPv4. A knowledgeable user may be able to ping an IP address but few of them will understand the concept of a subnet. Cheers, Rob -- Email: robert@timetraveller.org IRC: Solver Web: http://www.practicalsysadmin.com I tried to change the world but they had a no-return policy

On 03/04/2010 06:41 PM, Thomas Magill wrote:

I've been on board with rolling out IP6 but the SPs I've talked to are all '...about to start trying to possibly think about extending a beta to a small portion of some customers' or something along those lines. This led me to believe that SPs are way behind on this considering the expected exhaustion of IP4 space.

Note, that no operator on this list or any other has had a request approved but not fulfilled by an RIR due to a lack of numbers to assign. When that happens if not before you can can expect behavioral change to occur. denial anger bargaining depression acceptance decide which step you're on... joel

On Mar 5, 2010, at 1:57 PM, Joel Jaeggli wrote:

On 03/04/2010 06:41 PM, Thomas Magill wrote:

...

I've been on board with rolling out IP6 but the SPs I've talked to are all '...about to start trying to possibly think about extending a beta to a small portion of some customers' or something along those lines. This led me to believe that SPs are way behind on this considering the expected exhaustion of IP4 space.

Note, that no operator on this list or any other has had a request approved but not fulfilled by an RIR due to a lack of numbers to assign. When that happens if not before you can can expect behavioral change to occur.

denial anger bargaining depression

acceptance <--- My dual-stacked network and I are here. Owen

On Wed, Mar 10, 2010 at 04:55, Jens Link <lists@quux.de> wrote:

Owen DeLong <owen@delong.com> writes:

...

...

denial anger bargaining depression acceptance    <--- My dual-stacked network and I are here.

So am I. But most IT people I talk to are still at the denial phase. And there is not much one can do about it.

Jens, 566 days to go -- ------------------------------------------------------------------------- | Foelderichstr. 40  | 13595 Berlin, Germany | +49-151-18721264         | | http://www.quux.de | http://blog.quux.de   | jabber: jenslink@guug.de | -------------------------------------------------------------------------

Or 374 days on the competing prediction http://ipv4depletion.com/?page_id=4

IMHO, only personally experienced pain is going to push a lot of these sorts of people into ipv6. By pain, I mean things such as not being able to deploy their new service (web site, email server, VPN box, whatever) on the internet due to lack of ipv4 addresses, having to implement double NAT, CGN/LSN, or being forced to live behind such an arrangement ["what do you mean I can't port forward the port for my favorite game/new service?!?!" (yes, I know some schemes will still allow customer port forwards, but this will be made more difficult, painful, since many users will now be sharing the same publics.)]

Once the "pain" hits, many will be doing crash courses in ipv6 and rolling it out as quickly as they can. I think it's just human nature. :)

- Jim

Yep... We all know you can't get an ostrich's head out of the sand with a shovel. Having said that, I do think we have other tools besides shovels at our disposal. I try to avoid being preachy, but, at the same time, there are some pretty hard numbers available. It's not the guys on IRC that need the most convincing anyway. They know, and in many cases, while they're still in denial, they don't need to change because they couldn't get support from above if they did. The target really needs to be the CxOs and the management, especially in places where there is content facing the general public. Fortunately, Google, Yahoo, Netflix, etc. get it and have moved forward with IPv6. Some others are coming along. I just prodded the IT department at Wells Fargo today while working on troubleshooting an IPv4-based email problem asking them why my messages weren't reaching them over IPv6 as well. The main thing we need to convey to our colleagues in the IRC crowd is that IPv6 really isn't as difficult as some have made it out to be. While it does require some different thinking, mostly in the area of address planning, the rest of it is pretty much business as usual just like IPv4. The other hurdle I've encountered is fear about "switching" to IPv6. We need to be clear that we aren't "switching" to IPv6, we're "adding IPv6 capabilities to the existing IPv4 network". The former creates a lot more fear of change than the latter. Owen (Oh, and in case anyone doesn't know, yes, I work for Hurricane Electric. I went to work there because I liked what they were doing with IPv6. I'd recommend their products (and did) even if I did not work there.)

On Wednesday 10 March 2010 09:46:19 pm Jim Burwell wrote:

On 3/10/2010 16:57, Owen DeLong wrote:

...

The target really needs to be the CxOs and the management, especially in places where there is content facing the general public. Fortunately, Google, Yahoo, Netflix, etc. get it and have moved forward with IPv6. Some others are coming along.

True. CxOs can basically order it to be done.

Fascinating thread; thanks to all for the many insights found here; this thread has made my personal archive, just like the other long one did. I've chosen to reply to this post, because it directly addresses me, in addition to the other two topical posts I just couldn't resist. So, let me give the insight from the CIO point of view, at least in terms of a non-profit organization. How do I know this PoV? I _am_ the CIO here, that's how. Here's my hypothetical reaction to a hypothetical network engineer coming to me with a good, solid, thorough, and compelling presentation on why we need to go to IPv6: "Hey, great presentation. Compelling arguments. But I have one question: will our existing gear that's not yet fully depreciated handle it? No? Sorry, won't happen. Not in this recession year; grants have been tight, and nobody wants to fund this kind of capex right now. Especially not since it hasn't yet been five years since that previous grant bought some of that equipment. No, we cannot afford to forklift upgrade now. Do whatever you can with what we have. Or, if we absolutely must upgrade, find the money in the bandwidth budget, and reduce our bandwidth if you have to do so. Oh, and one other thing: is our ISP supporting this IPv6 thing yet? No? Come back when they do, and when you figure out how to do this with our existing equipment, or find the money in the existing budget. If you'll excuse me, I have a meeting with the head of the server group, who says he needs funds for upgrading our server farm to something called vSphere 4. Says he can save us a couple of grand per month in power and cooling costs, and has a plan to use the savings to upgrade our website to something more interactive for our core stakeholders." Fact: many, if not most, businesses today are struggling to do basic things, at least in my area. IPv6 migration for many businesses is a desirable, not an essential, thing to do, at least right now, and especially if serious capex is required to do it. For some businesses, IPv6 addition is more of an annoyance than a desirable. So, many businesses, in today's economic climate, will be dragged into IPv6 kicking and screaming simply because it's going to be, in their eyes, dead cost. Unless there is either a significant value-add or cost reduction in the mid to long term, that is. Having more addresses is not enough. And thus, ISP's which serve those businesses really don't have sufficient economic reason to expend their own capex budgets down to the bone if the demand from their customers is low. At the CxO level, it's all about the money. Or the lack therof. In our case, yes, we're going to add IPv6 when it makes cents to do so. Misspelling intentional; but I do have a plan in place to roll it out quickly when needed, in no small part thanks to threads on NANOG and Cisco-NSP. -- Lamar Owen Chief Information Officer Pisgah Astronomical Research Institute

On 3/26/2010 1:31 PM, Owen DeLong wrote:

On Mar 26, 2010, at 8:57 AM, Lamar Owen wrote:

You should ask your server guy how he plans to talk to your core stakeholders when they can't get IPv4 any more.

Then, at that time, both he and his key stakeholders will experience pain while they both deploy IPv6, or more likely, his key stakeholders will add another level of NAT-like indirection to give themselves space to expand with the address pool they have.

...

At the CxO level, it's all about the money. Or the lack therof.

How much less money will you have when donors can not reach your website or have a poor user experience doing so?

This assumption is incorrect. "They can't keep nursing IPv4 forever. Eventually everybody will have to switch to v6. If you don't, you'll be sorry. Just wait and see." That attitude did not force any previous supposed IPv4-killer protocol to be deployed. The fact is, for the foreseeable future, his donors will tend to have a better experience over v4 than v6. He isn't going to be blindsided by the need to deploy v6, and he knows it. By the time an important v4 host is not reachable via the entire internet (and at full speed), v6 will have been everywhere for years. An address space crisis will not result in v6 deployment from repentant network engineers who did not see the light in time. An address space crisis will merely result in more hacks to keep v4 running longer. v6 will be deployed slowly by the curious, encouraged by features v6 has that they want and with the assumption that they will still be able to do everything they can do on v4 (either through translation or dual stacking.) This process can be accelerated by something that v6 can do that v4 can't. So far, there's nothing that fits that description; everything being done over v6 can also be done over v4.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings Owen, The only problem is that there will be a number of devices that the eyeballs like that won't ever see an IPv6 packet (specifically thinking about the CE devices in the home). As such, it won't be IPv6 only, it will be dual-stack. Eventually we won't be able to give that eyeball's NAT box a unique address, then the proliferation of state begins.... Chris On 27 Mar 2010, at 08.42 , Owen DeLong wrote:

Dave, It's clear we disagree about what will happen in an obviously unpredictable future. I think that eyeball networks will deploy IPv6 rapidly due to the high costs of attempting to continue to hack IPv4. You believe that something else will happen. In time, we will see which of us turns out to be more correct. We can look at it in hindsight over drinks in about 5 years or so.

Owen

On Mar 26, 2010, at 1:32 PM, Dave Israel wrote:

...

On 3/26/2010 1:31 PM, Owen DeLong wrote:

...

On Mar 26, 2010, at 8:57 AM, Lamar Owen wrote:

You should ask your server guy how he plans to talk to your core stakeholders when they can't get IPv4 any more.

Then, at that time, both he and his key stakeholders will experience pain while they both deploy IPv6, or more likely, his key stakeholders will add another level of NAT-like indirection to give themselves space to expand with the address pool they have.

...

...

At the CxO level, it's all about the money. Or the lack therof.

How much less money will you have when donors can not reach your website or have a poor user experience doing so?

This assumption is incorrect. "They can't keep nursing IPv4 forever. Eventually everybody will have to switch to v6. If you don't, you'll be sorry. Just wait and see." That attitude did not force any previous supposed IPv4-killer protocol to be deployed. The fact is, for the foreseeable future, his donors will tend to have a better experience over v4 than v6. He isn't going to be blindsided by the need to deploy v6, and he knows it. By the time an important v4 host is not reachable via the entire internet (and at full speed), v6 will have been everywhere for years.

An address space crisis will not result in v6 deployment from repentant network engineers who did not see the light in time. An address space crisis will merely result in more hacks to keep v4 running longer. v6 will be deployed slowly by the curious, encouraged by features v6 has that they want and with the assumption that they will still be able to do everything they can do on v4 (either through translation or dual stacking.) This process can be accelerated by something that v6 can do that v4 can't. So far, there's nothing that fits that description; everything being done over v6 can also be done over v4.

- --- 李柯睿 Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJLrUppAAoJEGmx2Mt/+Iw/k30IAIv4rBRUbpWpFt7g5aXj5Jdh BfT7vKZp20Ho4O4IPPu5gqF1w5m/PWAsdyyuD+seUaVx/r6+KQbS5cLuErt+RXtb nZShLBjmXRusuJaz6Wj9ydTPaCZ0YdAC+drLLVN+7ogyoLpk3bp8JYf9nA66eHV5 BvaepyWOO47Fl2jG18Zds/xuPDlx9wTTi/fdeJiPAfLMFUKyMhoooFbqZXYd1Go4 tZVZWShvD8WOSiCnBr746WiuUpsqzpk0UPD+fmkciMkLEC3kCCJlRg0ak0O/SSlC nl8DgMk/ADY421ilZpUs27NwrpjOd8AXMgXoDhmeZ4q7HyH7KqqVrBlWrWuYe6Q= =ELTE -----END PGP SIGNATURE-----

Thanks for sharing. I think your/our circumstances are shared by many folks who have a network to run, budgets to stck to, and technology to adopt. Not everyone has a massive core network with 10s of thousands of downstream clients. A few years ago I attended a SIGCOM mtg and was on a pannel talking about IPv6. One of the pannelests was XingLi of CERN, who presented their v4/v6 translator code that supports over 400,000 chinese academics on native IPv6 - the IPv4 was relegated to the translator box and the DNS. I run the code at my home (we have been native IPv6 only for about 3 years now) on old hard ware (a 386 with 2@100m nics) and it is rock solid. We have runs demos at ARIN mtgs, and I2/Joint Techs workshops for a few years as well. The IETF is grappling with the same issues, wiht multiple alternatives being discussed. Another technique, based on slightly different design criteria can be had from ISC (your favorite DNS and DHCP code supplier). Their product is called AFTR. For really high end stuff, my friend Charlie has developed a box that will translate for 100k/10m nodes or so - truely a carrier-grade box. Both IVI and (perhaps) AFTR will give you the ability to move small (100-1000) networks to a native IPv6, with a thin IPv4 veneer on the perimeter. So it is possible to decompose the problem into small, bite-sized chunks and not have to worry about your upstream leading the say. You can use old kit and not have to deploy lots of new gear. So it might be worthwhile to consider this from a "grass-roots" perspective. Another PoV to consider. --bill

On Sun, Mar 28, 2010 at 09:08:52PM +0200, Simon Leinen wrote:

bmanning writes:

...

A few years ago I attended a SIGCOM mtg and was on a pannel talking about IPv6. One of the pannelests was XingLi of CERN, who presented

s/CERN/CERNET/ - credit where credit is due.

well... yes.

...

their v4/v6 translator code that supports over 400,000 chinese academics on native IPv6 - the IPv4 was relegated to the translator box and the DNS. -- Simon.

On Friday 26 March 2010 02:10:45 pm Mark Andrews wrote:

In message <201003261157.23601.lowen@pari.edu>, Lamar Owen writes:

...

"Hey, great presentation. Compelling arguments. But I have one question: will our existing gear that's not yet fully depreciated handle it? No?

What percentage of your equipment already supports IPv6? Most 5 year old pieces of equipement already have IPv6 support. It just needs to be enabled.

While my hypothetical answer was intentionally worst-case, with just-barely- too-old hypothetical hardware being mentioned, in reality my situation is dealing with in some cases much older equipment. I could go into detail, but you guys don't want to read my pity party, I'm sure. But "supporting IPv6" and "handling it [dual stack with comparable throughput]" are two different things.

...

No, we cannot afford to forklift upgrade now.

IPv6 is *not* a "forklift upgrade".

I have few routers that will do IPv6 at all, and even fewer that will do it efficiently. Where we have layer 3 switches, none will do IPv6 in hardware, and only one will do it in software (OSR 7609). For us, efficient dual-stack is a forklift upgrade.

Turning on IPv6 doesn't really affect the amount of bandwith you use.

Not my point; if I have to spend on hardware/software upgrades (both being expensive, especially for out-of-contract hardware), then that's less dollars we have to spend on bandwidth. Thus I lower my bandwidth, and spend that previously-opex money on capex instead. [snip] Don't misunderstand; we are and have been working on our plan for rolling out dual-stack, and I hope to have an IT intern this summer who will do the grunt work. I'm just having to try to be frugal when doing so, and with an understanding of the limitations of our older gear; I don't plan on being bit by some surprise 'feature' on one of our arcane pieces of gear. Once we understand what can do what and how fast it can do what it does, then we can intelligently redeploy equipment to produce the least pain at the least cost when IPv6 is enabled on it. And if we have to purchase some newer kit, well, we'll cross that bridge when we come to it. It will be a tough sell when we come to that bridge. For instance, terminating a slow MetroE on Cisco 12000 1 port GE. Overkill, on first glance, but not when you factor the actual IPv6 performance on that linecard. And if already have that gear, fully amortized, then you've reduced your implementation cost (maybe not opex, but it would take a lot of reduction in opex to offset the reduction in capex), and thus made it more likely to happen.

...

At the CxO level, it's all about the money. Or the lack therof.

Turn on IPv6 should be a $0 cost. Fully supporting IPv6 on all the services you offer will have some cost.

Nothing is $0 cost. Time is money, after all. But I do appreciate all the advice I have gleaned from NANOG and c-nsp over the years on the various and sundry ways people have performed the 'addition' of IPv6 to their IPv4 networks. And I thank all those who have shared their experiences; even if it didn't help anyone else, it has helped this non-profit. And while I understand most of the issues involved in the negative impact of not going dual-stack, and am in full agreement that we need to do so, I still have to look at the economic reality of the situation. Yes, in order to get this done in this economy you (or your department head, or whatever) have to get your CIO/CTO and maybe the CEO on board (typically the CIO would get the CEO on board). But even with them on board the costs may be greater than the bottom line can currently bear. And to get the CxO's on board you have to speak the C language....no, not that C, but the language of the CxO. And that's dollars and cents; cost-benefit, etc. Business 101. Having said all that, we are well on the way to getting the equipment selection phase (among equipment we already have on hand or in service) completed. We know what equipment we have that will definitely not work, and we know what equipment we have on hand that definitely will work. Now we have to determine how well that workable equipment will work, and if there are ways to continue to use some of the equipment that is in service, but not able to handle IPv6.

On Monday 29 March 2010 07:17:28 pm Doug Barton wrote:

However, none of that is relevant to the fact that a change IS coming, whether you're ready for it or not. The questions are, what will the change(s) be, how soon, and how will it/they affect me? [snip] So the question is not, "Can I afford to make a change?" The questions are as above, what, and how soon? This is why "we" have been telling people for years to work IPv6 requirements into all NEW stuff (networking hardware, end-user systems, b/w contracts) so that WHEN the changes start to affect you you won't have to do a forklift upgrade.

The nature of these changes (what, how soon, how will I be affected) will be entirely determined by how many can afford the costs of the implementation, and how soon they can afford it, as well as how quickly others can afford it; the more 'others' that can afford it, the more desirable affording it becomes to that set of all 'others' severally. One problem I see is one of marketing; marketing towards a negative is typically much less effective than marketing a positive. Market what people can do with IPv6, not what they can't do without IPv6. The 'IPv4 address space is running out' line is much weaker than it should be (with CxO's), because it's marketing a negative. The 'wow, here's valuable stuff you can do only with IPv6' is much more compelling. What is that 'valuable stuff?' (rhetorical question, I've seen some lists, they're not a compelling as they could be) The biggest problem with using the IPv4 allocation shortage as a negative is that it's not even a hard negative, really, not like Y2K, the most successful negative marketing example that I can think of, was. But this is different; when the IPv4 space is fully allocated, my existing services won't just up and quit. I'll have to do something other than get more IPv4, of course, and I'll start by being creative with how the existing services are allocated their IPv4 space, work my way up to some NAT-PT to overlap multiple services on a single IP, all the while looking at what the IPv6 addition will cost me, and will gain me. I mean, really: address space doesn't technically run out; it just all gets allocated; IP addresses are not consumables, but to a degree they're capital. But what the RIR's give, the RIR's can take away, or rearrange. And you asymptotically approach having 4 billion AS's running /32 networks with multi- layer NAT on the eyeballs and deep name-based virtual hosting (usable since HTTP v1.1) on the content side. And an enhancement to DNS allowing a port number to be part of an A record. But if no one (or close enough to 'no one') can afford to do IPv6, then IPv6 won't happen and the above scenario becomes more likely. Likewise, if everyone (or close enough to 'everyone') can afford to do IPv6, then IPv6 will happen quickly. Those are the two ends of the 'affordability' vs. 'implementation speed' continuum. Tactically, can I afford to do IPv6? No; and it's mostly a labor issue, even though hardware and software upgrades must be purchased. Tactically, can I afford to not do IPv6? Yes. The cost of not implementing in the tactical short-term is not yet enough to offset the cost of implementing, although both costs go up the longer the delay is. Strategically, can I afford to do IPv6? Hopefully, but it might require some creative budgeting (hmm, IPv6, or replace the batteries in the UPS's....). Strategically, can I afford to not do IPv6? Of course not; my strategic plan must involve IPv6 in some way; it's been in the strategic plan for a while, now, in both Porsche and Volkswagen editions (flat 6 vs flat 4...sorry for the arcane pun). But I've got to keep my fiscal head above water before I can implement the strategic plan, otherwise there won't be a strategic plan or even a need for a strategic plan.

On Wed, Mar 10, 2010 at 10:00 PM, Daniel Senie <dts@senie.com> wrote:

Well, it's like this... there's still no native IPv6 connectivity in most data centers, residences, >businesses or wireless, most vendors of networking equipment have not had a lot of mileage on >their IPv6 code if they even have it fully working, and, frankly, the IPv6 community has been >predicting a falling sky for so long that people just gave up listening. Add in a whole lot of other bits >of argument that just exasperate those dealing with today's problems, and it's pretty easy to >understand, if you've not been one of the ones pushing IPV6 for all these years, that there's a lot of >listener fatigue.

I fall into this category, but I'm trying to get better. This may be OT for this forum, but as someone whose network admin hat has mostly been at the LAN/MAN level, I'm less concerned about IPv6 peering, etc. then I am with what applications/servers don't play well with IPv6 and how do I work around those issues. Where does one go to find out how organizations have switched their internal IT infrastructure to IPv6? Does it make sense/work to do this for internal operations even if our outside connections are IPv4 only (forget about tunneling). Even more mundane questions like how to deal with IPv4 only networked printers when everything else is IPv6? If anyone in the Boston metro area wants to present to the local system administrators group (www.bblisa.org) on why we should care (and more importantly what to do) please contact me off list. We're mostly a bunch of senior Unix system administrator who are comfortable in our IPv4 world and (I think) see IPv6 as a whole bunch of work to mostly get back to where we already are. We've all heard about the coming address apocalypse, but it always seems somewhere in the distant future. Thanks, Bill Bogstad

In message <2d6a9f6f1003111016t16ddc73frc4a430e22089149d@mail.gmail.com>, Bill Bogstad writes:

I fall into this category, but I'm trying to get better. This may be OT for this forum, but as someone whose network admin hat has mostly been at the LAN/MAN level, I'm less concerned about IPv6 peering, etc. then I am with what applications/servers don't play well with IPv6 and how do I work around those issues.

You test and file bug reports. Multi-homing support has been a host requirement for 20+ years now. IPv4 + IPv6 is just a example of multi-homing so there really should be no reason for any application to break when IPv6 support is added.

Where does one go to find out how organizations have switched their internal IT infrastructure to IPv6?

I think you will find that most organizations *added* IPv6.

Does it make sense/work to do this for internal operations even if our outside connections are IPv4 only (forget about tunneling). Even more mundane questions like how to deal with IPv4 only networked printers when everything else is IPv6?

I don't recommend turning on IPv6 internally without having external IPv6 connectivity. You don't have to offer IPv6 service publically but being able to get out to the internet over IPv6 removes a whole class of problems in applications which don't support multi-homing properly and try IPv6 first. You really don't want all the timeouts. This doesn't have to be native IPv6 connectivity. Tunnels work just fine for this initially. As for IPv4 only printers you can continue to run dual stack internally forever if you want. Otherwise put them on their own vlan and connect to them over NAT64 or run a proxy service.

If anyone in the Boston metro area wants to present to the local system administrators group (www.bblisa.org) on why we should care (and more importantly what to do) please contact me off list. We're mostly a bunch of senior Unix system administrator who are comfortable in our IPv4 world and (I think) see IPv6 as a whole bunch of work to mostly get back to where we already are. We've all heard about the coming address apocalypse, but it always seems somewhere in the distant future.

Thanks, Bill Bogstad -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

Well, those UDP captures appear to be BitTorrent Peer-to-Peer file sharing traffic, or something disguised as such. Note the "64 31 3a 61 64 32 3a 69 64 32 30 3a" and also the textual reference to info_hash On Fri, Mar 12, 2010 at 12:18 AM, Joe <jbfixurpc@gmail.com> wrote:

Not to distract from the IPV4/IPV6 thread, but just wondering if anyone has seen this beavior or perhaps can enlighten me to its orgin/virus/meaning?

Internet Protocol, Src: 183.0.215.179 (183.0.215.179), Dst: 192.168.1.52 (192.168.1.52) User Datagram Protocol, Src Port: 64514 (64514), Dst Port: 46993 (46993) Data (101 bytes)

0000  64 31 3a 61 64 32 3a 69 64 32 30 3a 49 10 78 b3   d1:ad2:id20:I.x. 0010  9d 3f ab 23 75 7e d4 35 d7 cf c0 13 98 bf 84 30   .?.#u~.5.......0 0020  39 3a 69 6e 66 6f 5f 68 61 73 68 32 30 3a 09 61   9:info_hash20:.a 0030  e1 d8 9d cf ab 6a 2e 32 e8 42 92 73 b3 41 a3 72   .....j.2.B.s.A.r 0040  c7 f1 65 31 3a 71 39 3a 67 65 74 5f 70 65 65 72   ..e1:q9:get_peer 0050  73 31 3a 74 38 3a 31 30 30 30 34 32 35 35 31 3a   s1:t8:100042551: 0060  79 31 3a 71 65                                    y1:qe

Internet Protocol, Src: 183.0.215.179 (183.0.215.179), Dst: 192.168.1.52 (192.168.1.52) User Datagram Protocol, Src Port: 64514 (64514), Dst Port: 46993 (46993) Data (101 bytes)

0000  64 31 3a 61 64 32 3a 69 64 32 30 3a 49 10 78 b3   d1:ad2:id20:I.x. 0010  9d 3f ab 23 75 7e d4 35 d7 cf c0 13 98 bf 84 30   .?.#u~.5.......0 0020  39 3a 69 6e 66 6f 5f 68 61 73 68 32 30 3a 09 61   9:info_hash20:.a 0030  e1 d8 9d cf ab 6a 2e 32 e8 42 92 73 b3 41 a3 72   .....j.2.B.s.A.r 0040  c7 f1 65 31 3a 71 39 3a 67 65 74 5f 70 65 65 72   ..e1:q9:get_peer 0050  73 31 3a 74 38 3a 31 30 30 30 34 32 35 35 31 3a   s1:t8:100042551: 0060  79 31 3a 71 65                                    y1:qe

I'm seeing thousands of these per minute at one location, hundreds of unique ip addresses. Some sort of bot net maybe?

Thanks much

Joe

-- -J

On Fri, Mar 12, 2010 at 11:42:50AM +1100, Mark Andrews wrote:

...

Does it make sense/work to do this for internal operations even if our outside connections are IPv4 only (forget about tunneling). Even more mundane questions like how to deal with IPv4 only networked printers when everything else is IPv6?

As for IPv4 only printers you can continue to run dual stack internally forever if you want. Otherwise put them on their own vlan and connect to them over NAT64 or run a proxy service.

Our approach to v6 deployment has always been about enabling capability where it is available. The trick is then to have the right tools to manage and monitor it. The interesting thing about printers is that even quite low end network printers (like the HP Laserjet I have) have had IPv6 for quite a while. You can even configure DHCPv6 on the one I'm using. Just look for capabilities/features as you refresh equipment and it makes things that little easier. Tim

Owen DeLong <owen@delong.com> writes:

I spend much of my time talking to groups of people about this. I have managed to get several members of such groups from denial to bargaining and sometimes eve depression in a single session.

I did several presentations about IPv6 basics myself and there was very positive feedback but those people had already in interest in IPv6. I always quote an admin form a big German university: "We'll start with IPv6 in 13 years. It's when my colleague retires."

On rare occasion, acceptance even starts to set in.

Thats true. I did one presentation, had a two hour train ride with someone from the audience and a couple of days later I got an email from him that his company network is running IPv6. But this is one person from a couple of hundred.

I think it is getting better and continuing to talk about it will help.

Thats also true and I'm looking forward to this weekend when I once again will try to tell people why they should learn IPv6 now. Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://www.quux.de | http://blog.quux.de | jabber: jenslink@guug.de | -------------------------------------------------------------------------

On 2010.03.04 20:55, Owen DeLong wrote:

Folks, I know that IPv4 is down to bread crumbs.

That's why I'm ready for IPv6 and hopefully the rest of you are or will be soon.

However, let's consider how much address space is saved by going from /30 to /31 on every point-to-point link in the internet...

Let's assume that there are ~1 million routers on the internet with an average of 8 point to point interfaces. (I think there are probably more like 1/4 million and the average is probably more like 2, but, absent real numbers, I'll be uber-conservative).

8 million /30s is 32 million IPs, or, 2 /8s world-wide. 8 million /31s is 16 million IPs, or, 1 /8 world-wide.

We burn roughly 14 /8s per year in new allocations and assignments.

So, assuming: 1. There are actually 8 million point to point links in the internet 2. All of them are currently /30s 3. Absolutely optimum use of addresses for all those links 4. All of them are converted to /31s

(none of these assumptions is likely in fact)

The most we could achieve would be to extend IPv4 freepool lifespan by roughly 26 days. Given the amount of effort sqeezing useful addresses out of such a conversion would require, I proffer that such effort is better spent moving towards IPv6 dual stack on your networks.

Owen, thanks for this picturesque description. Whoever recommended the FAQ, add this equation into it. I *wholeheartedly* agree with Owen's assessment. Even spending time trying to calculate a rebuttal to his numbers is better spent moving toward dual-stack ;) Nice. Steve ps. and I'm just tiny. I just enjoy seeing reports of the big boys moving forward, and watching my v6 routing table grow...

On Fri, Mar 5, 2010 at 4:39 AM, <bmanning@vacation.karoshi.com> wrote:

On Thu, Mar 04, 2010 at 10:05:43PM -0500, Steve Bertrand wrote:

...

On 2010.03.04 20:55, Owen DeLong wrote:

...

I proffer that such effort is better spent moving towards IPv6 dual stack on your networks.

I *wholeheartedly* agree with Owen's assessment. Even spending time trying to calculate a rebuttal to his numbers is better spent moving toward dual-stack ;)

Nice.

Steve

       er... what part of dual-stack didn't you understand?        dual-stack consumes exactly the same number of v4 and v6 addresses.

       if you expect to dual-stack everything - you need to look again.        either you are going to need:

       lots more IPv4 space

       stealing ports to mux addresses

       run straight-up native IPv6 - no IPv4 (unless you need to talk to        a v4-only host - then use IVI or similar..)

       imho - the path through the woods is an IVI-like solution.

I have a similar perspective. Your point about dual-stack is spot-on. Thats why the future, IMHO, will look like CGN / LSN meaning: NAT444, NAT64, and DS-lite. I am very focused on NAT64 since i believe all the right incentives are in place in that solution for both service providers and content folks to move to IPv6 as quickly as possible, while maintaining some level of IPv4 functions. The major limitation here is that some old-school and fringe applications are IPv4-only while the major applications (major web browsers, email clients, ...). The IPv6 capable applications have reached the tipping point where it is now viable to do IPv6-only + NAT64. There is one of other catch with NAT64 and IPv6-only. It breaks communications with IPv4 literals. Now, you might says that IPv4 literals in URLs are very seldom.... well ... have a look at how Akamai does a lot of their streaming. I just hope it does not come to a show-down where networks move to IPv6-only since IPv4 is a goner and now Akamai content is not available while IPv6 early adopters like Google and Limelight laugh all the way to bank. Hint: Akamai -- stop using IPv4 literals, and and if you can't use IPv6 then please use FQDNs so you don't break services to your customers. IVI is stateless, which means it requires 1 to 1 IPv4 to IPv6 mapping. NAT64 allows multiplexing.

--bill

On Sat, Mar 06, 2010 at 02:23:59AM +0800, Owen DeLong wrote:

Owen (who is very glad these are technologies OTHER people will use)

:) My point was not really to push a particular technology, although we believe ds-lite is worth looking at or ISC wouldn't have implemented and released it. (Among other things it does put the pain of figuring out deployment in more or less the same place that IPv4 exhaustion will be felt: in service-provider networks that will need to grow after the end of the unallocated IPv4 without leaving behind legacy customers.) My point was more that there *are* alternatives in this space that didn't exist until fairly recently, there's now a much bigger solution space for the gap between IPv4 runout and global-scale native IPv6 deployment than maybe people think.... But it's going to take some effort to find and use the technology that's right for you and your network, so start allocating that resource now if you haven't yet. Suzanne

On 3/5/2010 06:38, Cameron Byrne wrote:

There is one of other catch with NAT64 and IPv6-only. It breaks communications with IPv4 literals. Now, you might says that IPv4 literals in URLs are very seldom.... well ... have a look at how Akamai does a lot of their streaming. I just hope it does not come to a show-down where networks move to IPv6-only since IPv4 is a goner and now Akamai content is not available while IPv6 early adopters like Google and Limelight laugh all the way to bank.

One of the reasons I like the idea of DS-Lite. It may not be as native-IPv6 pure-and-holy as NAT64/DNS64, but it allows end users, IPv4 only applications, and legacy/non-IPv6 equipment to actually use IPv4 addresses. When the end user's favorite application stops working, or he can't play games online with his Xbox 360, he won't care about any explanations of NAT64/DNS64, or whose fault it is. He'll just want things to work. DS-Lite still allows this, and doesn't have any real impact on IPv4 exhaustion, since the end user will be issued RFC1918s, (likely) overlapped with other end users' RFC1918s. I also speculate that if one takes a large user community, say, customers of an ISP, and put them on NAT64/DNS64, we'll likely discover a lot more "IPv4 only" applications/services/appliances out there than we were expecting via the explosive ringing of flooded help desk lines. :p Granted, DS approaches will slow native IPv6 adoption a bit, but I think the real-world alternative is chaos. I personally prefer a scenario where users can go on using the internet as they've always done, likely oblivious to whether any particular site or application is using IPv6 or IPv4, while "behind the curtain" these same sites/applications are switching over to native IPv6, than a scenario where things simply stop working for them. Also, I hope that any pain associated with going through a CGN used in any of these sorts of approaches, and/or the benefits of native IPv6, will speed native IPv6 adoption more than any transition method might slow it. One can hope. :p

On Fri, Mar 05, 2010 at 08:40:19AM -0600, Dan White wrote:

On 05/03/10 12:39 +0000, bmanning@vacation.karoshi.com wrote:

...

er... what part of dual-stack didn't you understand? dual-stack consumes exactly the same number of v4 and v6 addresses.

I would expect the number of v6 addresses assigned to a host to be a multiple of the number of v4 addresses, depending on the type of host.

true that... i was being - perhaps - too literal.

...

imho - the path through the woods is an IVI-like solution.

Or, dual stack today. When you've run out of IPv4 addresses for new end users, set them up an IPv6 HTTP proxy, SMTP relay and DNS resolver and/or charge a premium for IPv4 addresses when you start to sweat.

and then we are back to drc's comments.

-- Dan White

On 06/03/2010, at 1:10 AM, Dan White wrote:

On 05/03/10 12:39 +0000, bmanning@vacation.karoshi.com wrote:

...

...

I *wholeheartedly* agree with Owen's assessment. Even spending time trying to calculate a rebuttal to his numbers is better spent moving toward dual-stack ;)

Nice.

Steve

er... what part of dual-stack didn't you understand? dual-stack consumes exactly the same number of v4 and v6 addresses.

I would expect the number of v6 addresses assigned to a host to be a multiple of the number of v4 addresses, depending on the type of host.

That's because you haven't done it yet. When you start doing it, you'll see that the number of v6 addresses assigned to a host will bear almost no relationship whatsoever to any metrics you've previously used to allocated IPv4 addresses.

Or, dual stack today. When you've run out of IPv4 addresses for new end users, set them up an IPv6 HTTP proxy, SMTP relay and DNS resolver and/or charge a premium for IPv4 addresses when you start to sweat.

I expect that once we all work out that we can use SP-NAT to turn "dynamic IPv4 addresses" into "shared dynamic IPv4 addresses," we'll have enough spare IPv4 addresses for much of the foreseeable future. If I have half a million residential subscribers and I can get ten subscribers onto each NATted IPv4 addresses, then I only need 50,000 addresses to service them. Yet I have half a million addresses *right now*, which I won't be giving back to my RIR. So that turns into 450,000 saleable addresses for premium customers after the SP-NAT box is turned on, right? Problem solved :-) - mark -- Mark Newton Email: newton@internode.com.au (W) Network Engineer Email: newton@atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223

On Sat, Mar 6, 2010 at 8:14 AM, Dan White <dwhite@olp.net> wrote:

On 06/03/10 23:36 +1030, Mark Newton wrote:

...

On 06/03/2010, at 1:10 AM, Dan White wrote:

...

On 05/03/10 12:39 +0000, bmanning@vacation.karoshi.com wrote:

...

...

I *wholeheartedly* agree with Owen's assessment. Even spending time trying to calculate a rebuttal to his numbers is better spent moving toward dual-stack ;)

Nice.

Steve

       er... what part of dual-stack didn't you understand?        dual-stack consumes exactly the same number of v4 and v6 addresses.

I would expect the number of v6 addresses assigned to a host to be a multiple of the number of v4 addresses, depending on the type of host.

That's because you haven't done it yet.  When you start doing it, you'll see that the number of v6 addresses assigned to a host will bear almost no relationship whatsoever to any metrics you've previously used to allocated IPv4 addresses.

I have. Windows XP, for instance, will auto assign multiple addresses during auto configuration, including random identifiers.

If you through in multiple routers for redundancy, then you start to have a multiplying effect, compared to your typical one v4 address per end user host.

Also, the number of publicly routeable v6 addresses assigned to hosts is surely much higher, on average, than the public v4 addresses assigned to those hosts.

...

...

Or, dual stack today. When you've run out of IPv4 addresses for new end users, set them up an IPv6 HTTP proxy, SMTP relay and DNS resolver and/or charge a premium for IPv4 addresses when you start to sweat.

I expect that once we all work out that we can use SP-NAT to turn "dynamic IPv4 addresses" into "shared dynamic IPv4 addresses," we'll have enough spare IPv4 addresses for much of the foreseeable future.

If I have half a million residential subscribers and I can get ten subscribers onto each NATted IPv4 addresses, then I only need 50,000 addresses to service them.  Yet I have half a million addresses *right now*, which I won't be giving back to my RIR.  So that turns into 450,000 saleable addresses for premium customers after the SP-NAT box is turned on, right?

Possibly. I understand how to do HTTP proxies today, and understand its limitations. But it's a far more appealing technology than all these future technologies being proposed that fit in the 'once we all work out that we can use' category.

These IPv6-only systems are not far out, i am running a beta service using NAT64/DNS64 today. I believe a reasonable level off basic service can be provided today using IPv6-only + NAT64/DNS64. And, of course, native IPv6 content is a better QoE than the common NAT44 folks have today. I have demonstrations of windows 7 netbooks and Symbian Nokia smartphones doing common function with only IPv6 addresses on the end systems, no IPv4 except for the translation pool on the NAT64: www.youtube.com/theipv6guy Folks are risking their business and their customers if they don't have an IPv6 plan, and when i say IPv6 plan i mean IPv6-only. This list has already examined how polluted the remaining free IPv4 blocks are ... and as others have pointed out, CGN will be an expensive and poor QoE reality for those clinging to IPv4

-- Dan White

In message <20100306184958.GA17785@mx.ytti.net>, Saku Ytti writes:

On (2010-03-06 10:07 -0800), Cameron Byrne wrote:

...

Folks are risking their business and their customers if they don't have an IPv6 plan, and when i say IPv6 plan i mean IPv6-only. This list has already examined how polluted the remaining free IPv4 blocks are ... and as others have pointed out, CGN will be an expensive and poor QoE reality for those clinging to IPv4

I'm personally afraid that EU+US companies may not see the risk. Majority of people in EU+US who want broadband and have purchase power for the services, should already have connectivity, as broadband penetration is somewhat complete.

Companies offering products/services may view that implementing IPv6 will not bring them new business, but implementing it carries non-zero cost. And providing access to consumers who are not potential customers increases costs without increasing revenue.

Not implementing IPv6 will start to lose them business soon as they won't be able to reach IPv6 only sites. Not quite yet but soon. While all the services that there customers want to reach are available over IPv4 they will be fine. Once they are not they people will start to leave for a competitor that does offer IPv6 access. ISP's need to be asking themselves how much business are they willing to lose before they deploy IPv6. If they answer is "none" they should be moving now.

The major losers in EU+US market seem to be start-ups, who can't get addresses and thus have fraction of the market size giving existing companies unfair competitive advantage, nearly impossible to overcome.

I would personally hope that EU+US would mandate that residential ISP add IPv6 to their subscribers by default, without possibility to opt-out in n years time. Hopefully n would be no more than 3.

APAC and Africa surely are completely different matter. -- ++ytti -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

On Mar 7, 2010, at 2:49 AM, Saku Ytti wrote:

On (2010-03-06 10:07 -0800), Cameron Byrne wrote:

...

Folks are risking their business and their customers if they don't have an IPv6 plan, and when i say IPv6 plan i mean IPv6-only. This list has already examined how polluted the remaining free IPv4 blocks are ... and as others have pointed out, CGN will be an expensive and poor QoE reality for those clinging to IPv4

I'm personally afraid that EU+US companies may not see the risk. Majority of people in EU+US who want broadband and have purchase power for the services, should already have connectivity, as broadband penetration is somewhat complete.

While it is more complete than many other countries, there are still rural areas where it is not, and, the relatively high churn rate in competitive markets will actually still lead to a need for increasing address allocations and assignments as customers move from ISPs that already have space for them to ISPs that need more space. If you look at the ARIN consumption statistics, or, the RIPE consumption statistics, there is certainly no indication that the demand for addresses has been significantly reduced in EU+US.

Companies offering products/services may view that implementing IPv6 will not bring them new business, but implementing it carries non-zero cost. And providing access to consumers who are not potential customers increases costs without increasing revenue.

It may not bring you new business, but, it may be necessary to avoid losing the business you have. Most businesses that are built on an MRR model have to pay attention to that. Generally speaking, customer retention is regarded as important in most such organizations.

The major losers in EU+US market seem to be start-ups, who can't get addresses and thus have fraction of the market size giving existing companies unfair competitive advantage, nearly impossible to overcome.

I think at least the first several such startups will be able to get space out of the /10 reserved for transitional technologies to provide front-end proxies and such for their services. Startup eye-ball ISPs may be at a greater disadvantage for a relatively short period of time as they will essentially have to deploy an IPv6 customer network along side a technology such as NAT64 or DS-LITE. However, the more of these are created, the more pressure there is for content and service providers to provide native IPv6 availability of their content and services, so, I think it will rapidly solve itself on that level.

I would personally hope that EU+US would mandate that residential ISP add IPv6 to their subscribers by default, without possibility to opt-out in n years time. Hopefully n would be no more than 3.

I wouldn't hold my breath on that. It simply doesn't map to the regulatory framework and culture prevalent in the US at this time. Owen

On Mar 7, 2010, at 1:47 AM, Saku Ytti wrote:

On (2010-03-07 14:21 +0800), Owen DeLong wrote:

...

While it is more complete than many other countries, there are still rural areas where it is not, and, the relatively high churn rate in competitive markets will actually still lead to a need for increasing address allocations and assignments as customers move from ISPs that already have space for them to ISPs that need more space.

My wording could have been better, by 'mostly complete' I was trying to be in mindset of company offering products and service over Internet. I think US is somewhere between 65-70& BB penetration? Companies might feel the part of the country not having BB accesss are not potential customers, perhaps due to lack of purchase power.

Us is somewhere close to 90% BB penetration in urban areas and closer to 30% in rural areas. Overall, that makes 65-70%. My point was that the raw 65-70% number is misleading because of the strong dichotomy between urban and rural instances in the US. While you may be right that some larger national companies may not feel the impact, do not underestimate the number of companies that depend on providing and delivering local content to these rural markets as well. Given the number of initiatives to expand rural broadband within the US, such as BTOP, I think there is potential here.

Interestingly enough, here local incumbent ex-monopoly started removing DSLAM network from remote rural areas, quoting it being unprofitable.

That would probably not happen here unless it was replaced by an alternative technology for the same market, lest it attract the attention of regulators. Additionally, one of the largest broadband providers in the US is Comcast. I suspect that of the US markets which are monopoly or duopoly Comcast is probably present in a majority of those markets. They have expressed a definite strategy for moving to IPv6 and enabling their residential customers to have IPv6 services. I think this fact will make it difficult for their competition to offer less and get away with it.

...

If you look at the ARIN consumption statistics, or, the RIPE consumption statistics, there is certainly no indication that the demand for addresses has been significantly reduced in EU+US.

But have these addresses been mostly delivered to new home users? Or have they been to new companies offering products and services?

The largest address consumers even today as I understand it are the residential "eye-ball" ISPs. However, even if it is new companies offering products and services, then, it will not take long after IPv4 runout for there to be a critical mass of IPv6-only companies in this area of the net. Either way, I think that IPv4 runout, in addition to creating a temporary train-wreck of end-user experiences for IPv4 content, will accelerate deployment of IPv6 on both sides of the equation and that any acceleration on one side will drive further acceleration on the other.

...

It may not bring you new business, but, it may be necessary to avoid losing the business you have. Most businesses that are built on an MRR model have to pay attention to that. Generally speaking, customer retention is regarded as important in most such organizations.

I can't see end users currently having IPv4 connectivity changing to provider who can't provide access to IPv4 sites. Which I believe would translate that all existing users will continue to have access to the service.

No, but, if their choice is between a current provider which offers extremely degraded IPv4 services without IPv6 and a provider which offers IPv6 services and a similarly degraded service which only affects IPv4-only content, I can see them switching rapidly towards the latter.

...

I think at least the first several such startups will be able to get space out of the /10 reserved for transitional technologies to provide front-end proxies and such for their services. Startup eye-ball ISPs may be at a greater disadvantage for a relatively short period of time as they will essentially have to deploy an IPv6 customer network along side a technology such as NAT64 or DS-LITE. However, the more of these are created, the more pressure there is for content and service providers to provide native IPv6 availability of their content and services, so, I think it will rapidly solve itself on that level.

I really hope you are correct. But I fear only way to fix the situation is to force IPv6 connectivity down the throat of every existing IPv4 end-user.

I hope not, because that simply won't happen.

Some companies sellings products and services might even find the new situation favourable, by not deploying IPv6, they make sure that users won't change to IPv6 only service as they need to reach the site, and thus they would be protecting themselves of new competition, who can only offer the service over IPv6.

I don't think i will work out that way. I think that new companies that need to offer new sites will use proxy servers and obtain VIP addresses out of the /10 reserved for transitional technologies. Thus, new services will be able to easily come up dual-stack with almost no disadvantage vs. their IPv4-only competition. Since their IPv4-only competition will then be providing an increasingly degraded user-experience to their end users, where as dual-stack end-users will get a full native user experience with the newer competitor on dual-stack, I think that the newer competitor will actually have the advantage here.

...

...

I would personally hope that EU+US would mandate that residential ISP add IPv6 to their subscribers by default, without possibility to opt-out in n years time. Hopefully n would be no more than 3.

I wouldn't hold my breath on that. It simply doesn't map to the regulatory framework and culture prevalent in the US at this time.

Quite right, but EU has history requiring rather more silly things, especially if it means getting free money with ridiculous monopoly claims.

I'm not sufficiently familiar with the EU regulatory climate to comment knowledgeably. I can say that I would not expect that to work in the US which is where I live. I'll even go out on a limb and say it is unlikely in Canada. Owen

On Sun, 07 Mar 2010 14:07:47 +0800, Owen DeLong said:

Interesting way of thinking about it. I suspect that rather than pay your premium prices, the customers you just degraded in order to charge them more for the service they had will look to your competitors for better service.

I suspect that in many areas, the incumbent monopoly/duopoly has done a sufficiently good job of lowering customer expectations to do this. They've already been marketing what should be baseline service as "premium" for years already, and I'm not seeing much motivation for them to change.

On Thu, Mar 4, 2010 at 4:44 PM, Stan Barber <sob@academ.com> wrote:

...

On Mar 4, 2010, at 1:30 PM, William Herrin wrote: Because we expect far fewer end users to multihome tomorrow than do today?

I would suggest that the ratio of folks that will multihome under IPv6 versus those that won't will get smaller. I base that on an assumption that NAT (as we know it today) will be less prevalent as IPv6 usage grows.

Alrighty then... -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004

On 2010.03.04 22:26, Steve Bertrand wrote:

On 2010.03.04 16:53, William Herrin wrote:

...

On Thu, Mar 4, 2010 at 4:44 PM, Stan Barber <sob@academ.com> wrote:

...

...

On Mar 4, 2010, at 1:30 PM, William Herrin wrote: Because we expect far fewer end users to multihome tomorrow than do today?

I would suggest that the ratio of folks that will multihome under IPv6 versus those that won't will get smaller. I base that on an assumption that NAT (as we know it today) will be less prevalent as IPv6 usage grows.

Alrighty then...

heh.

Stan, you've got things backwards, no matter which direction you are looking at things from. I'm thinking that you may have written the sentence incorrectly.

It's unfortunate, but it is reality.

Have you reviewed your RIR policy lately? v6 will be flying out the window soon, and your local RIR may be assigning PI space like candy.

Welcome IPv6.

fwiw, it didn't appear clear to me that my own comments reflected my feelings that the migration was a good thing ;) STeve

On Thu, Mar 4, 2010 at 11:15 PM, David Conrad <drc@virtualized.org> wrote:

On Mar 4, 2010, at 2:30 PM, William Herrin wrote:

...

Because we expect far fewer end users to multihome tomorrow than do today?

We do?

yea, it doesn't seem to follow based on what I'd seen at a large network provider, more people multihome over time, for reasons related to business continuity... (the comments about multihoming and nat just seem sideways, as well) -chris

On 03/05/2010 05:24 AM, William Herrin wrote:

On Thu, Mar 4, 2010 at 11:15 PM, David Conrad <drc@virtualized.org> wrote:

...

On Mar 4, 2010, at 2:30 PM, William Herrin wrote:

...

Because we expect far fewer end users to multihome tomorrow than do today?

We do?

Why do we expect this?

David,

Well, I don't know that "we" do, but Joel made a remarkable assertion that non-aggregable assignments to end users, the ones still needed for multihoming, would go down under IPv6.

A couple of months ago my then employer went to arin to get a direct v6 assignmentment. on the basis of the number of pops the resulting assignment was a /43. It'll be a while I imagine before another prefix is required. They like many organizations receiving direct assignments will not in all likelyhood end up with the handful of assignments (as it has in ipv4), because assignment number one is of sufficient size to support their subnetting needs for quite some time. As I also said the temptation to engage in deaggregate for traffic engineering purposes is there. If this is done right, direct assignment holders and ISPs are issued sufficiently large prefixes such that the prefix count per entity remains small.

I wondered about his reasoning. Stan then offered the surprising clarification that a reduction in the use of NAT would naturally result in a reduction of multihoming.

Regards, Bill

On Mar 5, 2010, at 11:55 PM, William Herrin wrote:

On Fri, Mar 5, 2010 at 10:44 AM, Joel Jaeggli <joelja@bogus.com> wrote:

...

On 03/05/2010 05:24 AM, William Herrin wrote:

...

Joel made a remarkable assertion that non-aggregable assignments to end users, the ones still needed for multihoming, would go down under IPv6.

A couple of months ago my then employer went to arin to get a direct v6 assignmentment. on the basis of the number of pops the resulting assignment was a /43. It'll be a while I imagine before another prefix is required.

Ah, I follow your reasoning. I'll be interested to learn whether the numbers agree. ARIN staff has reported before that the vast majority of IPv4 end user assignments go to organizations which do not subsequently return for additional assignments. In general it's the ISPs who come back for more allocations... I wonder if the minority of end-user orgs who do request additional space request enough additional blocks to make a difference in the routing tables.

Well, between that, and, the fact that ISPs should be asking for additional space a _LOT_ less frequently and all cases should be more likely to get an aggregable expansion of their allocation/assignment now that we are delegating by bisection, I think both of those things will reduce the rate at which growth within organizations increases the routing table by quite a bit. Owen

On Mar 5, 2010, at 10:44 AM, Joel Jaeggli wrote:

If this is done right, direct assignment holders and ISPs are issued sufficiently large prefixes such that the prefix count per entity remains small.

This sort of assumes Internet connectivity models of today, specifically that most address assignments are singly-homed and thus can be aggregatedd within a larger provider independent block, will remain the model of tomorrow. I have some skepticism this will be true. When entertainment, communications, monitoring, etc. are all provided via always-on IP connectivity, I suspect you'll see folks have less tolerance for even momentary outages. And that's not even considering mobility solutions that rely on the routing system (e.g., stuff like Boeing's Connexion (RIP)). We'll see I suppose. Regards, -drc

I was not trying to say there would be a reduction in multihoming. I was trying to say that the rate of increase in non-NATed single-homing would increase faster than multihoming. I guess I was not very clear. Here is the basis for my assumptions since they are not clear: 1. Almost all home users (not businesses) that are connected to the Internet today via IPv4 are behind some kind of NAT box. In some cases, two NATs (one provided by the home user's router and one provided by some kind of ISP). There is no need for this using IPv6 to communicate with other IPv6 sites. 2. Almost all home users referenced above are not multi-homed today on IPv4. I am having a hard time believing that they will want to change that under IPv6. However, someone may have a case I have not thought about. Ergo, I believe their will be an increase in non-multihomed non-NATed endpoints as IPv6 becomes the standard way folks connect. Now, one thing that could negatively impact this would be providers that insist on providing some kind of IPv6/IPv6 NAT. Creating that kind of walled garden for IPv6 in the long term does not make alot of sense to me, but I am very interested in other points of view on that. On Mar 5, 2010, at 7:24 AM, William Herrin wrote:

On Thu, Mar 4, 2010 at 11:15 PM, David Conrad <drc@virtualized.org> wrote:

...

On Mar 4, 2010, at 2:30 PM, William Herrin wrote:

...

Because we expect far fewer end users to multihome tomorrow than do today?

We do?

Why do we expect this?

David,

Well, I don't know that "we" do, but Joel made a remarkable assertion that non-aggregable assignments to end users, the ones still needed for multihoming, would go down under IPv6. I wondered about his reasoning. Stan then offered the surprising clarification that a reduction in the use of NAT would naturally result in a reduction of multihoming.

Regards, Bill

-- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004

Ok. Let's get back to some basics to be sure we are talking about the same things. First, do you believe that a residential customer of an ISP will get an IPv6 /56 assigned for use in their home? Do you believe that residential customer will often choose to multihome using that prefix? Do you believe that on an Internet that has its primary layer 3 protocol is IPv6 that a residential customer will still desire to do NAT for reaching IPv6 destinations? I am looking forward to your response. On Mar 18, 2010, at 2:25 PM, William Herrin wrote:

...

On Mar 5, 2010, at 7:24 AM, William Herrin wrote:

...

Joel made a remarkable assertion that non-aggregable assignments to end users, the ones still needed for multihoming, would go down under IPv6. I wondered about his reasoning. Stan then offered the surprising clarification that a reduction in the use of NAT would naturally result in a reduction of multihoming.

On Thu, Mar 18, 2010 at 11:07 AM, Stan Barber <sob@academ.com> wrote:

...

I was not trying to say there would be a reduction in multihoming. I was trying to say that the rate of increase in non-NATed single-homing would increase faster than multihoming. I guess I was not very clear.

Hi Stan,

Your logic still escapes me. Network-wise there's not a lot of difference between a single-homed IPv4 /32 and a single-homed IPv6 /56. Host-wise there may be a difference but why would you expect that to impact networks?

Regards, Bill Herrin

-- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004

In this case, I am talking about an IPv6<->IPv6 NAT analogue to the current IPv4<->IPv4 NAT that is widely used with residential Internet service delivery today. I believe that with IPv6 having much larger pool of addresses and each residential customer getting a large chunk of addresses will make IPv6<->IPv6 NAT unnecessary. I also believe that there will be IPv6 applications that require end-to-end communications that would be broken where NAT of that type used. Generally speaking, many users of the Internet today have not had the luxury to experience the end-to-end model because of the wide use of NAT. Given that these customers today don't routinely multihome today, I currently believe that behavior will continue. Multihoming is generally more complicated and expensive than just having a single connection with a default route and most residential customers don't have the time, expertise or financial support to do that. So, the rate of multihoming will stay about the same even though the number of potential sites that could multihome could increase dramatically as IPv6 takes hold. Now, there are clearly lots of specifics here that may change over time concerning what the minimum prefix length for IPv6 advertisements might be acceptable in the DFZ (some want that to be /32, other are ok with something longer). I don't know how that will change over time. I also think that that peering will continue to increase and that the prefix lengths that peers will exchange with each other are and will continue to be less constrained by the conventions of the DFZ since the whole point of peering is to be mutually beneficial to those two peers and their customers. But, that being said, I don't think residential customers will routinely do native IPv6 peering either. I think IP6-in-IPv4 tunneling is and will continue to be popular and that already makes for some interesting IPv6 routing concerns. Hope that clarifies my comment for you. Obviously, they are my opinions, not facts. The future will determine if I was seeing clearly or was mistaken in how these things might unfold. However, I think a discourse about these possibilities is helpful in driving consensus and that's one of the valuable things about mailing lists like this. On Mar 18, 2010, at 8:20 PM, Christopher Morrow wrote:

On Thu, Mar 18, 2010 at 7:36 PM, Stan Barber <sob@academ.com> wrote:

...

Ok. Let's get back to some basics to be sure we are talking about the same things.

First, do you believe that a residential customer of an ISP will get an IPv6 /56 assigned for use in their home? Do you believe that residential customer will often choose to multihome using that prefix? Do you believe that on an Internet that has its primary layer 3 protocol is IPv6 that a residential customer will still desire to do NAT for reaching

how are nat and ipv6 and multihoming related here? (also 'that has a primary layer 3 protocol as ipv6' ... that's a LONG ways off)

-chris

...

IPv6 destinations?

I am looking forward to your response.

On Mar 18, 2010, at 2:25 PM, William Herrin wrote:

...

...

On Mar 5, 2010, at 7:24 AM, William Herrin wrote:

...

Joel made a remarkable assertion that non-aggregable assignments to end users, the ones still needed for multihoming, would go down under IPv6. I wondered about his reasoning. Stan then offered the surprising clarification that a reduction in the use of NAT would naturally result in a reduction of multihoming.

On Thu, Mar 18, 2010 at 11:07 AM, Stan Barber <sob@academ.com> wrote:

...

I was not trying to say there would be a reduction in multihoming. I was trying to say that the rate of increase in non-NATed single-homing would increase faster than multihoming. I guess I was not very clear.

Hi Stan,

Your logic still escapes me. Network-wise there's not a lot of difference between a single-homed IPv4 /32 and a single-homed IPv6 /56. Host-wise there may be a difference but why would you expect that to impact networks?

Regards, Bill Herrin

-- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004

On 2010-03-22 17:42, Christopher Morrow wrote:

the current ietf draft for 'simple cpe security' (draft-ietf-v6ops-cpe-simple-security-09.txt) is potentially calling for some measures like nat, not nat today but...

This is being reversed as we speak. Simon -- NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org

On Mar 22, 2010, at 5:42 PM, Christopher Morrow wrote:

On Mon, Mar 22, 2010 at 3:53 PM, Stan Barber <sob@academ.com> wrote:

...

In this case, I am talking about an IPv6<->IPv6 NAT analogue to the current IPv4<->IPv4 NAT that is widely used with residential Internet service delivery today.

I don't necessarily see 6-6 nat being used as 4-4 is today, but I do think you'll see 6-6 nat in places. the current ietf draft for 'simple cpe security' (draft-ietf-v6ops-cpe-simple-security-09.txt) is potentially calling for some measures like nat, not nat today but...

That would be unfortunate, but, not unlikely.

...

I believe that with IPv6 having much larger pool of addresses and each residential customer getting a large chunk of addresses will make IPv6<->IPv6 NAT unnecessary. I also believe that there will be IPv6 applications that require end-to-end communications that would be broken where NAT of that type used. Generally speaking, many users of

I think you'll see apps like this die... quickly, but that's just my opinion.

This I think is both unfortunate and unlikely. They haven't died yet in IPv4 land, we just use ridiculous heroic measures like STUN, SNAT, UPNP, etc. to attempt to circumvent the damage known as NAT.

...

the Internet today have not had the luxury to experience the end-to-end model because of the wide use of NAT.

Given that these customers today don't routinely multihome today, I currently believe that behavior will continue. Multihoming is generally more complicated and expensive

That's not obvious. if a low-cost (low pain, low price) means to multihome became available I'm sure it'd change... things like shim-6/mip-6 could do this.

Heh.. I don't see shim-6 deployment as low-pain. I think we will eventually need a true ID/Locator split, and I have an idea how it might be accomplished without altering the packet size, but, time will tell.

...

than just having a single connection with a default route and most residential customers don't have the time, expertise or financial support to do that. So, the rate of multihoming will stay about the same even though the number of potential sites that could multihome could increase dramatically as IPv6 takes hold.

Now, there are clearly lots of specifics here that may change over time concerning what the minimum prefix length for IPv6 advertisements might be acceptable in the DFZ (some want that to be /32, other are ok with something longer). I don't know how that will change over time. I also think that that peering will continue to increase and that the prefix lengths that peers will exchange with each other are and will continue to be less constrained by the conventions of the DFZ since the whole point of peering is to be mutually beneficial to those two peers and their customers. But, that being said, I don't think residential customers will routinely do native IPv6 peering either. I think IP6-in-IPv4 tunneling is and will continue to be popular and that already makes for some interesting IPv6 routing concerns.

I firmly hope that ipv6-in-ipv4 dies... tunnel mtu problems are horrific to debug.

Indeed. I think at worst, IPv6-in-IPv4 will advance to a state where IPv4 MTU problems become largely historic. This will occur because as IPv6 gains popularity, an increasing number of IPv4-only users will be forced to this as their only means of achieving IPv6 connections in many cases. I wish it weren't so, but, it'll be a wonderful surprise if 6in4 dies any time soon. Arguably, having it become popular enough to force resolution to the various IPv4 MTU issues by default would be just as useful. Owen

On Mar 22, 2010, at 9:39 PM, Daniel Senie wrote:

On Mar 22, 2010, at 6:53 PM, Stan Barber wrote:

...

In this case, I am talking about an IPv6<->IPv6 NAT analogue to the current IPv4<->IPv4 NAT that is widely used with residential Internet service delivery today.

I believe that with IPv6 having much larger pool of addresses and each residential customer getting a large chunk of addresses will make IPv6<->IPv6 NAT unnecessary. I also believe that there will be IPv6 applications that require end-to-end communications that would be broken where NAT of that type used. Generally speaking, many users of the Internet today have not had the luxury to experience the end-to-end model because of the wide use of NAT.

End-to-end applications will face much of the same interruption issues in the future as today. They will face firewall equipment that inspects the packet stream and purposefully blocks applications that are potentially harmful (e.g. vectors for systems infection). While the address translation part of stateful inspection firewall processing may not be used for IPv6, all other aspects of firewall function will be as applicable to IPv6 packets as they are to IPv4.

Sure, but, for the most part, it is the address translation part that does unintended damage to end-to-end protocols. The stateful inspection is intended interference, so usually a work-around is undesirable. In the case of NAT, there's often a need for a workaround due to the unintended consequences. Hence the creation of STUN, SNAT, UPNP, etc.

...

Given that these customers today don't routinely multihome today, I currently believe that behavior will continue. Multihoming is generally more complicated and expensive than just having a single connection with a default route and most residential customers don't have the time, expertise or financial support to do that. So, the rate of multihoming will stay about the same even though the number of potential sites that could multihome could increase dramatically as IPv6 takes hold.

I deal more with small businesses than residences, but I will take issue with the premise presented. Today there are many products, especially firewalls that allow "multihoming" of a sort using multiple upstream connections in conjunction with IPv4 and NAT. This is fairly simple, and can allow smaller offices, such as a company's field offices to combine multiple broadband connections, such as a cable modem and a DSL connection, to attain higher reliability and increased bandwidth.

Albeit with a number of less than ideal tradeoffs vs. a BGP-based multihoming solution. With the smaller routing table afforded by IPv6, this will be less expensive. As a result, I suspect there will be more IPv6 small multihomers. That's generally a good thing.

Because these appear to be just two broadband customer modems in one location (whether small business or residence), you cannot easily determine that such combining is being done.

As this is a VERY useful, and well-used capability, it will be interesting to see what the vendors choose to offer in their equipment as IPv6 support improves.

It's pretty easy to do this in IPv6 without NAT. Just advertise both prefixes in the RA from the device and you're done. Owen

On Mar 22, 2010, at 10:27 PM, Mark Newton wrote:

On 23/03/2010, at 3:43 PM, Owen DeLong wrote:

...

With the smaller routing table afforded by IPv6, this will be less expensive. As a result, I suspect there will be more IPv6 small multihomers. That's generally a good thing.

Puzzled: How does the IPv6 routing table get smaller?

Compared to IPv4? Because we don't do slow start, so, major providers won't be advertising 50-5,000 prefixes for a single autonomous system.

There's currently social pressure against deaggregation, but given time why do you think the same drivers that lead to v4 deaggregation won't also lead to v6 deaggregation?

I think that the same drivers will apply, but, think of IPv6 as a Big 10->1 reset button on those drivers. Sure, in 30 years, we may be back to a 300,000 prefix table, but, in 30 years, a 300,000 prefix table will be well within the hardware capabilities instead of on the ragged edge we face today.

(small multihomers means more discontiguous blocks of PI space too, right?)

Yep. It does. However, IPv6 gives us a 30-50,000 prefix table now (when we get there) and 10-30 years to solve either the TCAM scaling issue or come up with a better routing paradigm. I think that eventually an ID/Locator split paradigm will emerge that is deployable. I think that SHIM6 and the others proposed so far are far too complex and end-host dependent to ever be deployable. Likely we will need to modify the packet header to be able to incorporate a locator in the header in the DFZ and do some translation at the edge. I haven't fully figured out the ideal solution, but, I think several others are working on it, too. Owen

On Tue, Mar 23, 2010 at 8:17 AM, William Herrin <bill@herrin.us> wrote:

On Tue, Mar 23, 2010 at 3:40 AM, Owen DeLong <owen@delong.com> wrote:

...

On Mar 22, 2010, at 10:27 PM, Mark Newton wrote:

...

On 23/03/2010, at 3:43 PM, Owen DeLong wrote:

...

With the smaller routing table afforded by IPv6, this will be less expensive. As a result, I suspect there will be more IPv6 small multihomers. That's generally a good thing.

Puzzled:  How does the IPv6 routing table get smaller?

Compared to IPv4?  Because we don't do slow start, so, major providers won't be advertising 50-5,000 prefixes for a single autonomous system.

On the other hand, smaller ASes still announce the same number, the hardware resource consumption for an IPv6 route is at least double that of an IPv4 entry, RIR policy implies more bits for TE disaggregation than is often possible in IPv4 and dual-stack means that the IPv6 routing table is strictly additive to the IPv4 routing table for the foreseeable future. Your thesis has some weaknesses.

Plus the RIRs are currently applying pressure to assign only the bare minimum IPv6 address space to PI multi-homers (at least, the RIR I deal with.) I can see this quickly leading to non-contiguous assignments in the not to distant future. Today I have enough address space to easily allocate /48s per site, assuming a /64 per VLAN. But I can see the need to assign /56s per switch port for dhcp-pd. If I were to assign a /48 per switch stack (seems like a reasonable engineering decision), I'm quickly going to burn through lots of /48s. I'm sure I could come up with clever ways to save address space, but I'm wondering why when one of the promises of IPv6 is to avoid having to think too hard about individual assignments. -- Tim:>

On Tue, Mar 23, 2010 at 10:27 AM, Owen DeLong <owen@delong.com> wrote:

I think that the additive nature of the IPv6/IPv4 routing tables  will be the driving factor for deprecation of IPv4 pretty quickly once IPv6 starts to reach critical mass.  The problem is that we are so early on the IPv6 adoption curve right now that nobody believes IPv6 will become ubiquitous fast enough to be relevant.

it seems to me that we'll have widespread ipv4 for +10 years at least, potentially there will be enough ipv4 alive in 20 years to still consider it 'widespread'. I also think we'll see more v4 routes (longer prefixes) show up in the first 10yrs, before it gets better :( I could be wrong, I hope I am, but...

I think that IPv6 deployment is already showing signs of acceleration. I think that it will lurch forward suddenly shortly after (~6-12 months) IPv4 finally hits the runout wall in a couple of years.

I agree that v6 deployments seem to be getting better/faster/stronger... I think that's good news, but we'll still be paying the v4 piper for a while. -Chris

Owen

On 24/03/2010, at 4:10 AM, Christopher Morrow wrote:

it seems to me that we'll have widespread ipv4 for +10 years at least,

How many 10 year old pieces of kit do you have on your network? Ten years ago we were routing appletalk and IPX. Still doing that now? Ten years ago companies were still selling ISDN routers which still insisted on classful addressing. Got any of them left on the network? I'd expect that v4 will still exist in legacy form behind firewalls, but I think its deprecation on the public internet will happen a lot faster than anyone expects.

I agree that v6 deployments seem to be getting better/faster/stronger... I think that's good news, but we'll still be paying the v4 piper for a while.

Only until v4 becomes more expensive (using whatever metric matters to you) than v6. After you pass that tipping point, v4 deployment will stop dead. - mark -- Mark Newton Email: newton@internode.com.au (W) Network Engineer Email: newton@atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223

On 24/03/2010, at 1:46 PM, <bmanning@vacation.karoshi.com> wrote:

tell me Mark,

when will you turn off -all- IPv4 in your network?

I don't imagine there'll be a date as such; We'll just enable IPv6 versions of the services you've mentioned on equipment which supports it, and note that over time the number of systems still using v6 to perform those functions diminishes.

simple switching of datagrams over non-v4 transport is trivial. th O&M behnd running production is a slightly longer path and the legal requirements these days didn't exisit a decade ago. Chris was optimistic at 10+ years.

There seems to be an assumption that continuing to run v4 on a v6 internet will be free, or at least cheap. I don't think it will be. I think it'll rapidly become horrendously expensive in operational support terms, and that we'll all see significant pressure from our CFOs and CTOs to get rid of it well before the ten-year estimate expires. ... and if we don't, our customers will. - mark -- Mark Newton Email: newton@internode.com.au (W) Network Engineer Email: newton@atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223

       when will you turn off -all- IPv4 in your network?        no snmp/aaa, no syslog, no radius, no licensed s/w keyed to a v4 address,        no need to keep logs for leos' (whats the data retention law in your jurisdiction?)        etc...

The same day that we stop using RS-232C point-to-point protocol devices. The day that IPv4 is turned off, is not an interesting date. What *IS* interesting is when IPv4 disappears into the woodwork and is only used inside boxes and on internal management networks. For comparison look at the z-80 CPU which powered the early desktop computers. When the IBM PC came out, people thought that the Intel 8086 would make the Z-80 obsolete. But it didn't. The Z-80 just disappeared into all sorts of electronic devices where it serves as a controller for some function, perhaps the video display or the disk drive servos. And you can still buy them. Here is a development kit in case you want to use Z-80s in new devices: <http://www.zilog.com/docs/ez80/devtools/fl0023.pdf> The same thing will happen to IPv4. In a hundred years some engineer will be surprised to discover that IPv4 is running inside residential HVAC systems, carrying messages from thermostats and temperature sensors to the heating system, the air conditioners, and the ground heat exchangers. But within 10 years, IPv4 will no longer be doing the heavy-lifting in carrying packets across the public Internet, and that is what counts for most of us. --Michael Dillon P.S. If you are in the market for a buggy whip, here is a list of manufacturers/sellers as well as some advice on choosing the whip. <http://home.comcast.net/~a-mcnibble/Links/Link1.HTML>

On Mar 26, 2010, at 8:45 AM, Lamar Owen wrote:

On Wednesday 24 March 2010 05:24:39 pm Michael Dillon wrote:

...

For comparison look at the z-80 CPU which powered the early desktop computers. When the IBM PC came out, people thought that the Intel 8086 would make the Z-80 obsolete. But it didn't. The Z-80 just disappeared into all sorts of electronic devices where it serves as a controller for some function, perhaps the video display or the disk drive servos. And you can still buy them.

Lots of DVD drives use embedded Z80's as controllers, including the dual-layer drive in my laptop. Never thought that my teenage years spent hacking Z80 machine code on a TRS-80 could produce a currently marketable skill....

Quick, Z80 joke coming.... Addr: 0000:21 00 00 01 FF FF 11 01 00 ED B0.......Will it finish?

Same is true of MIPS and PowerPC, though. There are far more MIPS chips in routers than ever saw desktop use in SGI workstations; and while it might take a little while for Cisco's PowerPC driven routers' CPU's to outnumber all the PowerMacs our there, one day it will happen.

And then all those PowerMac assembly language gurus might prove useful in the router side of the house.....

The Juniper SRX-100 appears to have a MIPS or MIPS-like chip in it called an Octeon. Owen

Same is true of MIPS and PowerPC, though.  There are far more MIPS chips in routers than ever saw desktop use in SGI workstations; and while it might take a little while for Cisco's PowerPC driven routers' CPU's to outnumber all the PowerMacs our there, one day it will happen.

MIPS are now used as a core in many microcontrollers as an alternative to ARM. I do development using Microchip's PIC32MX which is based on a 32-bits MIPS M4K core, beautiful piece of silicon and very good performance. I have a small collection of old gear, somewhere I've a couple of the old Sinclair Spectrum Z-80 with 16KB RAM !!, amazing that one used to program those things with 4K and some kids today don't know how to get started if they don't have a couple of GB's in APIs. Cheers Jorge

On Tue, Mar 23, 2010 at 7:59 PM, Mark Newton <newton@internode.com.au> wrote:

On 24/03/2010, at 4:10 AM, Christopher Morrow wrote:

...

it seems to me that we'll have widespread ipv4 for +10 years at least,

How many 10 year old pieces of kit do you have on your network?

it's not my network anymore (or not the one I work on anymore) but... 702 had +400 7500's of 1996 vintage when I left, 703 had somewhere near 200 or so of similar vintage 7500's and 7200's... Sprint still does T1 agg on 7500's. ATT I'm sure has 75's in the network as well. If there's low margin and no 'cost' to run the gear, why would I upgrade??

Ten years ago we were routing appletalk and IPX.  Still doing that now?

apples and oranges.

I'd expect that v4 will still exist in legacy form behind firewalls, but I think its deprecation on the public internet will happen a lot faster than anyone expects.

maybe you're right, but... I doubt it.

...

I agree that v6 deployments seem to be getting better/faster/stronger... I think that's good news, but we'll still be paying the v4 piper for a while.

Only until v4 becomes more expensive (using whatever metric matters to you) than v6.

I have v4, it's not going to be anymore expensive than it is today for me... for new folks sure, but I've got mine.

After you pass that tipping point, v4 deployment will stop dead.

doubtful. we could go back and forth with this pingpong ball for ... ever, but the point here is no one knows, it's likely different than either of us think, and in the mean time fun will ensue! -chris

 - mark

-- Mark Newton                               Email:  newton@internode.com.au (W) Network Engineer                          Email:  newton@atdot.dotat.org  (H) Internode Pty Ltd                         Desk:   +61-8-82282999 "Network Man" - Anagram of "Mark Newton"  Mobile: +61-416-202-223

On Wed, Mar 24, 2010 at 12:35:38AM -0700, Owen DeLong wrote:

...

...

Only until v4 becomes more expensive (using whatever metric matters to you) than v6.

I have v4, it's not going to be anymore expensive than it is today for me... for new folks sure, but I've got mine.

If you start deploying IPv6, then, the cost of maintaining duplicate security policies (v4 and v6), duplicate host mappings, duplicate DNS, duplicate configurations on all your routers, etc. does eventually add up, as does the need for even more TCAM.

bingo. to move -from- a single stack system (IPv4) to a dual stack system (v4 & v6) is horrifically expensive. and to justify it based on the eventual cost savings of returning to a single-stack system "someday" might be problematic. one will pay those costs -if- there is an acceptable cost/benefit tradeoff.

These costs may be trivial in small environments, but, for major enterprises and large backbones, these costs will become significant.

An additional not-yet recognized cost of IPv4 will come to light as the various transfer policies start super-fragmenting the address space and our TCAMs begin exploding with new IPv4 routes. Likely there will be scenarios where ISPs need a /16 but they can only find 240 non-aggregable /24s. They'll snap them up and bam... 240 new IPv4 routes.

i will note in passing that an ipv6 /32 is the functional equivalent of an ipv4 /32... with the community accepting /48's, we will exceed the potential route injection capability of ipv4. we will potentially have more ipv6 routes than we could have ipv4... simply because we can't get any finer grained in IPv4 than a /32... while we can in IPv6.

The ARIN transfer policies has some safeguards against this, but, most of the RIRs passed transfer policies without these safeguards.

last I checked ARIN transfer policies didn't really talk to routing deaggregation much. in part because ARIN has (to date) almost no leverage on who announces what.

Owen

On 3/23/2010 10:59 PM, Mark Newton wrote:

On 24/03/2010, at 4:10 AM, Christopher Morrow wrote:

...

it seems to me that we'll have widespread ipv4 for +10 years at least,

How many 10 year old pieces of kit do you have on your network?

Are you kidding? I'm in state education these days. I probably still have one or two 2500 series routers hiding in my network.

Ten years ago we were routing appletalk and IPX. Still doing that now?

Ten years ago we were routing ipv4, which was going to die of address exhaustion and/or be replaced by ipv6 within two years. Fifteen years ago we were running ipv4, which was going to die of address exhaustion and/or be replaced by OSI within two years. I remember a (telco) engineer, after a presentation on MPLS in the late 90s, saying that it was all very interesting, but all this IP stuff was a fad, and everything was going to be ATM in the near future.

I'd expect that v4 will still exist in legacy form behind firewalls, but I think its deprecation on the public internet will happen a lot faster than anyone expects.

You may be right; past experience is not always correct in predicting future behavior. But there has to be a reason why it will be different this time.

...

I agree that v6 deployments seem to be getting better/faster/stronger... I think that's good news, but we'll still be paying the v4 piper for a while.

Only until v4 becomes more expensive (using whatever metric matters to you) than v6.

After you pass that tipping point, v4 deployment will stop dead.

Sure. But the key phrase is "whatever metric matters to you." You're going to find people whose "expense" metrics are neither dollars nor sense. 1) For some people, that might mean what you think it means: "Hey, to deploy ipv4, we have to pay for this expensive translator box. Lets do v6." 2) On the other hand, there'll be "Hey, we already bought the translator box, because we had an emergency and had to deploy it. So let's stick to v4, because it is what we know." 3) In a lot of places, there will be "Everything I want is v4. v6 is the expensive option, because it means deploying new router software and/or configurations." 4) For others, it will be "I know v4, and not v6. My management knows nothing, and buys what I tell them." 5) Because of groups 2-4, there will be plenty of "Everybody else is still doing v4, and so v4 is what I need to reach them." 6) And finally, there will be a lot of "I need to talk to people in groups 2-5, so I need to deploy v4 regardless." Remember, a new protocol is a lot harder to sell than a new hack that makes the old protocol live longer. And all the protestations of "It can't keep going on like this" ignores history again. Just because we don't *want* NAT to be "fixed" to support more people doesn't make it un"fix"able. If you want v6 deployed, you cannot expect to sit around and wait for everybody to admit you're right; you must make deploying v6 easier/cheaper/less painful than pumping life into v4. -Dave

On Mar 24, 2010, at 10:14 PM, Bill Stewart wrote:

...

...

it seems to me that we'll have widespread ipv4 for +10 years at least, How many 10 year old pieces of kit do you have on your network? Ten years ago we were routing appletalk and IPX. Still doing that now?

Ten years ago I was still telling a few customers that Novell Netware had supported TCP/IP since the early 90s and it was really time to shut off IPX, and the Appletalk users were at least running over IP, not LocalTalk, so I didn't have to care much, and the Windows people were probably already arguing about Active Directory and LDAP and whether to do DNS, DLSW was Not Dead Yet, and 1/3 of my X.25 customers acknowledged that it was way obsolete and time to join the 1990s (the other two were state governments who viewed it as Somebody Else's Emulation Problem.)

The last time I was dealing with high-end Layer 1 access problems was a couple of years ago, but in addition to normal IPv4 and MPLS, I had customers running Fiber Channel and other SAN protocols on the WAN.

There'll be enough IPv4 to keep antiques dealers in business for a while yet.

As of (at least) 2002, the FBI was still using bisync for communications. If you're a data communications professional and haven't heard of bisync, that proves my point... I suspect that some members of this list weren't born by the time it was considered obsolete. --Steve Bellovin, http://www.cs.columbia.edu/~smb

On Mar 23, 2010, at 10:27 AM, Owen DeLong wrote:

With 30,000 active AS right now, assuming an average of 2 instead of 9.5,

You appear to be assuming ISPs (like the ones that have received /18s, /19s, /20s, etc.) aren't going to deaggregate for traffic engineering purposes. Or do I misunderstand? Regards, -drc

On 19/03/2010, at 4:07 AM, Stan Barber wrote:

1. Almost all home users (not businesses) that are connected to the Internet today via IPv4 are behind some kind of NAT box. In some cases, two NATs (one provided by the home user's router and one provided by some kind of ISP). There is no need for this using IPv6 to communicate with other IPv6 sites.

There are a large number of users, here in NZ at least, but I imagine in other places, that have a single ethernet port "ADSL Modem" which terminates PPP, does IPv4 NAT, DHCP, etc. and then a "Wireless Router" which has its ethernet "Internet" plug connected to the "ADSL Modem", and does IPv4 NAT, DHCP to end hosts, etc. This means that they have double NAT inside the home, and then in the future a potential third NAT. We did some looking at packets, and 17% of outbound packets from customers at an ISP had TTLs that indicated two L3 hops in the home - which for the majority of cases would mean double NAT. In NZ the most popular ADSL deployment is PPPoATM, so the ADSL unit the ISP ships (either loaned, or included in the install cost) is an IPv4 router terminating a PPPoATM connection, not a bridge or anything. -- Nathan Ward

On Fri, Mar 5, 2010 at 7:22 AM, Andy Davidson <andy@nosignal.org> wrote:

On 04/03/2010 19:30, William Herrin wrote:

...

On Thu, Mar 4, 2010 at 2:12 PM, Joel Jaeggli <joelja@bogus.com> wrote:

...

handling the v6 table is not currently hard (~2600 prefixes) while long term the temptation to do TE is roughly that same in v6 as in v4, the prospect of having a bunch of non-aggregatable direct assignments should be much lower... Because we expect far fewer end users to multihome tomorrow than do today?

The opposite, but a clean slate means multihomed networks with many v4 prefixes may be able to be a multihomed network with just one v6 prefix.

Assuming RIR policy allows multi-homers to be allocated/assigned enough v6 to grow appreciably without having to go back to the RIR. As a multi-homed end-user, I don't currently find that to be the case. -- Tim:>

Once upon a time, Jeff McAdams <jeffm@iglou.com> said:

Both my previous and current employer, in switching from IPv4 to IPv6 will drop from 7 and 4 advertisements (fully aggregated) to 1. I don't anticipate either ever having needs larger than the single initial allocation they have or would get. Both are multi-homed.

That brings a question to mind. As an ISP, with IPv4, end sites that are multihoming can justify a /24 from us (or another upstream) and announce it through multiple providers. With IPv6, are they supposed to get their block from ARIN directly if they are multihoming? In other words, should I _never_ allow customers to announce smaller blocks of my IPv6 ARIN block? -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.

On Mar 6, 2010, at 1:37 AM, Thomas Magill wrote:

...

That brings a question to mind. As an ISP, with IPv4, end sites that are multihoming can justify a /24 from us (or another upstream) and announce it through multiple providers. With IPv6, are they supposed to get their block from ARIN directly if they are multihoming? In other words, should I _never_ allow customers to announce smaller blocks of my IPv6 ARIN block?

According to ARIN, you must meet their IPv4 requirements for an ARIN block to get an IPv6 ARIN block. That leads me to believe that the same customers who need v4 space from you would also need v6 space from you.

Um, not exactly. According to ARIN, _IF_ you meet their requirements for obtaining an IPv4 block, then, you ALSO automatically meet their requirements for obtaining an IPv6 block. There are ALSO other ways to qualify for an IPv6 block, completely independent of the qualification for or possession of an IPv4 block. As to the question about what you should or should not allow your customers to announce, that is up to you. However, there is a specific block being used to issue ARIN end-user assignments, and, many ISPs filter that more liberally (/48) than they filter blocks used for allocation (/32). As such, your customers who are multihomed _MAY_ have a better chance of having their prefix seen if they use an ARIN direct assignment. However, there is at least 1 provider (hello, AS701) that blocks nearly all prefixes longer than /32 in IPv6, so, customers that are multihomed and announcing a more specific from your space would appear as if they are single-homed to Verizon customers, while they would be invisible to Verizon customers if they use ARIN space. There may be other providers with similar filtration policies. Hurricane Electric will accept routes either way. I cannot speak in detail about the conduct of other providers, as I do not know their policies. Owen

On Mar 6, 2010, at 2:06 AM, Thomas Magill wrote:

...

According to ARIN, _IF_ you meet their requirements for obtaining an IPv4 block, then, you ALSO automatically meet their requirements for obtaining an IPv6 block.

Thank you for the clarification. I am obviously in the very early stage of planning IPv6 for our company with hopes of at least having peers up this summer after our peak holiday season (mothers day). I would prefer to get an ARIN block so that we feel less locked down to a provider by using their space.

Seems reasonable. That's precisely why I created the original and co-authored the final version of the first Provider Independent End-User IPv6 policy.

...

However, there is a specific block being used to issue ARIN end-user assignments, and, many ISPs filter that more liberally (/48) than they filter blocks used for allocation (/32). As such, your customers who are multihomed _MAY_ have a better chance of having their prefix seen if they use an ARIN direct assignment.

So what seems to be the standard for the longest advertised prefix for v6 (compared to /24 for v4)? If I get a /48 from ARIN how many non-aggregated prefixes should I expect to have? This sounds like you are saying /48 is as specific at it would get.

Uh, 1. If you need multiple discreet networks, you should probably get a /48 for each of them from ARIN. Owen