Op 3-10-2012 18:33, Kevin Broderick schreef:

I'll add that in the mid-90's, in a University Of Washington lecture hall, Vint Cerf expressed some regret over going with 32 bits. Chuckle worthy and at the time, and a fond memory - K

"Pick a number between this and that." It's the 80's and you can still count the computers in the world. :) It is/was a "experiment" and you have the choice between a really large and a larger number. Humans are not too good in comparing really large numbers. If it was ever decided to use a smaller value, for the size of the experiment it might have went quite different. The "safe" (larger) choice ended up bringing more pain. As a time honored ritual, the temporary solution becomes the production solution. Oops... And that was not quite what Mr Cerf meant to do. Regards, Seth

On Wed, Oct 3, 2012 at 12:22 PM, Izaac <izaac@setec.org> wrote:

On Wed, Oct 03, 2012 at 06:52:57PM +0200, Seth Mos wrote:

...

"Pick a number between this and that." It's the 80's and you can still count the computers in the world. :)

And yet, almost concurrently, IEEE 802 went with forty-eight bits. Go figure. I'm pretty sure the explanation you're looking for is: It was with the word size of the most popular minis and micros at the time.

The 48 bit MAC was 1980; notable that it was not primarily handled in software / CPUs (ethernet key functionality is in dedicated interface hardware, though the stack is MAC-aware obviously). CPU register bit length is less critical when you have a dedicated controller of arbitrary bittedness handling MACs. -- -george william herbert george.herbert@gmail.com

On Oct 3, 2012, at 12:22 PM, Izaac <izaac@setec.org> wrote:

On Wed, Oct 03, 2012 at 06:52:57PM +0200, Seth Mos wrote:

...

"Pick a number between this and that." It's the 80's and you can still count the computers in the world. :)

And yet, almost concurrently, IEEE 802 went with forty-eight bits. Go figure. I'm pretty sure the explanation you're looking for is: It was with the word size of the most popular minis and micros at the time.

IEEE 802 was expected to provide unique numbers for all computers ever built. Internet was expected to provide unique numbers for all computers actively on the network. Obviously, over time, the latter would be a declining percentage of the former since the former is increasing and never decrements while the latter could (theoretically) have a growth rate on either side of zero and certainly has some decrements even if the increments exceed the decrements. Owen

On 10/4/12 1:31 AM, Marco Hogewoning wrote:

On Oct 4, 2012, at 12:21 AM, Owen DeLong wrote:

...

IEEE 802 was expected to provide unique numbers for all computers ever built.

Internet was expected to provide unique numbers for all computers actively on the network.

Obviously, over time, the latter would be a declining percentage of the former since the former is increasing and never decrements while the latter could (theoretically) have a growth rate on either side of zero and certainly has some decrements even if the increments exceed the decrements. Which brings the question, are we expected to ever run out of the 48 bits for mac-addresses? Of course there are exceptions, but in most cases you can probably start recycling them after a certain period. And that period could even become shorter over time, I mean what are the chances you find a iPhone 1 in your network these days?

The IEEE/RAC regards the consistent enforcement of these restrictions as a fundamental and realistic basis for ensuring longevity of the EUI-48 identifier capability, with a target lifetime of 100 years for existing applications using EUI-48 identifiers. http://standards.ieee.org/develop/regauth/tut/eui.pdf

Marco

On 10/03/2012 09:52 AM, Seth Mos wrote:

Op 3-10-2012 18:33, Kevin Broderick schreef:

...

I'll add that in the mid-90's, in a University Of Washington lecture hall, Vint Cerf expressed some regret over going with 32 bits. Chuckle worthy and at the time, and a fond memory - K

"Pick a number between this and that." It's the 80's and you can still count the computers in the world. :)

Oops... And that was not quite what Mr Cerf meant to do.

