No, this is how the RIR process works. The RIRs request their next /8s and begin the "cleaning" process on them several months prior to running out of their previous allocations. This is done to try and make the allocations/assignments from those blocks as immediately useful as possible to their customers. I can assure you that RIRs are in the business of distributing IP resources within the policy guidelines set by the community. They have no gain from holding or hoarding them and are not in a position to do any such thing. Owen On Apr 2, 2010, at 3:48 PM, John Palmer (NANOG Acct) wrote:

On the topic of IP4 exhaustion: 1/8, 2/8 and 5/8 have all been assigned in the last 3 months yet I don't see them being allocated out to customers (users) yet.

Is this perhaps a bit of hoarding in advance of the complete depletion of /8's?

----- Original Message ----- From: "Majdi S. Abbas" <msa@latt.net> To: "Jeroen van Aart" <jeroen@mompl.net> Cc: "NANOG list" <nanog@nanog.org> Sent: Friday, April 02, 2010 4:06 PM Subject: Re: legacy /8

...

...

I am curious. Once we're nearing exhausting all IPv4 space will there ever come a time to ask/demand/force returning all these legacy /8 allocations? I think I understand the difficulty in that, but then running out of IPs is also a difficult issue. :-) For some reason I sooner see all IPv4 space being exhausted than IPv6 being actually implemented globally. Because it's no more than a delaying action. Even presuming you get people to cooperate (and they really, have no incentive to because they don't necessarily have any agreement covering the space with the RIRs) rather than fire up their legal department.... A couple of /8s doesn't last long enough to really make a dent in the pain. You might buy yourself a few months at most. It might actually do more harm than good, by convincing people

On Fri, Apr 02, 2010 at 02:01:45PM -0700, Jeroen van Aart wrote: that they can still get v4 space rather than worry about what they are going to do in the future. --msa

----- Original Message ----- From: "Majdi S. Abbas" <msa@latt.net> To: "John Palmer (NANOG Acct)" <nanog2@adns.net> Cc: "NANOG list" <nanog@nanog.org> Sent: Friday, April 02, 2010 5:52 PM Subject: Re: legacy /8

On Fri, Apr 02, 2010 at 05:48:44PM -0500, John Palmer (NANOG Acct) wrote:

...

On the topic of IP4 exhaustion: 1/8, 2/8 and 5/8 have all been assigned in the last 3 months yet I don't see them being allocated out to customers (users) yet.

Is this perhaps a bit of hoarding in advance of the complete depletion of /8's?

Doubt it. 1/8 is still being evaluated to determine just how usable portions of it are, thanks to silly people of the world that decided 1.1.1.x and the like were 1918 space.

As for the others, the RIR requests it when they are running low, but certainly not exhausted, and as slow as people are to update their bogon filters, it sounds like general good practice not to assign out of a new /8 until pre-existing resources are exhausted.

Was looking for the "allocated" file on the ARIN website, but can't remember where it is. They used to have a file with one line per allocation that started like this "arin|US|ipv4". Is that still public somewhere?

Can we put the tinfoil hats away and let this thread die now?

--msa

Good luck with that one :->

On 2010.04.05 09:20, Steve Bertrand wrote:

On 2010.04.02 19:29, John Palmer (NANOG Acct) wrote:

...

Was looking for the "allocated" file on the ARIN website, but can't remember where it is. They used to have a file with one line per allocation that started like this "arin|US|ipv4". Is that still public somewhere?

If you are looking for what blocks have been allocated to ARIN by IANA, the file is maintained on the IANA site:

http://www.iana.org/assignments/ipv4-address-space/

After digging a little bit more, and to further my own post, ARIN does maintain a list within its website that contains its IANA allocated blocks for both IPv4 and IPv6: https://www.arin.net/knowledge/ip_blocks.html After a quick review, it seems as though there are numerous blocks left out of this list when comparing it to the aforementioned IANA list. Perhaps it is due to certain blocks being legacy (?). If ARIN does have a single text file, I haven't found it. Should be trivial to copy/dump though. Steve

Must resist urge to bash v6... must start weekend... must turn off computer for my own good..... On Fri, Apr 2, 2010 at 6:08 PM, Charles N Wyble <charles@knownelement.com> wrote:

Hmmm... it is 2pm on a Friday afternoon. I guess it's the appropriate time for this thread.

*grabs popcorn and sits back to watch the fun*

On Friday 02 April 2010 06:14:33 pm Owen DeLong wrote:

This is where Legacy vs. RIR becomes meaningful. Legacy holders have no contractual obligation to return unused space. RIR recipients, on the other hand, do.

Some legacy holders might, I imagine, be 'squatting' on that legacy space and are getting ready to 'sell' some to the highest bidder, generating who knows how much revenue, if their agreement allows them to do so. A few of those same legacy holders might even want to impede IPv6 uptake to make their /8 more valuable when the crunch comes. Perhaps I'm too paranoid. But I'm sure I'm not the first person to think of these possibilities (in my case, however, I have no legacy space, and wouldn't go that route even if I did).

Cutler James R wrote:

I also just got a fresh box of popcorn. I will sit by and wait

I honestly am not trying to be a troll. It's just everytime I glance over the IANA IPv4 Address Space Registry I feel rather annoyed about all those /8s that were assigned back in the day without apparently realising we might run out. It was explained to me that many companies with /8s use it for their internal network and migrating to 10/8 instead is a major pain.

Running out of IP addresses is not a soon realized scenario for IPv6. If an organization runs out of IP addresses, the difficulty is with top management, not the network or address space.

I also don't try to bash IPv6, I don't know enough about it yet to do that and I doubt I would. From a casual observer's point of view having that much more IP space to allocate can only be a good thing. But from the same observer's POV you can also reason it is taking very long to gain acceptance. Regards, Jeroen

On Apr 2, 2010, at 3:38 PM, Andrew Gray wrote:

Jeroen van Aart writes:

...

Cutler James R wrote:

...

I also just got a fresh box of popcorn. I will sit by and wait I honestly am not trying to be a troll. It's just everytime I glance over the IANA IPv4 Address Space Registry I feel rather annoyed about all those /8s that were assigned back in the day without apparently realising we might run out. It was explained to me that many companies with /8s use it for their internal network and migrating to 10/8 instead is a major pain.

You know, I've felt the same irritation before, but one thing I am wondering and perhaps some folks around here have been around long enough to know - what was the original thinking behind doing those /8s?

The original thinking was based on an environment where the Internet was expected to consist only of a few corporate entities providing services and products to research institutions and the government. There was no WWW, no browsers, and Windows couldn't even spell TCP/IP at the time. The expectation was that those /8s would be subnetted into vast arrays of "Class C" sized chunks and that subnets within a given /8 all had to be the same size (this used to be necessary to keep RIP happy and every machine participating in RIP routing had to have an /etc/netmasks (or equivalent) table that tracked "THE" subnet mask for each natural prefix). Sure, a /8 is a lot of addresses in today's world. However, back then, it was much like a /48 today. Just a way to give someone 65,500+ subnets (for any given X/8, then X.0/16, X.255/16, X.Y.0/24, X.Y.255/24 were unusable in these days).

I understand that they were A classes and assigned to large companies, etc. but was it just not believed there would be more than 126(-ish) of these entities at the time? Or was it thought we would move on to larger address space before we did? Or was it that things were just more free-flowing back in the day? Why were A classes even created? RFC 791 at least doesn't seem to provide much insight as to the 'whys'. - Andrew

It was thought that we would not have nearly so many people connected to the internet. It was expected that most things connecting to the internet would be minicomputers and mainframes. Owen

The last time I discussed IP Address needs with a company the builds automobiles, they wanted forty million addresses for robots, sensors, and the like for manufacturing. A single /8, were it available, would only yield about 20% of that requirement. On Apr 2, 2010, at 6:46 PM, Owen DeLong wrote:

Sure, a /8 is a lot of addresses in today's world.

James R. Cutler james.cutler@consultant.com

On 4/3/2010 01:03, Jeroen van Aart wrote:

Owen DeLong wrote:

...

It was thought that we would not have nearly so many people connected to the internet. It was expected that most things connecting to the internet would be minicomputers and mainframes.

It took some visionary and creative thinking to "come up" with the internet. But given such a train of thought the idea of everyone being connected isn't such a wild idea. I can imagine it'd be almost a given.

Although if I get the time frame right in those days you had 2 camps, those (ibm, dec...) who believed that there was no need for home computers and you only needed a few (hundred?) thousand big mainframes and minicomputers and those (commodore, apple...) who believed (rightfully so) there was going to be a big future and demand for home computers.

So I guess depending on what "camp" you were in, it's not that strange to not envision all these household computers being interconnected.

Hindsight is always 20/20. But remember that the internet started as a DoD project with just the military, mil contractors, universities, etc, connected to it. At first it wasn't even envisioned as something the general public would even use. And back in those times having a computer at home was still a fairly unusual thing. Only "geeks" had them (I remember kids poking fun at me back in middle school when they found out I had a home computer). Back then, during the "computer revolution", you used a modem to connect to BBSes, services like Compu$serve, and perhaps the UUCP network for email and usenet. The internet was something only big orgs, corps, universities, and the military had. So it's not *too* surprising that the "explosion" that happened after the web browser/server came into being was a bit of a surprise for people. And it wasn't all that long after the explosion that I started hearing about things like "IP-NG", etc (for a while I thought IPv6 would use OSI NSAPs hehe). So they got busy addressing the problem pretty quickly, despite having not predicted such a big explosion in internet use. Of course my memory could be a bit foggy, but there are guys on this list who were on the leading edge of all this who could (and probably have) tell the whole story in more detail. :) -Jim

On Sat, 03 Apr 2010 08:06:44 EDT, Jeffrey Lyon said:

For small companies the cost of moving to IPv6 is far too great, especially when we rely on certain DDoS mitigation gear that does not yet have an IPv6 equivalent.

