NANOG Digest, Vol 27, Issue 25
Russell Berg
berg at wins.net
Mon Apr 5 13:37:43 UTC 2010
"nanog-request at nanog.org" <nanog-request at nanog.org> wrote:
Send NANOG mailing list submissions to
nanog at 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 at nanog.org
You can reach the person managing the list at
nanog-owner at 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 at seven.com>
Subject: RE: legacy /8
To: <marka at isc.org>
Cc: nanog at nanog.org
Message-ID:
<5A6D953473350C4B9995546AFE9939EE08FE6C76 at RWC-EX1.corp.seven.com>
Content-Type: text/plain; charset="us-ascii"
> -----Original Message-----
> From: marka at isc.org [mailto:marka at isc.org]
> Sent: Saturday, April 03, 2010 11:42 AM
> To: George Bonser
> Cc: Larry Sheldon; nanog at 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 at psg.com>
Subject: Re: legacy /8
To: George Bonser <gbonser at seven.com>
Cc: North American Network Operators Group <nanog at nanog.org>
Message-ID: <m2hbnsjmt1.wl%randy at 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 at iname.com>
Subject: RE: legacy /8
To: <nanog at 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 at googlemail.com]
Sent: Saturday, April 03, 2010 1:07 PM
To: Larry Sheldon
Cc: nanog at 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 at iname.com>
Subject: RE: legacy /8
To: "'James Hess'" <mysidia at gmail.com>, "George Bonser"
<gbonser at seven.com>, <nanog at 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 at gmail.com]
Sent: Saturday, April 03, 2010 1:08 PM
To: George Bonser
Cc: nanog at 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 at virtualized.org>
Subject: Re: legacy /8
To: frnkblk at iname.com
Cc: nanog at nanog.org
Message-ID: <FB728DBD-E36B-46A5-B0E2-BADB65A8E23B at 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 at zaidali.com>
Subject: Re: legacy /8
To: <frnkblk at iname.com>, <nanog at nanog.org>
Message-ID: <C7DD0615.2C578%zaid at 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 at 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 at googlemail.com]
> Sent: Saturday, April 03, 2010 1:07 PM
> To: Larry Sheldon
> Cc: nanog at 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 at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org>
Subject: Re: legacy /8
To: "George Bonser" <gbonser at seven.com>
Cc: nanog at nanog.org
Message-ID: <20100404104500.1c7b6d49 at opy.nosense.org>
Content-Type: text/plain; charset=US-ASCII
On Sat, 3 Apr 2010 11:25:48 -0700
"George Bonser" <gbonser at seven.com> wrote:
>
>
> > -----Original Message-----
> > From: Larry Sheldon [mailto:LarrySheldon at cox.net]
> > Sent: Saturday, April 03, 2010 10:54 AM
> > Cc: nanog at 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 at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org>
Subject: Fw: legacy /8
To: NANOG List <nanog at nanog.org>
Message-ID: <20100404104614.6bff3a1a at 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 at google.com>
To: Mark Smith
<nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> Cc: Andrew
Gray <3356 at blargh.com>, NANOG List <nanog at 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 at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> wrote:
> On Fri, 02 Apr 2010 15:38:26 -0700
> Andrew Gray <3356 at 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.
>
>
-------------- next part --------------
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
<[1]nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> wrote:
On Fri, 02 Apr 2010 15:38:26 -0700
Andrew Gray <[2]3356 at 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.
References
1. mailto:nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org
2. mailto:3356 at blargh.com
------------------------------
_______________________________________________
NANOG mailing list
NANOG at nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog
End of NANOG Digest, Vol 27, Issue 25
*************************************
More information about the NANOG
mailing list