I finally got around to finding a reply Vint Cerf wrote to a thread I started a year or two ago. The url is http://mailman.nanog.org/pipermail/nanog/2010-April/020488.html and quoted below in full for future prosperity. This gives a great behind the scenes view and a clear idea on the thought processes involved and why things evolved the way they did. Interestingly ipv6 is 128 bits, and I personally would have loved to see variable length address structures being implemented, alas. Maybe when ipv6 is in need of replacement... * Begin quote * 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 * end quote * -- Earthquake Magnitude: 4.7 Date: Monday, October 29, 2012 23:51:42 UTC Location: Flores region, Indonesia Latitude: -8.1762; Longitude: 123.4122 Depth: 19.60 km

On Wed, Oct 3, 2012 at 12:11 PM, Tony Hain <alh-ietf@tndh.net> wrote:

...

Sadiq Saif [mailto:sadiq@asininetech.com] wrote:

On Wed, Oct 3, 2012 at 12:13 PM, Chris Campbell <chris@ctcampbell.com> wrote:

...

Is anyone aware of any historical documentation relating to the choice of 32 bits for an IPv4 address?

Cheers.

I believe the relevant RFC is RFC 791 - https://tools.ietf.org/html/rfc791

Actually that was preceded by RFC 760, which in turn was a derivative of IEN 123. I believe the answer to the original question is partially available on a series of pages starting at : http://www.networksorcery.com/enp/default1101.htm IEN 2 is likely to be of particular interest ...

It's worthwhile noting that the state of system (mini and microcomputer) art at the time of the 1977 discussions was, for example, the Intel 8085 (8-bit registers; the 16-bit 8086 was 1978) and 16-bit PDP-11s. The 32-bit VAX 11/780 postdated these (announced October 77). Yes, you can do 32 or 64 bit network addressing with smaller registers, but there are tendencies to not think that way. -- -george william herbert george.herbert@gmail.com

On Wed, 03 Oct 2012 15:44:16 -0400, "Tony Patti" said:

Perhaps worth noting (for the archives) that a significant part of the early ARPAnet was DECsystem-10's with 36-bit words.

And the -10s and -20s were the major reason RFCs refer to octets rather than bytes, as they had a rather slippery notion of "byte" (anywhere from 6 to 9 bits, often multiple sizes used *in the same program*).

----- Original Message -----

From: "Dave Crocker" <dhc2@dcrocker.net>

My theory is that there is a meta-rule to make new address spaces have 4 times as many bits as the previous generation.

We have three data points to establish this for the Internet, and that's the minimum needed to run a correlation: Arpanet, IPv4, IPv6...

So the address space for IPv8 will be... </troll> Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274

On Wed, 03 Oct 2012 17:49:56 -0500, Jimmy Hess said:

(1) Stopped mixing the Host identification and the Network identification into the same bit field; instead every packet gets a source network address, destination network address, AND an additional tuple of Source host address, destination host address; residing in completely separate address spaces, with no "Netmasks", "Prefix lengths", or other comingling of network addresses and host address spaces.

Where's Noel Chiappa when you need him?

(2) The new protocol will use variable-length address for the Host portion, such as used in the addresses of CLNP,

This also was considered during the IPv6 design phase, and the router designers had a collective cow, as it makes ASIC design a whole lot more interesting. And back then, line speed was a lot lower than it is now... Not saying it can't be done - but you're basically going to have to do CLNP style handling at 400Gbits or 1Tbit. Better get those ASIC designers a *lot* of caffeine, they're gonna need it...

On Wed, Oct 03, 2012 at 06:59:20PM -0400, Valdis.Kletnieks@vt.edu wrote:

Where's Noel Chiappa when you need him?

...

(2) The new protocol will use variable-length address for the Host portion, such as used in the addresses of CLNP,

This also was considered during the IPv6 design phase, and the router designers had a collective cow, as it makes ASIC design a whole lot more interesting. And back then, line speed was a lot lower than it is now...

Not saying it can't be done - but you're basically going to have to do CLNP style handling at 400Gbits or 1Tbit. Better get those ASIC designers a *lot* of caffeine, they're gonna need it...