So? How many people are *realistically* being hit by IPv6 DDoS right now? (I saw a number in the last 2-3 days that 2-3% of spam is now being delivered via SMTP-over-IPv6). You may not need that gear as much as you thought... Did you tell your mitigation gear vendor 5 years ago that their next model needed to have IPv6 support? Given that currently most stuff is dual-stack, and IPv6 isn't totally widespread, what are the effects of doing IPv6 DDoS mitigation by simply turning off IPv6 on your upstream link and letting traffic fall back to IPv4 where you have mitigation gear?

In article <4BB897A7.60503@consolejunkie.net>, Leen Besselink <leen@consolejunkie.net> writes

...

(I saw a number in the last 2-3 days that 2-3% of spam is now being delivered via SMTP-over-IPv6). You may not need that gear as much as you thought...

This maybe ?: http://labs.ripe.net/content/spam-over-ipv6

"Out of the total number of emails received, 14% were received over IPv6, the rest over IPv4."

RIPE NCC has been running ipv6 mail for some time, so this may be higher than average.

"Looking only at the number of e-mails received over IPv6, 3.5% were classified as spam, the rest were legitimate."

But then again this is a pretty low number as well:

"Looking only at the number of emails received over IPv4: 31% were classified as spam, the rest were legitimate."

Some of us deal with 98% or more.

Don't forget it also said: "this excludes messages already rejected by blacklisting and greylisting ... and sent to non-existent email addresses within the ripe.net domain" and: "Additionally, our statistics only take our primary MX system into account (and not email sent from the secondary MX system to the primary)." -- Roland Perry

On 4/3/2010 1:39 PM, Valdis.Kletnieks@vt.edu wrote:

On Sat, 03 Apr 2010 08:06:44 EDT, Jeffrey Lyon said:

...

For small companies the cost of moving to IPv6 is far too great, especially when we rely on certain DDoS mitigation gear that does not yet have an IPv6 equivalent.

So? How many people are *realistically* being hit by IPv6 DDoS right now? (I saw a number in the last 2-3 days that 2-3% of spam is now being delivered via SMTP-over-IPv6). You may not need that gear as much as you thought...

Did you tell your mitigation gear vendor 5 years ago that their next model needed to have IPv6 support?

Given that currently most stuff is dual-stack, and IPv6 isn't totally widespread, what are the effects of doing IPv6 DDoS mitigation by simply turning off IPv6 on your upstream link and letting traffic fall back to IPv4 where you have mitigation gear?

Not a valid argument. When ipv6 gets widely used then the DDOS will follow it. I have to agree with the previous poster about not wanting to move until his DDOS mitigation gear supports V6. Many of the security products i use are just now starting to go v6 capable. I would not want to move to V6 even if i could until all of my security gear/software is properly V6 tested.

On Apr 12, 2010, at 12:39 AM, <Valdis.Kletnieks@vt.edu> <Valdis.Kletnieks@vt.edu> wrote:

IPv6 isn't heavily used *currently*, so it may be perfectly acceptable to deal with the mythological IPv6 DDoS

The only IPv6-related DDoS attacks of which I'm aware to date is miscreants going after 6-to-4 gateways in order to disrupt one another's IPv6-tunneled botnet C&C traffic. However, as soon as there are moneymaking opportunities to be had and/or ideological vendettas to be pursued by launching pure IPv6-based DDoS attacks, we can all rest assured they won't let the side down. ;> ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken

In article <207E4E4F-B642-424E-8649-810A589DA54B@delong.com>, Owen DeLong <owen@delong.com> writes

I believe the IPv4 classful addressing scheme (which some have pointed out was the second IPv4 addressing scheme, I wasn't involved early enough for the first, so didn't remember it) predates commodore, apple, etc.

On a historical note, if Classful Addressing is deemed to date from rfc792 (1981) [but I'd be grateful for other nominations of a suitable alternate date] then that post-dates the Commodore PET and Apple II which were both launched in 1977. Some sources claim the PET is later, but I remember it because I was doing a project on "PCs in Schools" in the spring of 1977, using an 8-bit PC that I had built myself on a patchboard. And the PET arrived just in time for me to be able say to "I'm not completely insane - a viable PC you could install in a school is now commercially available". -- Roland Perry

In article <201004041249.o34CnUUt078737@aurora.sol.net>, Joe Greco <jgreco@ns.sol.net> writes

...

Some sources claim the PET is later, but I remember it because I was doing a project on "PCs in Schools" in the spring of 1977, using an 8-bit PC that I had built myself on a patchboard. And the PET arrived just in time for me to be able say to "I'm not completely insane - a viable PC you could install in a school is now commercially available".

Your memory seems to be in error; the PET was created for the June 1977 CES, and wasn't shipped to customers until at least later that year. It seems very likely that you received your PET in the spring of 1978.

I use the expressions "arrived" and "available" in the spirit of vapourware that was endemic in the industry at the time. In other words, it was when the product was "introduced". It's true that we would not have expected to see a real one in the UK until much later. There are at least two sources which date the PET to "Winter CES" and "Jan 1977", but I agree that June CES is where production items would be first shown; however by then schools were out and my project was finished (I was studying to be maths teacher). -- Roland Perry

Jeroen van Aart <jeroen@mompl.net> writes:

...

That was at the West Coast Computer Faire in mid-April of 1977, organised by Jim Warren of Dr. Dobbs Journal. The first major gather of hobbyists and microcomputer companies. Apparently an important moment in the microcomputer history.

seems like i saw an Apple I at that show, and also a SOL, which i remember thinking very highly of since it had an S-100 bus. the PET was there but with the itty bitty keyboard the machine was a bit of a head-scratcher for the crowd. -- Paul Vixie KI6YSY

Lamar Owen wrote:

and construction of the prototype. It was announced to the public on August 3, 1977, and sold a quarter of a million units over its lifetime (talking about the 'Model I' only). IOW, the TRS-80 was already in design before the PET was shown to John Roach; that's the minor correction.

Right, I believe the book was trying to say that the missed opportunity is that Commodore could have sold the original PET in Tandy's stores. I assume you were (as I was) wondering why the hell Tandy would have done that as it've been a competitor to the TRS-80. But then Commodore (having taken over MOS technologies) sold CPUs to their major competitors including Apple and Atari. So it's not unheard of. Regards, Jeroen

You know, I've felt the same irritation before, but one thing I am wondering and perhaps some folks around here have been around long enough to know - what was the original thinking behind doing those /8s?

Read your network history. In the beginning all allocations were /8s, in fact the slash notation hadn't been invented yet. Network numbers were 8 bits and there was a 24 bit host id appended. Then someone realised that the net was growing really fast, so they invented class A, B and C addresses in which the network numbers were 8, 16 or 24 bits respectively. You could tell which class by looking at the first two bits of the address. In that time period only very big organizations got class A allocations. Mid-sized ones got class B and small ones got class C. In fact what happened was that some smaller organizations got multiple non-aggregatable class C blocks (and aggregation didn't exist anyway). Later on some clever folks invented VLSM for the routers which allowed network ops folks to invent CIDR. That was when people really got interested in justifying the size of an allocation, and working based on 3 months, or 6 months requirements. This is when ARIN was created so that the community had some input into how things were done. But nobody could really unroll the past, just clean up the bits where people were changing things around anyway. For instance this is how Stanford's /8 ended up being returned. Lots of folks believed that VLSM and CIDR were only stopgap measures so around the same time they invented IPv6. It was released into network operations around 10 years ago which is why most of your network equipment and servers already support it. But that's all water under the bridge. It's too late to do anything about IPv4. The ROI just isn't there any more, and it doesn't escape the need to invest in IPv6. The network industry has now reached consensus that IPv6 is the way forward, and you have to catch the wave, or you will drown in the undertow. --Michael Dillon

On Fri, 02 Apr 2010 15:38:26 -0700 Andrew Gray <3356@blargh.com> wrote:

Jeroen van Aart writes:

...

Cutler James R wrote:

...

I also just got a fresh box of popcorn. I will sit by and wait

I honestly am not trying to be a troll. It's just everytime I glance over the IANA IPv4 Address Space Registry I feel rather annoyed about all those /8s that were assigned back in the day without apparently realising we might run out.

It was explained to me that many companies with /8s use it for their internal network and migrating to 10/8 instead is a major pain.

You know, I've felt the same irritation before, but one thing I am wondering and perhaps some folks around here have been around long enough to know - what was the original thinking behind doing those /8s?

I understand that they were A classes and assigned to large companies, etc. but was it just not believed there would be more than 126(-ish) of these entities at the time? Or was it thought we would move on to larger address space before we did? Or was it that things were just more free-flowing back in the day? Why were A classes even created? RFC 791 at least doesn't seem to provide much insight as to the 'whys'.

