"nanog-request@nanog.org" <nanog-request@nanog.org> wrote: Send NANOG mailing list submissions to nanog@nanog.org To subscribe or unsubscribe via the World Wide Web, visit https://mailman.nanog.org/mailman/listinfo/nanog or, via email, send a message with subject or body 'help' to nanog-request@nanog.org You can reach the person managing the list at nanog-owner@nanog.org When replying, please edit your Subject line so it is more specific than "Re: Contents of NANOG digest..." Today's Topics: 1. RE: legacy /8 (George Bonser) 2. Re: legacy /8 (Randy Bush) 3. RE: legacy /8 (Frank Bulk) 4. RE: legacy /8 (Frank Bulk) 5. Re: legacy /8 (David Conrad) 6. Re: legacy /8 (Zaid Ali) 7. Re: legacy /8 (Mark Smith) 8. Fw: legacy /8 (Mark Smith) ---------------------------------------------------------------------- Message: 1 Date: Sat, 3 Apr 2010 12:09:51 -0700 From: "George Bonser" <gbonser@seven.com> Subject: RE: legacy /8 To: <marka@isc.org> Cc: nanog@nanog.org Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE6C76@RWC-EX1.corp.seven.com> Content-Type: text/plain; charset="us-ascii"

-----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". ------------------------------ Message: 2 Date: Sun, 04 Apr 2010 05:36:26 +0900 From: Randy Bush <randy@psg.com> Subject: Re: legacy /8 To: George Bonser <gbonser@seven.com> Cc: North American Network Operators Group <nanog@nanog.org> Message-ID: <m2hbnsjmt1.wl%randy@psg.com> Content-Type: text/plain; charset=US-ASCII

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.

it's known as "second system syndrome." and you neglect to add that ipv6 did not deal with the routing problems, which are rather intimately connected with addressing in both the ipv4 and the ipv6 models. randy ------------------------------ Message: 3 Date: Sat, 3 Apr 2010 16:22:12 -0500 From: "Frank Bulk" <frnkblk@iname.com> Subject: RE: legacy /8 To: <nanog@nanog.org> Message-ID: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAABa3wZheJVIR45rbqPho5y5AQAAAAA=@iname.com> Content-Type: text/plain; charset="iso-8859-1" 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? Frank -----Original Message----- From: Michael Dillon [mailto:wavetossed@googlemail.com] Sent: Saturday, April 03, 2010 1:07 PM To: Larry Sheldon Cc: nanog@nanog.org Subject: Re: legacy /8

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 ------------------------------ Message: 4 Date: Sat, 3 Apr 2010 16:30:32 -0500 From: "Frank Bulk" <frnkblk@iname.com> Subject: RE: legacy /8 To: "'James Hess'" <mysidia@gmail.com>, "George Bonser" <gbonser@seven.com>, <nanog@nanog.org> Message-ID: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAADkiLCe9o7+RLmWUhTYga4rAQAAAAA=@iname.com> Content-Type: text/plain; charset="us-ascii" If Google made the same strong statement with IPv6 as they have done with their 700 MHz bid or the Google-subsidized fiber project, it could make a significant difference. A few examples come to mind: - free or discounted advertising to vendors if delivered over IPv6: this would incent advertisers to have viewers access content over IPv6, even if it was just on mobile phones with certain apps. - free or discounted Google Apps if a certain percentage of client access was over IPv6, etc: this would incent enterprises (the non-profits are either free or discounted, so this example applies mostly to the for-profits) to find native IPv6 access because it provides an immediate and direct savings Frank -----Original Message----- From: James Hess [mailto:mysidia@gmail.com] Sent: Saturday, April 03, 2010 1:08 PM To: George Bonser Cc: nanog@nanog.org Subject: Re: legacy /8 <snip> I suppose if Google announced tomorrow, that search engine access over IPv4 is going to be discontinued in 12 months, and you will have to connect using IPv6, then IPv4 might become legacy....... They could have posted that on April 1, with impunity too :) Enterprises may take a long time to move, there are so many participants involved, it is difficult to fathom them all acting at once, at least, until some major content providers, major search engines, etc, announce they will _stop_ providing services over V4. <snip> -- -J ------------------------------ Message: 5 Date: Sat, 3 Apr 2010 11:35:56 -1000 From: David Conrad <drc@virtualized.org> Subject: Re: legacy /8 To: frnkblk@iname.com Cc: nanog@nanog.org Message-ID: <FB728DBD-E36B-46A5-B0E2-BADB65A8E23B@virtualized.org> Content-Type: text/plain; charset=us-ascii 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 ------------------------------ Message: 6 Date: Sat, 03 Apr 2010 14:49:57 -0700 From: Zaid Ali <zaid@zaidali.com> Subject: Re: legacy /8 To: <frnkblk@iname.com>, <nanog@nanog.org> Message-ID: <C7DD0615.2C578%zaid@zaidali.com> Content-Type: text/plain; charset="ISO-8859-1" 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. I feel talking to network operators is preaching to the choir, the challenge is helping content providers think about moving to IPv6. <Sarcasm>I think we will only see success once we are able to successfully work with content providers but they are quite busy now building real technology like the "Cloud" </Sarcasm> Zaid On 4/3/10 2:22 PM, "Frank Bulk" <frnkblk@iname.com> 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?