Except that these will be pure photonic networks, and apart from optical delay lines for your packet buffer you'd better be able to make a routing (switching) decision while few bits of the header have streamed by your photonic router circuit. There is no time for any table look-ups, obviously. And optical gates are *really* expensive, so better use few of them. And don't add too many gate delays, too. Above describes your setting for the next protocol. There is not a lot of leeway in design space, I'm afraid.

On Thu, Oct 04, 2012 at 05:10:00PM +0900, Masataka Ohta wrote:

...

Above describes your setting for the next protocol. There is not a lot of leeway in design space, I'm afraid.

Just keep using IPv4.

Masataka Ohta PS

See ftp://chacha.hpcl.titech.ac.jp/IEEE-ST.ppt presented at a summer topical of IEEE photonic society.

Thanks for the Powerpoint, I've already seen it or an earlier version of it. My (minor) beef with it is that while you offload most of heavy lifting to photonics you still use electronics and lookup. It is however reasonably easy to do everything at effectively L2 with a photonic crossbar if you encode geography in the headers (you have a direct proximity metric on your link slots). (You can actually prototype this with Ethernet MACs, as 2^48 in square meters happens to be half the surface area of the Earth http://www.wolframalpha.com/input/?i=2^48+m^2 So MAC collisions are not very probable, if distributed optimally ;) If you do it in optics the protocol is completely different from IPv4/IPv6, so you would encapsulate and use it as a transport layer for legacy (ha!) protocols. P.S. Sorry for shit-stirring (and it ain't even Friday yet). I'll be good now.

In Singapore in June 2011 I gave a talk at HackerSpaceSG about just doing away with IP addresses entirely, and DNS. Why not just use host names directly as addresses? Bits is bits, FQDNs are integers because, um, bits is bits. They're even structured so you can route on the network portion etc. Routers themselves could hash them into some more efficient form for table management but that wouldn't be externally visible. I did suggest a standard for such hashing just to help with debugging etc but it'd only be a suggestion or perhaps common display format. About the only obvious objection, other than vague handwaves about compute efficiency, is it would potentially make packets a lot longer in the worst case scenario, longer than common MTUs tho not much longer unless we also allow a lengthening of host name max, 1024 right now I believe? So 2K max for src/dest and whatever other overhead payload you need, not unthinkable. OTOH, it just does away with DNS entirely which is some sort of savings. There are obviously some more details required, this email is not a replacement for a set of RFCs! -- -Barry Shein The World | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo*

On Thu, Oct 4, 2012 at 4:36 PM, Barry Shein <bzs@world.std.com> wrote:

In Singapore in June 2011 I gave a talk at HackerSpaceSG about just doing away with IP addresses entirely, and DNS.

Why not just use host names directly as addresses? Bits is bits, FQDNs are integers because, um, bits is bits. They're even structured so you can route on the network portion etc.

Routers themselves could hash them into some more efficient form for table management but that wouldn't be externally visible. I did suggest a standard for such hashing just to help with debugging etc but it'd only be a suggestion or perhaps common display format.

About the only obvious objection, other than vague handwaves about compute efficiency, is it would potentially make packets a lot longer in the worst case scenario, longer than common MTUs tho not much longer unless we also allow a lengthening of host name max, 1024 right now I believe? So 2K max for src/dest and whatever other overhead payload you need, not unthinkable.

OTOH, it just does away with DNS entirely which is some sort of savings.

There are obviously some more details required, this email is not a replacement for a set of RFCs!

You'd still need DNS for non-A/PTR types of records. This scheme fails miserably in one practical manner - it's impossible to tell people far away from the source of a DNS / name domain's authority that a.foo.com and b.foo.com are in the UK and c.foo.com and d.foo.com are in Japan. With IP addresses, heirarchical blocks make routing trivial. Name based routing is ... seems hard, or insanely hard for "real complex networks" as opposed to trivial end user types of situations. Possibly unworkably hard. One could rename things such as having a.location.foo.com but you still encounter the problem that you have to propogate knowledge of where location.foo.com is further out into the universe. Nice troll and/or wild-crazy-idea though. -- -george william herbert george.herbert@gmail.com