That's because RFC791 is a long way from the original design assumptions of the Internet Protocols. "A Protocol for Packet Network Intercommunication", Vinton G. Cerf and Robert E. Kahn, 1974, says - "The choice for network identification (8 bits) allows up to 256 distinct networks. This size seems sufficient for the foreseeable future." That view seems to have persisted up until at least RFC761, January 1980, which still specified the single 8 bit network, 24 bit node address format. RFC791, September 1981, introduces classes. So somewhere within that period it was recognised that 256 networks wasn't going to be enough. I'm not sure why the 32 bit address size was persisted with at that point - maybe it was because there would be significant performance loss in handling addresses greater than what was probably the most common host word size at the time. If you start looking into the history of IPv4 addressing, and arguably why it is so hard to understand and teach compared to other protocols such as Novell's IPX, Appletalk etc., everything that has been added to allow increasing the use of IP (classes, subnets, classless) while avoiding increasing the address size past 32 bits is a series of very neat hacks. IPv4 is a 1970s protocol that has had to cope with dramatic and unforeseen success. It's not a state of the art protocol any more, and shouldn't be used as an example of how things should be done today (As a minimum, I think later protocols like Novell's IPX and Appletalk are far better candidates). It is, however, a testament to how successfully something can be hacked over time to continue to work far, far beyond it's original design parameters and assumptions. (IMO, if you want to understand the design philosophies of IPv6 you're better off studying IPX and Appletalk than using your IPv4 knowledge. I think IPv6 is a much closer relative to those protocols than it is to IPv4. For example, router anycast addresses was implemented and used in Appletalk.) Possibly Vint Cerf might be willing to clear up some of these questions about the origins of IPv4 addressing. Regards, Mark.

Cutler James R wrote:

...

I also just got a fresh box of popcorn. I will sit by and wait

I honestly am not trying to be a troll. It's just everytime I glance over the IANA IPv4 Address Space Registry I feel rather annoyed about all those /8s that were assigned back in the day without apparently realising we might run out. Yes. We should all jump up and down and complain about the early adopters who were present at the time and helped develop (and fund the development of) the Internet into something that pays most of our

Jeroen van Aart wrote: paychecks today. Or not. And of course some of the folks who got /8s early on have turned them back. Others have merged into entities who use a whole lot of the space. Matthew Kaufman

On Fri, Apr 02, 2010 at 03:25:22PM -0700, Jeroen van Aart wrote:

Cutler James R wrote:

...

I also just got a fresh box of popcorn. I will sit by and wait

I honestly am not trying to be a troll. It's just everytime I glance over the IANA IPv4 Address Space Registry I feel rather annoyed about all those /8s that were assigned back in the day without apparently realising we might run out.

its well to remember that when they got that space, the minimum allocation was a /8. you couldn't get anything smaller because "classful" addressing wasn;t invented yet. Only (much) later could you get "B" or "C" space... and after classful died in v4, we had CIDR. IPv6 as effectively reindroduced classful addressing.

Regards, Jeroen

--bill

On Sat, Apr 03, 2010 at 09:25:08AM +0900, Randy Bush wrote:

...

IPv6 as effectively reindroduced classful addressing.

but it's not gonna be a problem this time, right? after all, 32^h^h128^h^h^h64 bits is more than we will ever need, right?

randy

well... looking at a diet analogy, when .gt. 50% of your diet is HFCS and filler, its not real healthy. the way most folks are using IPv6, .gt. 50% of the bits are wasted as filler (got to love me some ::) so it seems like a lot, yet folks have already predicted the demise of IPv6 in the next 20years. (Klensin I think it was) --bill

On Fri, 2 Apr 2010, jim deleskie wrote:

Just like 640k or memory :)

But what if I said "640 petabytes will be more than anyone will ever need". The future might prove me wrong but it probably won't happen for a long time. That's a better analogy for IPv6. IPv6 could have included a larger address space, or it could have been allocated differently[1] but the reality is we have no way of knowing how future generations will use the network. I full expect that advances in computing will render IPv6 obsolete well before the address space is exhausted. Perhaps this may occur in 100 years or more. Future generations may well have to go back to the drawing board to develop new protocols to best utilise the technology that they have available at the time. [1] 48bit host identifier rather than 64bit, for example Rob

On Fri, Apr 2, 2010 at 9:25 PM, Randy Bush <randy@psg.com> wrote:

...

...

IPv6 as effectively reindroduced classful addressing.

but it's not gonna be a problem this time, right?  after all, 32^h^h128^h^h^h64 bits is more than we will ever need, right?

randy

-- Email: robert@timetraveller.org IRC: Solver Web: http://www.practicalsysadmin.com Open Source: The revolution that silently changed the world

On 4/2/2010 19:25, Randy Bush wrote:

...

IPv6 as effectively reindroduced classful addressing.

but it's not gonna be a problem this time, right? after all, 32^h^h128^h^h^h64 bits is more than we will ever need, right?

Just like last time. -- Democracy: Three wolves and a sheep voting on the dinner menu. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml

On Fri, Apr 02, 2010 at 05:19:12PM -0500, Joe Johnson wrote:

Maybe encourage people like Apple, Xerox, HP or Ford to migrate their operations completely to IPv6 and return their /8?

How are they going to completely migrate to v6 while there is a demand for v4 space (specifically, THEIR v4 space.)? As long as the beast is getting fed, there will be customers without v6, and they're not going to isolate themselves for the commercial benefit of an unrelated third party. And even if they did, it's only going to buy you a few months. --msa

On Fri, Apr 02, 2010 at 03:13:16PM -0700, Owen DeLong wrote:

Sigh... Guess you missed the last several go-arounds of

Running out of IPv4 will create some hardships. That cannot be avoided.

we won't run out, we won't exaust, we are -NOT- killing the last tuna. what we are doing is roughly what was anticipated in RFC 2050, we will get more efficent utilization of all the space.

Even if we were to reclaim the supposed unused legacy /8s, we'd still only extend the date of IPv4 runout by a few months.

wrong analogy. there won't be "green field" space - but there will still be lots to go around... for legacy style use (e.g. the Internet as we know it today) -- want to do something different? then use IPv6.

The amount of effort required to reclaim those few IPv4 addresses would vastly exceed the return on that effort. Far better for that effort to be directed towards the addition of IPv6 capabilities to existing IPv4 deployments so as to minimize the impact of IPv4 exhaustion.

here we disagree. Im all in favor of demonstrating 85% utilization of the IPv4 address pool before handing out new address space. --bill

Owen

On Apr 2, 2010, at 2:01 PM, Jeroen van Aart wrote:

...

I am curious. Once we're nearing exhausting all IPv4 space will there ever come a time to ask/demand/force returning all these legacy /8 allocations? I think I understand the difficulty in that, but then running out of IPs is also a difficult issue. :-)

For some reason I sooner see all IPv4 space being exhausted than IPv6 being actually implemented globally.

Greetings, Jeroen

On 4/2/2010 17:22, Randy Bush wrote:

ipv4 spae is not 'running out.' the rirs are running out of a free resource which they then rent to us. breaks my little black heart.

even if, and that's an if, ipv6 takes off, ipv4 is gonna be around for a loooong while. when 95% of the world has end-to-end ipv6, do you think amazon et alia are gonna blow 5% of their market by decomissioning ipv4?

we are gonna learn how to distribute and use ipv4 more efficiently. it's not that hard, we know how to do it. internet engineers have worked through and around a lot of problems, it's our job. making connectivity continue work for folk who, for whatever reason, delay migration from ipv4 is just part of our job. not to panic.

the hard part is figuring out how the rirs make money off ipv4 holders redistributing it among themselves. if that becomes a non-goal, things get a lot simpler.

So, jump through hoops to kludge up IPv4 so it continues to provide address space for new allocations through multiple levels of NAT (or whatever), and buy a bit more time, or jump through the hoops required to deploy IPv6 and eliminate the exhaustion problem? And also, if the IPv4 space is horse-traded among RIRs and customers as you allude to above, IPv6 will look even more attactive as the price and preciousness of IPv4 addresses increases. The idea isn't for IPv4 to be replaced (decommissioned). The idea is for IPv6 to be added, then things will slowly transition. IPv4 will be around for a long time indeed, but increasingly, new sites/services, and old sites/services will be adding IPv6 as a way to connect to them. Then at some point, IPv6 will become the "normal" way to connect, and IPv4 will be a the "legacy" way, with fewer and fewer using it. Also, reading your other post, if you don't understand the difference between 2^32 and 2^128, please start here: http://en.wikipedia.org/wiki/Exponential_growth Anyway, I see it as pretty much moot, since many major players (Comcast, Google, etc) are in the midst of major IPv6 deployments as we speak. Eventually you will have to jump on the bandwagon too. :-) - Jim

I'm old but maybe not old nuff to know if this was discussed before or not, but I've been asking people last few months why we don't just do something like this. don't even need to get rid of BGP, just add some extension, we see ok to add extensions to BGP to do other things, this makes at least if not more sence. -jim On Fri, Apr 2, 2010 at 11:13 PM, George Bonser <gbonser@seven.com> wrote:

...

-----Original Message----- From: Jim Burwell [mailto:jimb@jsbc.cc] Sent: Friday, April 02, 2010 6:00 PM To: nanog@nanog.org Subject: Re: legacy /8

...

So, jump through hoops to kludge up IPv4 so it continues to provide address space for new allocations through multiple levels of NAT (or whatever), and buy a bit more time, or jump through the hoops required to deploy IPv6 and eliminate the exhaustion problem?  And also, if the IPv4 space is horse-traded among RIRs and customers as you allude to above, IPv6 will look even more attactive as the price and preciousness of IPv4 addresses increases.

No problem,  everyone tunnels v4 in v4 and the "outer" ip address is your 32-bit ASN and you get an entire /0 of "legacy" ip space inside your ASN.  Just need to get rid of BGP and go to some sort of label switching with the border routers having an ASN to upstream label table and there ya go. Oh, and probably create an AA RR in DNS that is in ASN:x.x.x.x format.  Increase the MTU a little and whammo!  There ya go! Done.

:)

-----Original Message----- From: John Palmer (NANOG Acct) [mailto:nanog2@adns.net] Sent: Friday, April 02, 2010 7:29 PM To: nanog@nanog.org Subject: Re: legacy /8

Is someone volunteering to work on an RFC? Or, has someone done so for this already?

I have never heard of anything along that line. It is just something that has wandered through my mind from time to time wondering why nobody had ever done such a thing as it seems so easy. All you need is to increase the standard transit MTU a little bit so your encapsulation doesn't result in a bunch of additional packet fragmentation due to the encap overhead and create the new DNS AA RR and that would be about all that is required. If your network is an end user, you just announce one route ... your ASN ... to your transit providers and any peers. A transit operation announces their ASN and any they are collecting from peers. They hard part is getting all the end nodes to use IPIP tunneling as their primary protocol by default. It is doable but that is the hard part.

On Fri, 2 Apr 2010 22:06:24 -0700 "George Bonser" <gbonser@seven.com> wrote:

...

-----Original Message----- From: George Bonser [mailto:gbonser@seven.com] Sent: Friday, April 02, 2010 7:53 PM To: John Palmer (NANOG Acct); nanog@nanog.org Subject: RE: legacy /8

They hard part is getting all the end nodes to use IPIP tunneling as their primary protocol by default. It is doable but that is the hard part.