Frank

-----Original Message----- From: Michael Dillon [mailto:wavetossed@googlemail.com] Sent: Saturday, April 03, 2010 1:07 PM To: Larry Sheldon Cc: nanog@nanog.org Subject: Re: legacy /8

...

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

------------------------------ Message: 7 Date: Sun, 4 Apr 2010 10:45:00 +0930 From: Mark Smith <nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> Subject: Re: legacy /8 To: "George Bonser" <gbonser@seven.com> Cc: nanog@nanog.org Message-ID: <20100404104500.1c7b6d49@opy.nosense.org> Content-Type: text/plain; charset=US-ASCII 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.

------------------------------ Message: 8 Date: Sun, 4 Apr 2010 10:46:14 +0930 From: Mark Smith <nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> Subject: Fw: legacy /8 To: NANOG List <nanog@nanog.org> Message-ID: <20100404104614.6bff3a1a@opy.nosense.org> Content-Type: text/plain; charset="us-ascii" Hi, Vint Cerf kindly sent through some more explanation. Regards, Mark. Begin forwarded message: Date: Sat, 3 Apr 2010 08:17:28 -0400 From: Vint Cerf <vint@google.com> To: Mark Smith <nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> Cc: Andrew Gray <3356@blargh.com>, NANOG List <nanog@nanog.org> Subject: Re: legacy /8 When the Internet design work began, there were only a few fairly large networks around. ARPANET was one. The Packet Radio and Packet Satellite networks were still largely nascent. Ethernet had been implemented in one place: Xerox PARC. We had no way to know whether the Internet idea was going to work. We knew that the NCP protocol was inadequate for lossy network operation (think: PRNET and Ethernet in particular). This was a RESEARCH project. We assumed that national scale networks were expensive so there would not be too many of them. And we certainly did not think there would be many built for a proof of concept. So 8 bits seemed reasonable. Later, with local networks becoming popular, we shifted to the class A-D address structure and when class B was near exhaustion, the NSFNET team (I think specifically Hans-Werner Braun but perhaps others also) came up with CIDR and the use of masks to indicate the size of the "network" part of the 32 bit address structure. By 1990 (7 years after the operational start of the Internet and 17 years since its basic design), it seemed clear that the 32 bit space would be exhausted and the long debate about IPng that became IPv6 began. CIDR slowed the rate of consumption through more efficient allocation of network addresses but now, in 2010, we face imminent exhaustion of the 32 bit structure and must move to IPv6. Part of the reason for not changing to a larger address space sooner had to do with the fact that there were a fairly large number of operating systems in use and every one of them would have had to be modified to run a new TCP and IP protocol. So the "hacks" seemed the more convenient alternative. There had been debates during the 1976 year about address size and proposals ranged from 32 to 128 bit to variable length address structures. No convergence appeared and, as the program manager at DARPA, I felt it necessary to simply declare a choice. At the time (1977), it seemed to me wasteful to select 128 bits and variable length address structures led to a lot of processing overhead per packet to find the various fields of the IP packet format. So I chose 32 bits. vint On Fri, Apr 2, 2010 at 10:42 PM, Mark Smith < nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> wrote:

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.