Don't change anything! That would...change things! Obviously my idea to use the host name directly as a src/dest address rather than convert it to an integer is not a small, incremental change. It's more in the realm of a speculative proposal. But I'm not sure that arguing that our string of bits (e.g., ipv6) is inherently superior to your proposed string of bits (a host name) is an immediately compelling objection. The objection which puzzles me the most is the implication that a numeric address locates a host or network directly or geographically rather than, as I understood it, by the tuple (address,route). Well, geographically? Since when, except at the very end of the routing sequence? "First they ignore you, then they ridicule you, then they fight you, then you win" -- Mahatma Gandhi -- -Barry Shein The World | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo*

My money is on an epic troll. Four out of five network engineers surveyed agree their individual IP headers are best served without condiments. -----Original Message----- From: Jay Ashworth [mailto:jra@baylink.com] Sent: Friday, October 05, 2012 2:06 PM To: NANOG Subject: Re: IPv4 address length technical design ----- Original Message -----

From: "Barry Shein" <bzs@world.std.com>

Don't change anything! That would...change things!

Your man; he is made of straw. :-)

Obviously my idea to use the host name directly as a src/dest address rather than convert it to an integer is not a small, incremental change. It's more in the realm of a speculative proposal.

Speculative is orthogonal to small or incremental; they are different measurement axes. This is also true of the difference between addresses and names. Addresses are an engineering artifact; names are a business/administrative artifact. *The entire point* of DNS vs IP is to uncouple those; necessary changes in the engineering artifact *MUST not* cause changes in the business artifact.

But I'm not sure that arguing that our string of bits (e.g., ipv6) is inherently superior to your proposed string of bits (a host name) is an immediately compelling objection.

And, unsurprisingly, no one made an argument that trivial. To the extent you think we did, I think we were merely giving you the benefit of the doubt of already understanding this dichotomy, which is pretty much Networking 201, and taken as read on NANOG. Extraordinary changes require extraordinary justification.

The objection which puzzles me the most is the implication that a numeric address locates a host or network directly or geographically rather than, as I understood it, by the tuple (address,route).

I didn't see anyone make that implication. Could you quote?

"First they ignore you, then they ridicule you, then they fight you, then you win" -- Mahatma Gandhi

Yeah; that approach didn't work out well for Jim Fleming. :-) Seriously, Barry; my appraisal of this after three decades is that this is first year stuff, and you are not a first year guy, by any stretch. So, is this just the epic troll of the year? Or is there something we're missing? Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274

I had toyed with the idea that maybe we needed an identity based routing system. Addressing doesn't change because it's the physical map of the network. Instead what you need is a set of identity "banking" servers, either arranged by organization or contract, that hold a public key and that your workstations and servers update with their current location. That would be similar to the current DNS infrastructure. When you wish to transact with one of these servers, you use the DNS like identity to retrieve the current location, and send a signed connection request via TCP or UDP. The remote end received an authenticated request that you can confirm using your identity and public key. You don't have to encrypt the contents of the packet, but you could if you needed to. If an address changes, that device could send a signed update indicating the IP change to all currently opened sockets and it's authoritative identity server. I know it's kind of rough, but it would take all this complexity and put it back in the workstation stack. Everybody is lowering their DNS TTL's to nothing anymore to support dynamic DNS. There is a big push to virtualize and fragment the IP address scheme to support IP mobility, which flies in the face of good network management. Not to mention how IP mobility also enables man in the middle to become a serious reality. And all the router vendors are pushing for more features, instead of doing what they are supposed to do better. I think a concept like this could help on several levels. It just seems like something different needs to be done. S - -----Original Message----- From: William Herrin [mailto:bill@herrin.us] Sent: Friday, October 05, 2012 8:07 AM To: Barry Shein Cc: nanog@nanog.org Subject: Re: IPv4 address length technical design On Thu, Oct 4, 2012 at 7:36 PM, Barry Shein <bzs@world.std.com> wrote:

In Singapore in June 2011 I gave a talk at HackerSpaceSG about just doing away with IP addresses entirely, and DNS. About the only obvious objection, other than vague handwaves about compute efficiency, is it would potentially make packets a lot longer

What portion of your audience would you say took it at face value without realizing they'd been trolled? Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004

In article <72A2F9AF18EC024C962A748EA6CF75B90ED2BA40@W8USSFJ204.ams.gblxint.com> you write:

Wouldn't that implicate the routing system to have, in essence, one routing entry for every host on the network?

That would be the moral equivalent to just dropping down to a global ethernet fabric to replace IP and using mac addresses for routing. I'll give you one guess as to how well that would work.

It works well for the 12 computers in my home office. Therefore it's a solved problem and trivial to implement. HTH, HAND, &c. John

On Oct 5, 2012, at 4:34 PM, Barry Shein wrote:

Well, XNS (Xerox Networking System from PARC) used basically MAC addresses. Less a demonstration of success than that it has been tried. But it's where ethernet MAC addresses come from, they're just XNS addresses and maybe this has changed but Xerox used to manage the master 802 OUI list and are assigned OUIs 000000...000009. Not insignificant in their effect.

You need a memory refresh. XNS used a three part address: network number, host identifier, and socket number. "Socket" was in essence the TCP/UDP Port Number. the host identifier was as you say a 48 bit number and generally took as its value the MAC address on one of the interfaces - and the same MAC address was used on all interfaces. Hence, no need for ARP/ND. The network number was a 32 bit number assigned to a LAN subnet. A multihomed host essentially implemented ILNP. The issue with the network number was, of course, that it couldn't be aggregated in any useful way. But XNS was not ethernet bridging on a wide scale.

On Wed, Oct 3, 2012 at 7:12 PM, Cutler James R <james.cutler@consultant.com> wrote:

On Oct 3, 2012, at 6:49 PM, Jimmy Hess <mysidia@gmail.com> wrote:

...

In 100 years, when we start to run out of IPv6 addresses, possibly we will have learned our lesson and done two things:

(1) Stopped mixing the Host identification and the Network identification into the same bit field; instead every packet gets a source network address, destination network address, AND an additional tuple of Source host address, destination host address; residing in completely separate address spaces, with no "Netmasks", "Prefix lengths", or other comingling of network addresses and host address spaces.

And (2) The new protocol will use variable-length address for the Host portion, such as used in the addresses of CLNP, with a convention of a specified length, instead of a hardwired specific limit that comes from using a permanently fixed-width field.

I suggest that the DNS name space should be considered to be an "hierarchical host address space" thus satisfying (1) and making (2) moot.

I'd suggest that too, but we'd have to throw out TCP, UDP and a good chunk of the BSD sockets API to get there. Or did you mean use DNS as it fits in the current system, which doesn't actually satisfy (1) at all since the layer 4 protocols continue to build the connection identity from the layer 3 network identity instead of the external host/service identity. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004

On Thu, Oct 4, 2012 at 4:17 PM, Cutler James R <james.cutler@consultant.com> wrote:

On Oct 4, 2012, at 4:00 PM, William Herrin <bill@herrin.us> wrote:

...

On Wed, Oct 3, 2012 at 7:12 PM, Cutler James R <james.cutler@consultant.com> wrote: Or did you mean use DNS as it fits in the current system, which doesn't actually satisfy (1) at all since the layer 4 protocols continue to build the connection identity from the layer 3 network identity instead of the external host/service identity.

Why does the connection identity have to include the host identifier. Is that not a problem under the control of applications?

Nope. It's under the control of the layer 4 protocol, generally TCP or UDP, and implemented at the OS level. For example, in TCP the connection identity is composed of the source and destination IP addresses and port numbers. Together, these 96 bits of information comprise the unique identity of that TCP connection which the OS matches to the socket number the application interacts with. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004

On Wed, Oct 3, 2012 at 4:15 PM, Owen DeLong <owen@delong.com> wrote:

On Oct 3, 2012, at 3:49 PM, Jimmy Hess <mysidia@gmail.com> wrote:

...

On 10/3/12, Jay Ashworth <jra@baylink.com> wrote:

...

So the address space for IPv8 will be... </troll>

In 100 years, when we start to run out of IPv6 addresses, possibly we will have learned our lesson and done two things:

(1) Stopped mixing the Host identification and the Network identification into the same bit field; instead every packet gets a source network address, destination network address, AND an additional tuple of Source host address, destination host address; residing in completely separate address spaces, with no "Netmasks", "Prefix lengths", or other comingling of network addresses and host address spaces.

Agreed, mostly.

Prefix lengths can still be useful for route summarization and it would be useful to have separate segments of the network address, such as Autonomous System Number, Intra-AS Organizational Identifier, and Intra-Organizational Network, for example. It might be useful to use prefix lengths in those cases to allow for variability in the boundary between these identifiers.

...

And (2) The new protocol will use variable-length address for the Host portion, such as used in the addresses of CLNP, with a convention of a specified length, instead of a hardwired specific limit that comes from using a permanently fixed-width field.

On this, I disagree… Once host identifiers are no longer dependent on or related to topology, there's no reason a reasonable fixed-length cannot suffice.

...

Need more bits? No protocol definition change required.

Nope, just new ASICS everywhere and no clear way to identify where they are or are not deployed and…

A regrettably serious response: There are some fundamental questions about areas of computer usage, engineering, and science that will affect what "the next protocol" should look like. Despite a couple of decades of frenetic work to mobility-ize our protocols, we mostly didn't with IPv6; that may be the norm rather than the design exception by $NEXTPROTOCOL. Quantum computers may, or may not, be relevant to anything (including possibly routing or switching) by $NEXTPROTOCOL days. Supermassive parallelism may be relevant to routing or switching. Moore's Law may peter out at some point with Silicon hitting atom-count limits, or could continue somewhat further with nanowires and graphene and the like, or something else completely could come about. Extremely low cost concerns may collapse the number of physical devices in a computer / computing device, as we have see many cycles of various system controllers or video controllers migrating into CPUs or back out again as performance or chip cost concerns / fab technology pushed the optimization point one way or the other. This could affect switch and router cost optimization as well. We can (probably safely) say that within the next decade there is no sign of a technical or business driver for $NEXTPROTOCOL bubbling over our feet; by the time that it becomes necessary or relevant, all the ASICS we have out there now will be obsolete. Whether they're just faster smaller ASICS or some form of interface we cannot currently accurately predict, I have no idea, but I would rather not limit our conceptualization of 20-100 year timeframe solutions to "Today, but faster". If we go back to 1992, it is almost completely an accident that winning technologies in many areas today are still recognizable to the computer people of that era. -- -george william herbert george.herbert@gmail.com

On Oct 4, 2012, at 11:19 AM, Tony Finch <dot@dotat.at> wrote:

Owen DeLong <owen@delong.com> wrote:

...

Once host identifiers are no longer dependent on or related to topology, there's no reason a reasonable fixed-length cannot suffice.

Host identities should be cryptographic hashes of public keys, so you have to support algorithm agility, which probably implies variable length.

No, they really shouldn't, but I understand why some security zealots think that's a good idea. Owen

On Oct 3, 2012, at 4:17 PM, Dave Crocker <dhc2@dcrocker.net> wrote:

...

...

...

Is anyone aware of any historical documentation relating to the choice of 32 bits for an IPv4 address? ... Actually that was preceded by RFC 760, which in turn was a derivative of IEN 123. I believe the answer to the original question is ...

My theory is that there is a meta-rule to make new address spaces have 4 times as many bits as the previous generation.

We have three data points to establish this for the Internet, and that's the minimum needed to run a correlation: Arpanet, IPv4, IPv6...

d/

Didn't work for DecNet Phase III, Decnet Phase IV, Decnet Phase V (8, 16, 128).