Actually, both methods could exist side by side. If a standard packet arrives, the destination AS is looked up using conventional routing information, it is encapsulated and sent to the destination AS. In other words, a standard packet is assumed to be a legacy address space packet. An encapsulated packet handled in the new way.

But you know, the fact that the network techies has not exactly spent the past 10 years busting down the doors for v6 should tell people something really important. That they are willing to wait until the wolf is at the door to switch means something that needs to be paid your attention. v6 could well be the protocol that broke the Internet because it is sort of like replacing a Jeep with a bus built by Rube Goldberg.

That adoption is so low at this point really says that it has failed.

I think the Y2K incident was an example worth observing. There was a lot of talk about it from at least 1995 onwards. In my experience however proper efforts to address it seemed to only start early to mid 1998, with the first half of 1999 being "crunch time" with the last six months of 1999 left to finalise anything left over. IPv6 seems to be following a similar time line - we're around two years away from running out of IPv4 addresses, and there now seems to be a lot more discussion, planning and implementation happening in recent times than there has been in the last 5 years. Y2K was a bit different though - there was no alternative other than fixing it. "Carrier grade NAT" didn't exist for YY fields, so there is no actual deadline for IPv6 like there was for Y2K. I think that is what is leaving room for people to think they don't have to deploy it soon, or that it has failed. Regards, Mark.

That adoption is so low at this point really says that it has failed.

In the real world, there is no success or failure, only next steps. At this point, IPv4 has failed, and IPv6 is the next step. No realistic alternative next steps exist at present. In addition any alternative next step to IPv6 would require massive forklift upgrades. IPv6 is already in place and has been for over 5 years. We just have to start using it. --Michael Dillon

-----Original Message----- From: Larry Sheldon [mailto:LarrySheldon@cox.net] Sent: Saturday, April 03, 2010 8:43 AM To: nanog@nanog.org Subject: Re: legacy /8

On 4/3/2010 10:34, Michael Dillon wrote:

...

...

That adoption is so low at this point really says that it has failed.

In the real world, there is no success or failure, only next steps. At this point, IPv4 has failed,

Failed? Really?!!?!

Failed in the sense that I am not sure there is enough time left to really get v6 deployment going before we hit the wall. It is like skydiving and waiting too long to open the chute. Any school teaching v4 at this point other than as a legacy protocol that they teach on the second year because "they might see it in the wild" should be closed down. All new instruction that this point should begin and end with v6 with v4 as an "aside". But that isn't.

-----Original Message----- From: Larry Sheldon [mailto:LarrySheldon@cox.net] Sent: Saturday, April 03, 2010 10:54 AM Cc: nanog@nanog.org Subject: Re: legacy /8

That is the parachute's fault?

Really? --

No. But that isn't the point. The point is that v6 was a bad solution to the problem. Rather than simply address the address depletion problem, it also "solves" a lot of problems that nobody has while creating a whole bunch more that we will have. Rather than simply address the problem that was on the horizon, the group took the opportunity to complicate it with a lot of other contraptions and saw that as being a "good thing" that apparently we and the vendors are just too dumb to realize or something. And they made v4 incompatible with v6 rather really addressing the problem. They saw simply extending the header with additional address bits to be a "bad thing" for some reason when that is really all that was needed and so they went on building their mousetrap and we have the mother of all internet protocols that slices and dices and even makes Julien fries when all we needed was a bigger potato peeler. I am not saying we can change it at this point but I am saying we should learn from it and never, ever, do things this way again.

-----Original Message----- From: marka@isc.org [mailto:marka@isc.org] Sent: Saturday, April 03, 2010 11:42 AM To: George Bonser Cc: Larry Sheldon; nanog@nanog.org Subject: Re: legacy /8

And we would have still had the same problem of intercommunicating. We know how to talk from IPv6 to IPv4 and get the reply traffic back. The hard part is how to initiate connection from IPv4 to IPv6. The same problem would exist in your "just expand the address bits world".

Mark

Actually, Mark, I hadn't said "just expand the address", I said to tunnel v4 in v4 which we already know how to do and most routers are already capable of doing. But yes, in the case of legacy devices that don't "speak" the new protocol, some sort of state for the flow would have to be maintained in that unit's first hop (or close to first hop) gateway. Simply increasing the address header on v4 to 128 bits would have fixed this problem years ago and got rid of such problems as NAT and we wouldn't be having this issue (and it would have been completely backwards compatible as 0s would be inserted into the new expanded address bits to put the legacy space in a special address range. I wouldn't expect to work out all the details over email on a weekend but I don't think it would take 10 years, either. The fundamental issue to me is that v6 solves a lot of problems that aren't really problems for most people and to get the fix that solves the problem you do have, you must accept a bunch of additional "fixes" for problems you don't have that makes the whole thing some big unwieldy contraption. That having been said, once the world has migrated to v6, we should have an easier go of it in the future as v6 is more easily extensible. But in the meantime, we are stuck with both protocols for probably the next 20 years or so as there are going to be places that are going to run v4 internally even if they communicate v6 externally. So ... "we are going to mandate that everyone use this new and better car but it will take different fuel, use different tires, won't fit in your garage and oh, it is incompatible with all existing roads unless you load it up on one of the old style vehicles piggy-back, but new roads are being built (here's a picture of one) and might someday be available where you live. And two years from now there will be none of the old cars left." But my daughter will need a car in three years and there are no such roads here. "Oh well! The new way is much better, it is for your own good, you will see. Trust me".

On Apr 3, 2010, at 8:25 AM, George Bonser wrote:

The point is that v6 was a bad solution to the problem.

Well, yes, but...

Rather than simply address the address depletion problem, it also "solves" a lot of problems that nobody has while creating a whole bunch more that we will have.

Not really. The only problem IPv6 really solves (that couldn't be solved in one way or another in IPv4) was the limited amount of address space. Well, OK. IPv6 also does stateless autoconfiguration for folks who care about that, but you can (after much battle with the IETF) mostly ignore that if you don't care. IPv6 doesn't, unfortunately, solve the real problem which is routing system scalability, but that's a separate rant.

And they made v4 incompatible with v6 rather really addressing the problem.

How would you propose making going from a smaller fixed address space to a larger one backwards compatible? How would you deal with the myriad of applications that 'know' an IP address fits into a 32 bit "int" and make use of that fact?

I am not saying we can change it at this point but I am saying we should learn from it and never, ever, do things this way again.

Which is, I think, why some folks argue for more conservatism in address allocation policy. Regards, -drc

On Sat, 3 Apr 2010 11:25:48 -0700 "George Bonser" <gbonser@seven.com> wrote:

...

-----Original Message----- From: Larry Sheldon [mailto:LarrySheldon@cox.net] Sent: Saturday, April 03, 2010 10:54 AM Cc: nanog@nanog.org Subject: Re: legacy /8

That is the parachute's fault?

Really? --

No. But that isn't the point. The point is that v6 was a bad solution to the problem. Rather than simply address the address depletion problem, it also "solves" a lot of problems that nobody has while creating a whole bunch more that we will have.

Ever used IPX or Appletalk? If you haven't, then you don't know how simple and capable networking can be. And those protocols were designed more than 20 years ago, yet they're still more capable than IPv4. I used to teach Novell CNE courses around the mid 90s. Of the 7 courses, one of them was a two day course on a networking protocol. That networking protocol *wasn't* IPX - it was TCP/IP. IPX just worked, but you had to spend two days explaining TCP/IP. Even though I'd been using TCP/IP for a number of years before then, it still to me 5 attempts at teaching that course before I was completely happy with how I'd explained subnets, and had that feedback from students. I think IPv6 has not just learnt from the history of IPv4, it has also learnt from the history of other protocols.

Rather than simply address the problem that was on the horizon, the group took the opportunity to complicate it with a lot of other contraptions and saw that as being a "good thing" that apparently we and the vendors are just too dumb to realize or something. And they made v4 incompatible with v6 rather really addressing the problem. They saw simply extending the header with additional address bits to be a "bad thing" for some reason when that is really all that was needed and so they went on building their mousetrap and we have the mother of all internet protocols that slices and dices and even makes Julien fries when all we needed was a bigger potato peeler.

I am not saying we can change it at this point but I am saying we should learn from it and never, ever, do things this way again.

On Sat, 3 Apr 2010 18:37:51 -0700 (PDT) David Barak <thegameiam@yahoo.com> wrote:

--- On Sat, 4/3/10, Mark Smith <nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> wrote:

...

...

No.  But that isn't the point.  The point is

To: "George Bonser" <gbonser@seven.com> that v6 was a bad solution

...

to the problem.  Rather than simply address the address depletion problem, it also "solves" a lot of problems that nobody has while creating a whole bunch more that we will have.

Ever used IPX or Appletalk? If you haven't, then you don't know how simple and capable networking can be. And those protocols were designed more than 20 years ago, yet they're still more capable than IPv4.

Spoken like someone who has forgotten how much {fun|trouble} cable range + zones were...

I'll admit I didn't do enough with Appletalk to fully understand Zones. However I do like how cable ranges allow you to have odd numbers of multipes of 256 nodes, rather than doubling or halving the subnet size, as is the case with IPv4.

IPX, AppleTalk, VINES, DECNet, SNA, and all of the other protocol suites which were kicking around in the 80s and early 90s each had the "one thing they do really really well," but none of them were sufficiently flexible, extensible, easy, or cheap to capture the market.

Examples of some things which those protocols *didn't* do well include (obviously the list is different for each individual protocol):

In a lot of cases they were add-ons to IPv4 too. Crypto was an add on, multicast was an add on, more than 256 networks was an add on, IPv4 isn't always cheap and easy to implement because of IPR clauses. Centralised, database driven address administration via DHCP is probably unique, however distributed centralised services were available in IPX and Appletalk via SAP, NDS, NBP and ZIP.

* interdomain routing - most were optimized for single-administrative control networks * multicast * handle an encryption layer at layer 3 * cheap + easy to implement, no license required * distributed centralized administration (i.e. DHCP servers) * tolerate a wide variety of {link|connection} performance characteristics

The following are worth having look at, as they show what was the state of the art when they were published in 1985. "Xerox Network Systems Architecture - Introduction to Xerox Network Systems" http://bitsavers.org/pdf/xerox/xns/XNSG058504_XNS_Introduction.pdf "Xerox Network Systems Architecture - General Information Manual" http://bitsavers.org/pdf/xerox/xns/XNSG068504_XNS_GenInfo.pdf Most of the things on your list are there, or could have been as added using the same methods used to add them to IPv4.

...

I think IPv6 has not just learnt from the history of IPv4, it has also learnt from the history of other protocols.

Sadly, though, it also picked up some of the mistaken optimizations from the other protocols. The mess that has been made of RA+SLAAC+DHCPv6+DNS is something which can't be described as "elegant," and I certainly don't find it an improvement over IPv4 DHCP+DNS.

Unfortunately I think that was always going to happen. I don't think there is as strong a need for centralised management of IP address space as what DHCP/BOOTP/RARP have provided. However as DHCP et al. is the only way to do autoconf in IPv4, I think people were always going to want to have a stateful equivalent in IPv6 as they're comfortable with it. If people were prepared to have given up the "DHCP way" of managing addresses, and had accepted using link layer addresses as layer 3 node addresses, like XNS did (and IPv4 originally did too - RFC826 is the in 800s for a reason), then IPv6 could have been simpler by not having to have a neighbor discovery protocol to map layer 3 to layer 2 addresses. I'm hoping multicast DNS and DNS-Service Discovery become more popular. In conjunction with IPv6 SLAAC, the Internet will have finally caught up with what people were easily doing in the early 1990s with Appletalk and IPX. Regards, Mark.

On Sat, Apr 03, 2010, Vadim Antonov wrote:

Step 1: specify an IP option for extra "low order" bits of source & destination address. Add handling of these to the popular OSes.

Don't IP options translate to "handle in slow path" on various routing platforms? :) THat makes "leave backbones unchanged" not happen. Adrian

This sounds like Step 1: I have a wisdom tooth, it hurts on my right jaw and so I will chew from my left. Step 2: Take some pain killers. Step 3: Damn it hurts I will ignore it and it will eventually heal. Step 4: Continue to take pain killers and perhaps if I sleep more it will grow in the right direction and everything will be fine. Step 5: Wake up everything is fine. You will actually wake up without a toothache and things will seem fine except you now have teeth you don't actually need because they will cause blockage, hard to brush, floss constraints, many future dental trips etc. Your ancestors needed wisdom teeth in the stone age because they bit off more than they could chew, food was rough and coarse and teeth fell out easily. Through evolution diet changed and jaws eventually became smaller and humans chewed differently so you don't need the protection of wisdom teeth. Given that understanding you can avoid 5 painful steps and go to a doctor to have it pulled out, slight extra pain in doing so but you gain healthier teeth. Leaving dentistry and coming back to IP, we have to think of what we want the future IP address model to be and how does it affects the future of the Internet model. A lot of smart people have come together to bring the IPv6 solution, it works (not without flaws but neither did IPv4 in the early days) so lets work together in figuring out implementation and adoption. There is nothing stopping anyone from writing an RFC on IP option for low order bits+NAT et al and to that I wish anyone well. Just make sure one addresses scaling/backward compatibility because it will be like not being able to predict what kind of food will get stuck around your oddly grown wisdom tooth that caused a hole and now need a filling. Implementing IPv4 patches/NAT etc will not harm or break the Internet model but the question is do we want this or do we want to implement IPv6 that may be have a bit of pain now but the right thing for the future. Lets go where we want and have a healthy Internet, adopt IPv6 and phase out IPv4. Zaid P.s. Disclaimer: I have always been a network operator and never a dentist. I did build networks for a medical university many moons ago and often got into interesting discussions about medicine. On 4/3/10 11:11 PM, "Vadim Antonov" <avg@kotovnik.com> wrote:

With all that bitching about IPv6 how come nobody wrote an RFC for a very simple solution to the IPv4 address exhaustion problem:

Step 1: specify an IP option for extra "low order" bits of source & destination address. Add handling of these to the popular OSes.

Step 2: make NATs which directly connect extended addresses but also NAT them to non-extended external IPs.

Step 3: leave backones unchanged. Gradually reduce size of allocated blocks forcing people to NAT as above.

Step 4: watch people migrating their apps to extended addresses to avoid dealing with NAT bogosity and resulting tech support calls & costs.

Step 5: remove NATs.

--vadim

On 4/4/10 2:04 PM, "Vadim Antonov" <avg@kotovnik.com> wrote:

...

Zaid

P.s. Disclaimer: I have always been a network operator and never a dentist.

I would have thought opposite.

It is sometimes helpful to draw lessons from nature and other systems :)

People who have been on this list longer would probably remember when I was playing in this sandbox.

The real wisdom about networks is "never try to change everything and everywhere at once". You either do gradual migration, or you end up in a big pile of poo. Which what IPv6 transition situation is.

--vadim

I too apply the same "real wisdom" and view IPv6 transition as a gradual migration and we are seeing a lot of success already with this approach, its just that the adoption numbers are slower than we would like. I get a sense that our 5+ year IPv6 discussions have people worried and panicked that the best thing is to leave things as they are <insert NAT solutions> which makes me think we should perhaps spend less time on the advocacy part of IPv6 solution and put our efforts on what we get out of implementation. Zaid

On Sun, 04 Apr 2010 20:01:36 -0700 joel jaeggli <joelja@bogus.com> wrote:

On 4/3/2010 6:15 PM, Mark Smith wrote:

...

Ever used IPX or Appletalk? If you haven't, then you don't know how simple and capable networking can be. And those protocols were designed more than 20 years ago, yet they're still more capable than IPv4.

Zing, and there you have it! The hourglass is thin in the middle. One of if not the defining propteries of the ip protocol is what it doesn't do, which is virtually everything.

Well since it has become the only layer 3 protocol, shouldn't it be good enough or made good enough to do everything that's been done in the past and proven useful? IPv4 didn't succeed because it was significantly better than IPX or Appletalk. IPX has 32 bit network numbers (and 48 bit node addresses), so as a protocol it could have scaled to the Internet's size better than IPv4 has. However, the network effect kicked in - the Internet talks IPv4, so that's what people started running. People eventually seem to be rational about efficiency and said, "we're always going to have to run IPv4 because we always want to be connected to the Internet, so lets try to stop running multiple protocols that are nearly functionally equivalent." So Novell ported their services operating over TCP/IP, and Apple did the same. The thing that IPX and Appletalk did better than IPv4 was make networking much more convenient to operate. That was lost when they were abandoned. IPv6 will (hopefully) help bring them back. Regards, Mark.

-----Original Message----- From: James Hess [mailto:mysidia@gmail.com] Sent: Saturday, April 03, 2010 2:08 PM To: George Bonser Cc: nanog@nanog.org Subject: Re: legacy /8

On Sat, Apr 3, 2010 at 11:31 AM, George Bonser <gbonser@seven.com> wrote:

...

Any school teaching v4 at this point other than as a legacy protocol that they teach on the second year because "they might see it in the wild" should be closed down.  All new instruction that this point should begin and end with v6 with v4 as an "aside".  But that isn't.

They would be doing the student, their customer, a disservice to not teach both, with emphasis on V4, just because one possible speculated outcome in the years ahead is that IPv4 becomes a legacy protocol. Schools do not have crystal balls, and they can't know how important IPv4 or IPv6 will be to those taught later.

I've been taking some networking classes for my undergrad college degree, and there've only been about 3 mentions of IPv6 during the whole time I've been here (at supposedly a high-tech school). Also, did I mention we're still being taught classful networking? I've never heard my professors udder the CIDR acronym or talk about subnetting. Hopefully this changes as students progress into the higher-level classes, but I wouldn't want to be the one attempting to get a job with no knowledge of what's changed since my professor was in school. ---------- Stephen (Trey) Repetski skr3394@rit.edu | skrepetski@gmail.com srepetsk.net | RIT '13, TJHSST '09

On 4/3/2010 1:31 PM, George Bonser wrote:

...

-----Original Message----- From: Larry Sheldon [mailto:LarrySheldon@cox.net] Sent: Saturday, April 03, 2010 8:43 AM To: nanog@nanog.org Subject: Re: legacy /8

On 4/3/2010 10:34, Michael Dillon wrote:

...

...

That adoption is so low at this point really says that it has

failed.

...

In the real world, there is no success or failure, only next steps. At this point, IPv4 has failed,

Failed? Really?!!?!

Failed in the sense that I am not sure there is enough time left to really get v6 deployment going before we hit the wall. It is like skydiving and waiting too long to open the chute.

Any school teaching v4 at this point other than as a legacy protocol that they teach on the second year because "they might see it in the wild" should be closed down. All new instruction that this point should begin and end with v6 with v4 as an "aside". But that isn't.

We've been dealing with the IPV4 myth now for over 7 years that i have followed it. It's about as valid as the exaflood myth. Part fo the reason folks aren't rushing to the V6 bandwagon is it's not needed. Stop doing the chicken little dance folks. V6 is nice and gives us tons of more addresses but I can tell you V4 is more than two years form "dying" just by seeing all the arm flailing going around.

...

We've been dealing with the IPV4 myth now for over 7 years that i have followed it. It's about as valid as the exaflood myth. Part fo the reason folks aren't rushing to the V6 bandwagon is it's not needed. Stop doing the chicken little dance folks. V6 is nice and gives us tons of more addresses but I can tell you V4 is more than two years form "dying" just by seeing all the arm flailing going around.

IPv4 will not die in 2 years. Growth in IPv4 accessible hosts will stop or become significantly more expensive or both in about 2.5 years (+/- 6 months). The more content and services that are available dual-stack (v4 and v6) by the time that occurs, the less of an issue that fact will be for all concerned. Owen

David Conrad <drc@virtualized.org> writes:

...

Growth in IPv4 accessible hosts will stop or become significantly more expensive or both in about 2.5 years (+/- 6 months).

Growth stopping is extremely unlikely. Growth becoming significantly more expensive is guaranteed. ...

more expensive for whom, though? if someone has to find existing address space and transfer it at some payment to the current holder in order to grow their own network, that's a direct expense. if this became common and resulted in significant deaggregation, then everybody else attached in some way to the "global routing table" would also have to pay some costs, which would be indirect expenses. unless a market in routing slots appears, there's no way for the direct beneficiaries of deaggregation to underwrite the indirect costs of same. at a systemic level, i'd characterize the cost of that kind of growth as instability rather merely expense.

Address utilization efficiency will increase as people see the value in public IPv4 addresses. ISPs interested in continuing to grow will do what it takes to obtain IPv4 addresses and folks with allocated- but- unused addresses will be happy to oblige (particularly when they accept that they only need a couple of public IP addresses for their entire network). At some point, it may be that the cost of obtaining IPv4 will outstrip the cost of migrating to IPv6. If we're lucky.

the cost:benefit of using ipv6 depends on what other people have deployed. that is, when most of the people that an operator and their customers want to talk to are already running ipv6, then the cost:benefit will be compelling compared to any form of continued use of ipv4. arguments about the nature and location of that tipping point amount to reading tea leaves. nevertheless if everybody who can deploy dual-stack does so, we'll reach that tipping point sooner and it'll be less spectacular. -- Paul Vixie Chairman, ARIN BoT

From: David Conrad <drc@virtualized.org> Date: Sun, 11 Apr 2010 10:30:05 -1000

...

unless a market in routing slots appears, there's no way for the direct beneficiaries of deaggregation to underwrite the indirect costs of same.

And that's different from how it's always been in what way?

when 64MB was all anybody had, deaggregation was rendered ineffective by route filtering. what i've seen more recently is gradual monotonic increase in the size of the "full table". if the systemic cost of using all of ipv4 includes a 10X per year step function in routing table size then it will manifest as instability (in both the network and the market). as you have pointed out many times, ipv6 offers the same number of /32's as ipv4. however, a /32 worth of ipv6 is enough for a lifetime even for most multinationals, whereas for ipv4 it's one NAT or ALG box. so, i'm thinking that making ipv4 growth happen beyond pool exhaustion would be a piecemeal affair and that the routing system wouldn't accomodate it painlessly. the rate of expansion of "other people's routers" seems to fit the growth curve we've seen, but will it fit massive deaggregation?

My tea leaf reading is that history will repeat itself. As it was in the mid-90's, as soon as routers fall over ISPs will deploy prefix length (or other) filters to protect their own infrastructure as everybody scrambles to come up with some hack that won't be a solution, but will allow folks to limp along. Over time, router vendors will improve their kit, ISPs will rotate out routers that can't deal with the size/flux of the bigger routing table (passing the cost on to their customers, of course), and commercial pressures will force the removal of filters. Until the next go around since IPv6 doesn't solve the routing scalability problem.

instability like we had in the mid-1990's would be far more costly today, given that the internet is now used by the general population and serves a global economy. if the rate of endpoint growth does not continue beyond ipv4 pool exhaustion we'll have a problem. if it does, we'll also have a problem but a different problem. i'd like to pick the easiest problem and for that reason i'm urging dual-stack ipv4/ipv6 for all networks new or old. -- Paul Vixie Chairman, ARIN BoT

In message <54701FCF-13EA-44DA-8677-26A7C6635EF1@virtualized.org>, David Conrad writes:

On Apr 11, 2010, at 10:57 AM, Paul Vixie wrote:

...

i'd like to pick the easiest problem and for that reason i'm urging dual-stack ipv4/ipv6 for all networks new = or old.

Is anyone arguing against this? The problem is what happens when there = isn't sufficient IPv4 to do dual stack.

On the client side you will still be dual stack and also be using PNAT (single, double or distributed) to more efficiently use the available IPv4 addresses. There will be service providers that provide client address pools for those that can't get IPv4 addresses themselves using technologies like ds-lite to transport the traffic. On the server side you will be able to purchase the use of a IPv4 address and the packets will be tunneled back to you socks like. Eventually most of the traffic will switch to being IPv6 and providers of theses services will disappear as they are no longer profitable to run. Mark

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

plenty of people have accused ipv6 of being a solution in search of a problem. on this very mailing list within the last 72 hours i've seen another person assert that "ipv6 isn't needed." while i tend to agree with tony li who of ipv6 famously said it was "too little and too soon" we have been Overtaken By Events and we now have to deploy it "or else".

http://www.hactrn.net/sra/vorlons

On Apr 11, 2010, at 11:34 AM, David Conrad wrote:

On Apr 11, 2010, at 8:09 AM, Owen DeLong wrote:

...

...

Part fo the reason folks aren't rushing to the V6 bandwagon is it's not needed. Stop doing the chicken little dance folks. V6 is nice and gives us tons of more addresses but I can tell you V4 is more than two years form "dying" just by seeing all the arm flailing going around. IPv4 will not die in 2 years.

I'd wager it won't be dead in 20 years. Of course, a lot depends on what is meant by "dying".

Yep. Assuming IPv6 catches on in the post-runout crisis (and I think it will), I suspect that IPv4 will be largely deprecated on the wide-spread internet within about 5-10 years of IPv6 practical ubiquity. I suspect it will ALWAYS be used in some niches somewhere.

...

Growth in IPv4 accessible hosts will stop or become significantly more expensive or both in about 2.5 years (+/- 6 months).

Growth stopping is extremely unlikely. Growth becoming significantly more expensive is guaranteed. Address utilization efficiency will increase as people see the value in public IPv4 addresses. ISPs interested in continuing to grow will do what it takes to obtain IPv4 addresses and folks with allocated-but-unused addresses will be happy to oblige (particularly when they accept that they only need a couple of public IP addresses for their entire network). At some point, it may be that the cost of obtaining IPv4 will outstrip the cost of migrating to IPv6. If we're lucky.

Eventually, utilization efficiency will get close to 100% and growth will, therefore stop. Note, I was specific about IPv4 accessible hosts, as in hosts which you can send a TCP SYN packet to, not merely hosts which can originate connections. Multi-layer NAT may help increase the number of IPv4-non-accessible hosts, but, it can do little to help increase accessible host count. Owen

Not often you hear something that has changed just about every aspect of life and enabled things that could not be imagined at its outset  called a failure

Sounds like you are describing the Roman Empire. It failed and that's why we now have an EU in its place. Things change. Time to move on. IPv4 has run out of addresses and we are nowhere near finished GROWING THE NETWORK. IPv6 was created to solve just this problem, and 10 years ago folks started deploying it in order to be ready. By 5 years ago, every significant router on the market supported IPv6. Now that we actually need IPv6 in order to continue network growth, most ISPs are in the fortunate position that their network hardware already supports it well enough, so the investment required is minimized. --Michael Dillon

On Apr 3, 2010, at 11:22 AM, Frank Bulk wrote:

If "every significant router on the market" supported IPv6 five years ago, why aren't transit links glowing with IPv6 connectivity? If it's not the hardware, than I'm guessing it's something else, like people or processes?

Or the fact that "supporting IPv6" could (and as far I could tell did until very recently) mean minimalistic process switching of packets without any of the 'niceties' of filtering, management, monitoring, etc. support. It also ignores the fact that there is a bit more to providing Internet service than simply running routers. However, historically we had: 1) why should ISPs pay to deploy IPv6 when their customers aren't asking for it? 2) why should customers ask for IPv6 when there is no content available via it? 3) why should content providers make their content available over IPv6 when they can't get it from their ISPs and none of their customers are asking for it? It may be that IPv4 free pool run out will result in costs for obtaining IPv4 to rise sufficiently to address (1). Or we could have multi-layer NAT. Regards, -drc

On Apr 3, 2010, at 2:49 PM, Zaid Ali wrote:

They are not glowing because applications are simply not moving to IPv6. Google has two popular applications on IPv6, Netflix is on it way there but what are other application companies doing about it? A popular application like e-mail is so far behind [ref: http://eng.genius.com/blog/2009/09/14/email-on-ipv6/] and I still encounter registrar's providing DNS service not supporting Quad A's.

Uh, netflix seems fully functional to me on IPv6. What do you think is missing? The registrar problem is definitely real... I'm having tremendous difficulty with OpenSRS. (If anyone from OpenSRS is listening, please fix this!!) My email seems to work fine dual-stacked when I haven't borked the router.

I feel talking to network operators is preaching to the choir, the challenge is helping content providers think about moving to IPv6.

Indeed. Owen

-----Original Message----- From: Owen DeLong Sent: Saturday, April 03, 2010 9:13 PM To: Zaid Ali Cc: nanog@nanog.org Subject: Re: legacy /8

On Apr 3, 2010, at 2:49 PM, Zaid Ali wrote:

...

They are not glowing because applications are simply not moving to IPv6. Google has two popular applications on IPv6, Netflix is on it way there but what are other application companies doing about it? A popular application like e-mail is so far behind [ref: http://eng.genius.com/blog/2009/09/14/email-on-ipv6/] and I still encounter registrar's providing DNS service not supporting Quad A's.

Uh, netflix seems fully functional to me on IPv6. What do you think is missing?

Well, there are a lot of companies out there building server applications who don't have the human bandwidth to migrate the application. Things like application clusters that do a lot if internal multicast, for example, would need to change. My instincts say you are going to see v6 roll out in a lot of production networks with devices like load balancers that can have an IPv6 virtual IP balanced to v4 servers on the back end. In that sense people aren't really migrating to v6 so much as they are accommodating it. And the vendors have some real problems when it comes to v6 that derives from lack of resource allocation. I can put together a bodacious route server on a quad CPU (hex core) with almost 200Gig of RAM for less than the cost of a management module on a small-ish router and offload a lot of the BGP stuff from the routers. In fact, with a few minor tricks you can have your edge routers connected to several peers and not have the peers talking BGP to your routers at all, they are all talking to your "bodacious" route server to which you can add processing power / RAM as needed. At that point your edge routers have one single BGP peer, the route server. And I have actually used this sort of thing in production albeit "back in the day" when the routing table first started to explode beyond the capabilities of some purple cyclops layer 3 switches I was using at the time. That is the fundamental problem as I see it right now. The vendors do not want to ship the resources required until they need to (it isn't a problem until it is a problem) and they all end up behind the curve reacting to this crisis or that rather than getting ahead of the game and producing the router than can handle a serious number of 128-bit routes. It isn't that the routing policy is bad, it is that we continue to have to work around the limitations of the gear shipped from the vendors.

...

If "every significant router on the market" supported IPv6 five years ago,

and if cash fell from the sky ...

to folk actually running real networks, 'support' means *parity* with ipv4, i.e. fast path at decent rates, management and monitoring, no licensing extortion, ...

we don't have that today!

We need more of the spirit of the old days of networking when people building UUCP, and Fidonet and IP networks did less complaining about "vendors" and made things work as best they could. Eventually, the vendors caught on and jumped on the bandwagon. The fact is that lack of fastpath support doesn't matter until IPv6 traffic levels get high enough to need the fastpath. Today we need to get more complete IPv6 coverage. And if management and monitoring work fine on IPv4 and networks are dual-stacked, why change? Do you have an actual example of a vendor, today, charging a higher license fee for IPv6 support?

the *additional* cost and effort to the isp of fullly deploying dual-stack is still non-trivial.  this is mightily off-pissing.

Nobody promised you a free lunch. In any case, the investment required to turn up IPv6 support is a lot less than the cost of carrier grade NAT. And the running costs of IPv6 are also lower, --Michael Dillon

...

Do you have an actual example of a vendor, today, charging a higher license fee for IPv6 support?

Juniper. If you want to run OSPFv3 on their layer 3 switches, you need a quite expensive "advanced" licence. OSPFv2, on the other hand, is included in the base licence.

Our IPv6 topology is largely based on static routes because of this. There's no customers that are willing to pay extra for IPv6 support at the moment, hence we cannot justify the extra cost of the licences. It sucks. I hope Juniper will come to their senses soon.

It used to be considerably worse. As late as May 2009, Juniper charged $10.000 (list price) for an "IPv6 Support on JunOS" on license (for high end M/MX/T series), and the same amount for an E series IPv6 license. Fortunately Juniper seems to have come to their senses here, and these licenses are now $0. Steinar Haug, Nethelp consulting, sthaug@nethelp.no

Juniper. If you want to run OSPFv3 on their layer 3 switches, you need a quite expensive "advanced" licence. OSPFv2, on the other hand, is included in the base licence.

yep maybe try is-is randy

On Sun, Apr 4, 2010 at 2:24 PM, David Conrad <drc@virtualized.org> wrote:

On Apr 3, 2010, at 10:46 PM, Michael Dillon wrote:

...

The fact is that lack of fastpath support doesn't matter until IPv6 traffic levels get high enough to need the fastpath.

Yeah, fortunately, the fact that your router is burning CPU doing IPv6 has no impact on stuff like BGP convergence.

also, for the record, there are parts of this ipv6 internet thing where ... doing things in the slowpath is no longer feasible.

On 4/4/2010 5:10 PM, Christopher Morrow wrote:

On Sun, Apr 4, 2010 at 4:32 PM, joel jaeggli<joelja@bogus.com> wrote:

...

Last time I checked, some of the state of the art 2004 era silicon I had laying around could forward v6 just fine in hardware. It's not so usefyl due to it's fib being a bit undersized for 330k routes plus v6, but hey, six years is long time.

<cough>4948</cough> (not 6yrs old, but... still forwards v6 in the slow-path, weee!)

Yes it does. and the slow path is sloooooooooow on the that switch. but switches and routers did and do come in colors other than blue. :/

Do like the Chinese if you want a feature put out a billion dollar tender with the feature mandatory and they will rush to do it Toute connaissance est une réponse à une question On 5/04/2010, at 14:48, Christopher Morrow <morrowc.lists@gmail.com> wrote:

On Sun, Apr 4, 2010 at 7:41 PM, joel jaeggli <joelja@bogus.com> wrote:

...

On 4/4/2010 5:10 PM, Christopher Morrow wrote:

...

On Sun, Apr 4, 2010 at 4:32 PM, joel jaeggli<joelja@bogus.com> wrote:

...

Last time I checked, some of the state of the art 2004 era silicon I had laying around could forward v6 just fine in hardware. It's not so usefyl due to it's fib being a bit undersized for 330k routes plus v6, but hey, six years is long time.

<cough>4948</cough> (not 6yrs old, but... still forwards v6 in the slow-path, weee!)

Yes it does. and the slow path is sloooooooooow on the that switch. but switches and routers did and do come in colors other than blue.

but, but, but.. then it won't match! and seriously, I can't have another run in with the fashion police.

In actual seriousness, my point is that plenty of this sort of gear is in the network, and will be for a time. It's sort of inexcusable that vendors put out gear 5 years ago that didn't do v6 in the fast path... oh well.

-chris

...

Nobody promised you a free lunch. In any case, the investment required to turn up IPv6 support is a lot less than the cost of carrier grade NAT. And the running costs of IPv6 are also lower,

Can you provide pointers to these analyses? Any evidence-backed data showing how CGN is more expensive would be very helpful.

It depends. If you plan to do IPv6 eventually, it's probably cheaper to do it now than to depend on NAT444. NAT444 breaks some things (fewer than you might expect, so it might not be as expensive as you think). Some of those things can be fixed by doing static port forwarding, but that means a support call explaining how to configure port forwarding on the LSN, and troubleshooting through the CPE. Cost analysis: more support calls, but might be even with IPv6 support calls. If your provisioning and OSS are centralized, you may need multiple instances inside each LSN (or tunnels, or some other way to cope with the fact that you now have multiple domains of 10/8 inside your network). Cost analysis: may be the same amount of development required to add IPv6 functionality, but additional hardware may be required. You need a pretty big logging infrastructure, so you have an answer when Smokey says, "Who had this address with this source port at time T six months ago?" and lawyers on hand to explain why you won't tell them all 500 customers who were using that address at the time. And a variety of things documented in draft-ford-shared-addressing-issues. Cost analysis: lots of disk, lawyers, for issues that don't exist in IPv6. All of your hardware already speaks IPv4, very little requires updates to support private addressing. Cost analysis: you probably have some hardware that doesn't support IPv6. If cost were the only criterion, it might be an even split between NAT444 and IPv6. Using NAT444 to delay replacing non-IPv6 hardware until the regular depreciation cycle means spending twice on development labor just to delay the capex. That math may or may not make sense for your network.. Lee

On Fri, 2 Apr 2010 21:29:20 -0500 "John Palmer \(NANOG Acct\)" <nanog2@adns.net> wrote:

Is someone volunteering to work on an RFC? Or, has someone done so for this already?

Probably similar to this (and others that remove end-site knowledge from the Internet core) - The Locator Identifier Separation Protocol (LISP) http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_11-1/111_lisp...

----- Original Message ----- From: "jim deleskie" <deleskie@gmail.com> To: <nanog@nanog.org> Sent: Friday, April 02, 2010 9:17 PM Subject: Re: legacy /8

I'm old but maybe not old nuff to know if this was discussed before or not, but I've been asking people last few months why we don't just do something like this. don't even need to get rid of BGP, just add some extension, we see ok to add extensions to BGP to do other things, this makes at least if not more sence.

-jim

On Fri, Apr 2, 2010 at 11:13 PM, George Bonser <gbonser@seven.com> wrote:

...

...

-----Original Message----- From: Jim Burwell [mailto:jimb@jsbc.cc] Sent: Friday, April 02, 2010 6:00 PM To: nanog@nanog.org Subject: Re: legacy /8

...

So, jump through hoops to kludge up IPv4 so it continues to provide address space for new allocations through multiple levels of NAT (or whatever), and buy a bit more time, or jump through the hoops required to deploy IPv6 and eliminate the exhaustion problem? And also, if the IPv4 space is horse-traded among RIRs and customers as you allude to above, IPv6 will look even more attactive as the price and preciousness of IPv4 addresses increases.

No problem, everyone tunnels v4 in v4 and the "outer" ip address is your 32-bit ASN and you get an entire /0 of "legacy" ip space inside your ASN. Just need to get rid of BGP and go to some sort of label switching with the border routers having an ASN to upstream label table and there ya go. Oh, and probably create an AA RR in DNS that is in ASN:x.x.x.x format. Increase the MTU a little and whammo! There ya go! Done.

:)

-----Original Message----- From: jim deleskie Sent: Friday, April 02, 2010 7:17 PM To: nanog@nanog.org Subject: Re: legacy /8

I'm old but maybe not old nuff to know if this was discussed before or not, but I've been asking people last few months why we don't just do something like this. don't even need to get rid of BGP, just add some extension, we see ok to add extensions to BGP to do other things, this makes at least if not more sence.

-jim

We wouldn't really need to get rid of BGP, it would just be that there would be potentially one route per ASN with no (or very little) aggregation. Some form of label switching where you map ASNs to peers might just be a little more efficient as you would only see the number of labels that you have peers. If the vendors are prepared to grow their capabilities along with the number of ASNs assigned, then there is no problem. Currently that would not be a problem. There are only 56,218 allocated 16-bit ASNs and 5120 allocated 32-bit ASNs for a current total of only about 61,000-ish "routes". Any peering router in use today that takes full routes would be able to handle this in its sleep.

On Fri, Apr 2, 2010 at 9:17 PM, jim deleskie <deleskie@gmail.com> wrote:

not, but I've been asking people last few months why we don't just do something like this. don't even need to get rid of BGP, just add some [snip] On Fri, Apr 2, 2010 at 11:13 PM, George Bonser <gbonser@seven.com> wrote: [snip]>> and there ya go. Oh, and probably create an AA RR in DNS that is in

...

ASN:x.x.x.x format.  Increase the MTU a little and whammo!  There ya go!

It's a good idea. But, it should be noted the 'end result' is not the only thing that matters, in regards to internet protocol, the transition mechanism you need to change and convince the community to change from using an old protocol and old methods to using a new protocol and new practices is almost everything --- stakeholders want no disruption to the stability, or end-to-end connectivity of the internet at any point in time -- if every network must update software, even in the same decade as each others' networks, the protocol change may be as good as dead, due to the relative infrequency of large providers updating equipment. The lack of a good well-thought-out transition mechanism can in effect be a show-stopper for any proposed change to widely-deployed existing protocol. IPv6 has 'dual stack'. It doesn't suffer the 1st problem, but its transition burden _still_ prevents universal IPv6 connectivity'. ASN routing would probably have a similar fate, unless someone came up with a bulletproof easy-as-pie transition mechanism (something preferably better than dual stack). So, how does a HTTP client indicate in the IP packet, the destination ASN obtained from looking up the value of this AA record? And how does that packet get to the web server at another provider, when the user's ISP or their ISP's upstream transit provider is not "ASN-routing-ready" yet......... Or do you suggest an internet flag day? Also, the socket peer of every IP transaction needs to know the source ASN, that means if you modify IP packets to add a 'destination ASN field', you also need a 'source ASN' field. Else there will be no way for the server to send return traffic with full IP information, or even complete TCP connection handshake reliably, especially in multi-homed scenarios. Another result is if either connection endpoint does not know about the new 'ASN packet labelling', they will be unable to properly label their return traffic (particularly in the case of multi-homed networks)... resulting in lack of ability to connect to each other, as the return traffic goes somewhere other than where expected ASN routing would also have some interesting implications for multi-homing in general. Introduces some potentially troubling scenarios where a malicious actor might find some advantage in the ability to force the ASN destination of arbitrary spoofed packets to something unnatural. -- -J

In message <p2offcec29f1004030657r97e6b8l426be7d10252d64@mail.gmail.com>, jim d eleskie writes:

James,

I agree with you concern, and as someone else said the devil is in the details, you points are something that would need to be looked at if enough people though we should move forward and look at an idea like this, which I think we should, but not sure if enough traffic to start down that road yet. If we do though, this is the kind of input we'd need.

-jim

This sort of thing was thought of and *rejected* over a decade ago. You will still have ALL the reachability problems from legacy machines that you have with IPv4 + IPv6. Your Windows 95 machine wouldn't be able to reach most of the Internet as it would be under this model. You still need to upgrade all the application and other tools. There never was a magic wand that could fix this. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

Not sure the IETF looked at it or not, but personally I'm one of those people that has never accepted a solution just because, its the only option there. I haven't always won my battles, but never just give in :) -jim On Sat, Apr 3, 2010 at 3:47 AM, Jim Burwell <jimb@jsbc.cc> wrote:

On 4/2/2010 19:13, George Bonser wrote:

...

...

-----Original Message----- From: Jim Burwell [mailto:jimb@jsbc.cc] Sent: Friday, April 02, 2010 6:00 PM To: nanog@nanog.org Subject: Re: legacy /8

...

So, jump through hoops to kludge up IPv4 so it continues to provide address space for new allocations through multiple levels of NAT (or whatever), and buy a bit more time, or jump through the hoops required to deploy IPv6 and eliminate the exhaustion problem?  And also, if the IPv4 space is horse-traded among RIRs and customers as you allude to above, IPv6 will look even more attactive as the price and

preciousness

...

of IPv4 addresses increases.

No problem,  everyone tunnels v4 in v4 and the "outer" ip address is your 32-bit ASN and you get an entire /0 of "legacy" ip space inside your ASN.  Just need to get rid of BGP and go to some sort of label switching with the border routers having an ASN to upstream label table and there ya go. Oh, and probably create an AA RR in DNS that is in ASN:x.x.x.x format.  Increase the MTU a little and whammo!  There ya go! Done.

:)

So essentially add 32-bits to the IPv4 address, used as a ASN, and use legacy V4 on the "backbone" which tunnels everything, so the entire intra-ASN internet has to go through v4-in-v4 tunnels.  A few "little" changes to DNS, and voila!  And of course, there's no "devils in the details" we have to worry about.  Heck.    Just quote that last post up and submit it as an RFC to replace the IPv6 RFCs!  :-)

Seriously though, would that really be easier to implement, or be better than IPv6 as this point?  I'd think the IETF would probably have considered solutions like that, but IPv6 is what we got.  So best learn to love it.  :P

-Jim

-----Original Message----- From: Jim Burwell [mailto:jimb@jsbc.cc] Sent: Friday, April 02, 2010 11:48 PM To: George Bonser Cc: nanog@nanog.org Subject: Re: legacy /8

On 4/2/2010 19:13, George Bonser wrote:

...

...

-----Original Message----- From: Jim Burwell [mailto:jimb@jsbc.cc] Sent: Friday, April 02, 2010 6:00 PM To: nanog@nanog.org Subject: Re: legacy /8

Seriously though, would that really be easier to implement, or be better than IPv6 as this point? I'd think the IETF would probably have considered solutions like that, but IPv6 is what we got. So best learn to love it. :P

-Jim

That is true and we have little choice at this point but we had 10 years and simply encapsulating v4 in v4 could have been implemented at the router level years ago with little problem years ago. And forget about the IETF at this point because they would not have had to be involved with this. It is operating within the v4 spec that was already specified, they would not have had to do anything. Call it v4^2 and implement it initially at the router level and then eventually customer demand pulls it down to the end system level with tcp/ipip becoming the standard. It was really just a muse (the point of the smiley at the end). I will be in the process of deploying v6 once I get a current project put to bed. Where did I put that helmet? G

On 4/2/2010 21:23, Randy Bush wrote:

...

Anyway, I see it as pretty much moot, since many major players (Comcast, Google, etc) are in the midst of major IPv6 deployments as we speak. Eventually you will have to jump on the bandwagon too. :-)

clue0: the isp for which i work deployed ipv6 in the '90s. we were the world's first commercial ipv6 isp deployment.

<golf clap>

clue1: not only can i do the math, but i can remember history

Heh. I didn't really doubt that you understood the math. Was just being a bit snarky. :p (this whole thread is sort of flame bait anyway hehe). Anyway, with just 2000::/3 alone, there's about 500 million /32s. According to the CIDR report, there's ~34,000 ASs in BGP right now. Lets double that "for future growth" just for fun. If we do that, it means if we divided those /32s evenly among all of those ASes, each would get about 7800 of them. Each one contains 64Ki /48s. And again, that's just one /3 of the entire v6 space (yeah I know they won't be divided evenly ... different sizes orgs, regional assignments, etc, etc, etc). Anyway, I think the addy space will tide us over for quite a while, even if it's "not enough" as your last post seemed to indicate. Hey, and if we ever do run out, we can just NAT! ;) ;) ;) -Jim

On 03/04/10 00:09 +0000, bmanning@vacation.karoshi.com wrote:

On Fri, Apr 02, 2010 at 03:13:16PM -0700, Owen DeLong wrote:

...

Sigh... Guess you missed the last several go-arounds of

Running out of IPv4 will create some hardships. That cannot be avoided.

we won't run out, we won't exaust, we are -NOT- killing the last tuna. what we are doing is roughly what was anticipated in RFC 2050, we will get more efficent utilization of all the space.

That statement becomes less truthy when more realistic definitions of 'we' are used. I'd suggest that attempts to stretch v4 addresses is going to fall over on its side, for large segments of we. Address exchanges on the free market, and RIR reclamation will certainly be sufficient for other large segments. However, there will be a point in the next 3-5 years in which neither of these methods will be able to keep up with the tide of technological advancement.

...

Even if we were to reclaim the supposed unused legacy /8s, we'd still only extend the date of IPv4 runout by a few months.

wrong analogy. there won't be "green field" space - but there will still be lots to go around... for legacy style use (e.g. the Internet as we know it today) -- want to do something different? then use IPv6.

I already feel like a dinosaur sitting in front of my desktop, with a keyboard. The Internet as we know it today only has 2-3 years of v4 address supply left. The more we stretch address usage, the more we create something that does not resemble the Internet as we know it today.

...

The amount of effort required to reclaim those few IPv4 addresses would vastly exceed the return on that effort. Far better for that effort to be directed towards the addition of IPv6 capabilities to existing IPv4 deployments so as to minimize the impact of IPv4 exhaustion.

here we disagree. Im all in favor of demonstrating 85% utilization of the IPv4 address pool before handing out new address space.

-- Dan White

On Apr 2, 2010, at 4:40 PM, Brielle Bruns wrote:

On 4/2/10 3:01 PM, Jeroen van Aart wrote:

...

I am curious. Once we're nearing exhausting all IPv4 space will there ever come a time to ask/demand/force returning all these legacy /8 allocations? I think I understand the difficulty in that, but then running out of IPs is also a difficult issue. :-)

For some reason I sooner see all IPv4 space being exhausted than IPv6 being actually implemented globally.

Greetings, Jeroen

I've got a rather stupidly simple and straightforward plan, since we're all throwing ideas out.

Take back all the IP space from China and give them a single /20 and tell them to make do. They're already behind a great firewall, so they should have no problem using NAT with their citizens for easier restricting of freedoms, and for the actual services they need to run, they can assign a limited amount of static IP addresses for servers, and the rest NAT as well, and port forward for specific services.

Probably not the biggest flaw in this plan, but: Total number of RFC-1918 addresses: 18+ million. Population of China: More than 1.325 billion. I'll leave the other political aspects to others, but, the math simply doesn't work. Owen

On 4/2/10 6:36 PM, David Conrad wrote:

On Apr 2, 2010, at 1:40 PM, Brielle Bruns wrote:

...

Take back all the IP space from China and give them a single /20 and tell them to make do.

At current consumption rates, that'd buy us another year or so. Then what?

Regards, -drc

To quote: "we get some IP space back to buy us more time" Didn't say it was a solution, but we're all talking about buying more time for ipv6 transition. Its no worse then any other suggestion people have proposed. :) -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org