Re: IPv4 address length technical design

[Jeroen van Aart]

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 
To: Mark Smith
 Cc: Andrew
Gray <3356 at blargh.com>, NANOG List  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

RE: IPv4 address length technical design

[Siegel, David]

I'll identify myself as the person who asked you the question privately.

Unfortunately, Barry, I still don't see a problem statement in your response.  
It sounds to me as though it really is nothing more than an interesting thought 
experiment, and there's nothing wrong with that at all as long as we all 
acknowledge the purpose of the discussion.  :-)

Dave


-Original Message-
From: Barry Shein [mailto:b...@world.std.com] 
Sent: Friday, October 05, 2012 6:25 PM
To: nanog@nanog.org
Cc: Barry Shein
Subject: RE: IPv4 address length technical design


 > While this is an interesting thought experiment, what problem are  > you 
 > trying to solve with this proposal?

(asked privately but it seems worthwhile answering publicly, bcc'd, you can id 
yourself if you like.)

Look, as I said in the original message I was asked to speak to a group of 
young "hackers" at the HackerSpace in Singapore.

I wanted to be interesting and thought-provoking, make them think through how 
this stuff works for an hour or two, encourage them to poke holes in it, etc. 
It was one of the audience who pointed out the potential MTU problem.

What problem does it solve, potentially?

0. Despite fears expressed herein I am not single-handedly planning to convert 
the worldwide internet to this over the weekend. I'm going to need some help :-)

1. It eliminates the need for DNS in its generally used form.

Sure, we've overloaded DNS with other functions from SPF -- in fact it was Meng 
Weng Wong, inventor of SPF, who graciously invited me to speak -- to whatever. 
But that's begging the point, there's nothing interesting here about 
distributed, lightweight databases other than eliminating one. Keep the DNS 
protocol per se for those things if you like.

But given this you won't need to translate between host names and addresses 
which is really what DNS was invented to do.

2. It makes "addresses" more transparent to humans, particularly when you 
consider ipv6 addresses as typically displayed (hex.) Is this an important 
goal? Not sure, but it's certainly true.

3. It's a transfinite space.

That just means that like Dewey Decimal etc it can be arbitrarily expanded, you 
can add more levels or even stick levels in between plus or minus some rules 
regarding SLDs/TLDs, and other rules which might or might not be imposed (see 
#4).

But its total address space is as large as you allow a payload, there is 
nothing inherent in the scheme that limits the addressing other than the 
permutation of all acceptable Unicode glyphs I guess. But since one can also 
have numeric parts and the set of integers is infinite (that's tongue-in-cheek, 
somewhat.)

4. Also, because it's transfinite it's arbitrarily segmentable.

Again, that just means you can impose any meaning you like on any substring or 
set of substrings. So for example host.gTLD is generally taken to be something 
of some significance, or host.co.ccTLD, and that sort of idea can be applied as 
needed, or not at all.

5. Bits is bits.

I don't know how to say that more clearly.

An ipv6 address is a string of 128 bits with some segmentation implications 
(net part, host part.)

A host name is a string of bits of varying length. But it's still just ones and 
zeros, an integer, however you want to read it.

The discussion I was responding to on NANOG involved how we got here and where 
might we be going.

I brought up an idea I'd worked out somewhat and have even presented in a small 
but public forum as being a possible future to consider further.

Now you can go back to your regularly scheduled Jim Fleming guffawing.

-- 
-Barry Shein

The World  | b...@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*

Re: IPv4 address length technical design

[Tony Finch]

On 6 Oct 2012, at 02:11, Michael Thomas  wrote:
> 
> Wasn't David Cheriton proposing something like this?
> 
> http://www-dsg.stanford.edu/triad/

CCNx basically routes on URLs

http://conferences.sigcomm.org/co-next/2009/papers/Jacobson.pdf

Tony.
--
f.anthony.n.finchhttp://dotat.at/

Re: IPv4 address length technical design

[Tony Finch]

On 7 Oct 2012, at 18:17, William Herrin  wrote:
> 
> Intentionally crashing the moon into the earth is a new idea. How far
> should we run with it before concluding that it not only isn't a very
> good one, considering it hasn't taught us anything we didn't already
> know?

http://www.xent.com/FoRK-archive/july98/0041.html

Tony.
--
f.anthony.n.finchhttp://dotat.at/

Re: IPv4 address length technical design

[William Herrin]

On Sun, Oct 7, 2012 at 3:52 PM, Barry Shein  wrote:
> Ok, then let's take a step back, perhaps not permanently, and say DNS
> resolution is only really useful for routers with more than just a
> single default external route.
>
> So DNS could be reduced to an inter-router only protocol, similar to
> BGP in some sense.

There's no party in the neighborhood you're searching. Turn it upside
down, on the other hand, and you end up somewhere like TRRP.
http://bill.herrin.us/network/trrp.html

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: IPv4 address length technical design

[Jay Ashworth]

- Original Message -
> From: "Barry Shein" 

> Well, George, you can take a new idea and run with it a bit, or just
> resist it right from the start.
> 
> We can map from host names to ip addresses to routing actions, right?
> 
> So clearly they're not unrelated or independent variables. There's a
> smooth function from hostname->ipaddr->routing.

Ah.  *This* is where you fell off the horse. 

Nope; the first one isn't smooth; it's *completely arbitrary*.

The mapping is, in fact, DNS's raison d'etre.

The second one has a relatively smooth mapping *at any given point in time*,
but you can't fit a function to that; it is prone also to arbitrary changes 
over time.

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@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

RE: IPv4 address length technical design

[Paul Vinciguerra]

> 
> Ok, then let's take a step back, perhaps not permanently, and say DNS 
> resolution is only really useful for routers with more than just a 
> single default external route.
> 
> So DNS could be reduced to an inter-router only protocol, similar to 
> BGP in some sense.

LISP DDT uses a lookup to determine EID location.

We operate one of the DDT roots, and yes the difference is that LISP uses an 
on-demand pull mechanism, where the route is looked up and then cached until it 
ages out from inactivity.  BGP pushes every route to peers and everyone running 
BGP pays a hardware tax for carrying each and every route. (See Bill Herrin's 
work at http://bill.herrin.us/network/bgpcost.html)   DDT provides a scalable, 
distributed database similar to DNS for looking up prefixes in LISP mapping 
servers.

Re: IPv4 address length technical design

[Steven Noble]

On Oct 7, 2012, at 12:52 PM, Barry Shein  wrote:

> 
> Ok, then let's take a step back, perhaps not permanently, and say DNS
> resolution is only really useful for routers with more than just a
> single default external route.
> 
> So DNS could be reduced to an inter-router only protocol, similar to
> BGP in some sense.

LISP DDT uses a lookup to determine EID location.

Re: names are not numbers, was IPv4 address length technical design

[Barry Shein]

Back in the 80s when DNS was a fairly new idea and things like Google
were way in the future I remember suggesting on the TCP-IP list that
people grab a phone number they owned as a domain name and add
first_last as a mailbox so we could leverage the international phone
directory system to find each other.

For example something like barry_sh...@0016176403067.com (maybe insert
a letter, all-digits wasn't allowed back then.)

I guess that sort of idea was eventually incorporated into telephone
number mapping but not clear how successful that is or if the intent
is really the same. I think there were other analogues?


  http://en.wikipedia.org/wiki/Telephone_number_mapping

But the idea has come up.

-- 
-Barry Shein

The World  | b...@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*

Re: IPv4 address length technical design

[Barry Shein]

Ok, then let's take a step back, perhaps not permanently, and say DNS
resolution is only really useful for routers with more than just a
single default external route.

So DNS could be reduced to an inter-router only protocol, similar to
BGP in some sense.

I suppose one question is how do we discover non-existant hostnames
but we have strong analogues to that at the ICMP level already, host
unreachable etc, just another kind of error feedback. But I'll agree
that begs some thought.


As I said, the proposal was originally offered by me to a bunch of
young "hackers" in Singapore for the purpose of stimulating
discussion.

-- 
-Barry Shein

The World  | b...@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*

Re: IPv4 address length technical design

[William Herrin]

On Sat, Oct 6, 2012 at 1:47 PM, Barry Shein  wrote:
> It's occured to you that FQDNs contain some structured information,
> no?

It has occurred to me that the name on my shirt's tag contains some
structured information. That doesn't make it particularly well suited
for use as a computer network routing key. Or suited at all.


On Sat, Oct 6, 2012 at 2:35 PM, Barry Shein  wrote:
> you can take a new idea and run with it a bit, or just
> resist it right from the start.

Intentionally crashing the moon into the earth is a new idea. How far
should we run with it before concluding that it not only isn't a very
good one, considering it hasn't taught us anything we didn't already
know?


> Van Jacobson had a similar observation vis a vis TCP and PPP header
> compression, why keep sending the same bits back and forth over a PPP
> link for example? Why not just an encapsulation which says "same as
> previous"?
>
> Now, how can that be generalized?

By observing that within a restricted subset of a problem domain there
may be usable techniques that aren't portable to the broader problem
domain. This is not news, and your comments have not bounded a subset
of the routing problem domain in a way that would make a discussion of
names as routing keys interesting.

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: IPv4 address length technical design

[George Herbert]

On Oct 6, 2012, at 11:35 AM, Barry Shein  wrote:

> 
> We can map from host names to ip addresses to routing actions, right?
> 
> So clearly they're not unrelated or independent variables. There's a
> smooth function from hostname->ipaddr->routing.

No.

Not just no, but hell no at the asserted communativity there, Barry.

That's not even Wrong...

And that's the point.

DNS to IP is in no way a smooth function.  Hell no, for many networks.  It's 
only true for the boringest customers.  Try actual enterprise endpoints, or 
service providers.

IP to Routing is not smooth at predictable scales.  Yes, it's in blocks, but a 
top-down view is at best fractal discontinuity.

IP to routing is smoother in IPv6 but as routing has two components - physical 
location and net path - was made smoother in one only ( net path, and to the 
degree that's smooth in physical location by accident...).


George William Herbert
Sent from my iPhone

Re: names are not numbers, was IPv4 address length technical design

[Joe Hamelin]

On Sat, Oct 6, 2012 at 6:14 PM, John Levine  wrote:
>
>
> Hey, I've got a great idea.  Let's lose this silly phone number
> portability nonsense and use phone numbers as routes.
>

You do not want to go down the hell hole that is SS7.

--
Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474

Re: names are not numbers, was IPv4 address length technical design

[John Levine]

In article <20592.28334.622769.539...@world.std.com> you write:
>It's occured to you that FQDNs contain some structured information,
>no?

Hey, I've got a great idea.  Let's lose this silly phone number
portability nonsense and use phone numbers as routes.

I mean, anyone who moves and takes his cell phone with him has
only himself to blame, right?

R's,
John

Re: IPv4 address length technical design

[Cutler James R]

On Oct 6, 2012, at 2:35 PM, Barry Shein  wrote, in part:
> 
> We can map from host names to ip addresses to routing actions, right?
> 
> So clearly they're not unrelated or independent variables. There's a
> smooth function from hostname->ipaddr->routing.

I would suggest that this is a bit optimistic and oversimplified.  

The mapping between DNS names and IP addresses is not necessarily unique or 
commutative. One may change either arbitrarily, as long some "directory 
service" exists which contains the current mapping.  In addition, multiple DNS 
names may map to one or more IP addresses and IP addresses do not necessarily 
map to unique routes or DNS names. These are not smooth functions.

If names and addresses are not independent, then any change in either would 
predicate a change in the another.  That is apparently not the experience of 
most network providers.  The only action required for a change in network name 
or address is to update the "directory service" used to map between name and 
address.

> Is this a good use of DNS computrons? Answering DNS inquiries for
> every new connection for every single-routed host on the internet?

Yes, it is.  Most "new" connections are repeats of previous connections (I 
request mail from my IMAP servers several times each day) and the preponderance 
of caching resolvers make the effort and traffic trivial. Even in the absence 
of cached final DNS reply, putting the lookup burden on the end system rather 
than the "routing engines" should be a no-brainer.

In particular, adding caching of connection destinations within routing 
components would not only seriously burden (read, slow down) routing engines 
but is also a violation of the Stupid Network.  David S Isenberg said, "In a 
Stupid Network, control passes from the center to the edge".  See 
http://www.isen.com/papers/Dawnstupid.html, originally published as the cover 
story of ACM Networker 2.1, February/March 1998, pp. 24-31. 

RE: IPv4 address length technical design

[nanog]

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:j...@baylink.com] 
Sent: Friday, October 05, 2012 2:06 PM
To: NANOG
Subject: Re: IPv4 address length technical design

- Original Message -
> From: "Barry Shein" 

> 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
j...@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

Re: IPv4 address length technical design

[Barry Shein]

Well, George, you can take a new idea and run with it a bit, or just
resist it right from the start.

We can map from host names to ip addresses to routing actions, right?

So clearly they're not unrelated or independent variables. There's a
smooth function from hostname->ipaddr->routing.

Take an extreme but extremely common case, the home or small office
end user.

Those packets only have exactly one place to go, right? One default
route.

So why do they need to turn a host name into an IP address at all to
ship a packet? The first-hop route is always exactly the same for
every single packet.

Is this a good use of DNS computrons? Answering DNS inquiries for
every new connection for every single-routed host on the internet?

Van Jacobson had a similar observation vis a vis TCP and PPP header
compression, why keep sending the same bits back and forth over a PPP
link for example? Why not just an encapsulation which says "same as
previous"?

Now, how can that be generalized?

   -b

On October 6, 2012 at 11:06 george.herb...@gmail.com (George Herbert) wrote:
 > As I said earlier, names' structure does not map to network or physical 
 > location structure.
 > 
 > DNS is who; IP is where.  Both are reasonably efficient now as separate 
 > entities.  Combining them will wreck one.  You're choosing to wreck routing 
 > (where), which to backbone people sounds frankly stark raving mad.
 > 
 > If you aren't willing to consider where / routing as a problem of equal 
 > importance ( not as end-user visible perhaps, but ultimately as important ), 
 > then you're just pissing around and not being serious about exploring future 
 > options.
 > 
 > 
 > 
 > George William Herbert
 > Sent from my iPhone
 > 
 > On Oct 6, 2012, at 10:47 AM, Barry Shein  wrote:
 > 
 > > 
 > > It's occured to you that FQDNs contain some structured information,
 > > no?
 > > 
 > >   -b
 > > 
 > > On October 5, 2012 at 21:47 b...@herrin.us (William Herrin) wrote:
 > >> On Fri, Oct 5, 2012 at 8:25 PM, Barry Shein  wrote:
 > >>> 5. Bits is bits.
 > >>> I don't know how to say that more clearly.
 > >> 
 > >> Hi Barry,
 > >> 
 > >> Bits is bits and atoms is atoms so lets swap all the iron for helium
 > >> and see how that works out for us.
 > >> 
 > >> You can say "bits as bits" as clearly as you like but however you say
 > >> it you'll be wrong. Bits are defined by the semantics of their use.
 > >> Any equality or inequality between one bit and another, and in fact
 > >> whether they can be meaningfully compared at all, is found in those
 > >> semantics.
 > >> 
 > >> Bits ain't just bits. Bits are information *in context.* Change the
 > >> context, change the bits.
 > >> 
 > >> Regards,
 > >> Bill Herrin
 > >> 
 > >> 
 > >> -- 
 > >> William D. Herrin  her...@dirtside.com  b...@herrin.us
 > >> 3005 Crane Dr. .. Web: 
 > >> Falls Church, VA 22042-3004
 > > 

-- 
-Barry Shein

The World  | b...@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*

Re: IPv4 address length technical design

[George Herbert]

As I said earlier, names' structure does not map to network or physical 
location structure.

DNS is who; IP is where.  Both are reasonably efficient now as separate 
entities.  Combining them will wreck one.  You're choosing to wreck routing 
(where), which to backbone people sounds frankly stark raving mad.

If you aren't willing to consider where / routing as a problem of equal 
importance ( not as end-user visible perhaps, but ultimately as important ), 
then you're just pissing around and not being serious about exploring future 
options.



George William Herbert
Sent from my iPhone

On Oct 6, 2012, at 10:47 AM, Barry Shein  wrote:

> 
> It's occured to you that FQDNs contain some structured information,
> no?
> 
>   -b
> 
> On October 5, 2012 at 21:47 b...@herrin.us (William Herrin) wrote:
>> On Fri, Oct 5, 2012 at 8:25 PM, Barry Shein  wrote:
>>> 5. Bits is bits.
>>> I don't know how to say that more clearly.
>> 
>> Hi Barry,
>> 
>> Bits is bits and atoms is atoms so lets swap all the iron for helium
>> and see how that works out for us.
>> 
>> You can say "bits as bits" as clearly as you like but however you say
>> it you'll be wrong. Bits are defined by the semantics of their use.
>> Any equality or inequality between one bit and another, and in fact
>> whether they can be meaningfully compared at all, is found in those
>> semantics.
>> 
>> Bits ain't just bits. Bits are information *in context.* Change the
>> context, change the bits.
>> 
>> Regards,
>> Bill Herrin
>> 
>> 
>> -- 
>> William D. Herrin  her...@dirtside.com  b...@herrin.us
>> 3005 Crane Dr. .. Web: 
>> Falls Church, VA 22042-3004
> 

Re: IPv4 address length technical design

[Barry Shein]

It's occured to you that FQDNs contain some structured information,
no?

   -b

On October 5, 2012 at 21:47 b...@herrin.us (William Herrin) wrote:
 > On Fri, Oct 5, 2012 at 8:25 PM, Barry Shein  wrote:
 > > 5. Bits is bits.
 > > I don't know how to say that more clearly.
 > 
 > Hi Barry,
 > 
 > Bits is bits and atoms is atoms so lets swap all the iron for helium
 > and see how that works out for us.
 > 
 > You can say "bits as bits" as clearly as you like but however you say
 > it you'll be wrong. Bits are defined by the semantics of their use.
 > Any equality or inequality between one bit and another, and in fact
 > whether they can be meaningfully compared at all, is found in those
 > semantics.
 > 
 > Bits ain't just bits. Bits are information *in context.* Change the
 > context, change the bits.
 > 
 > Regards,
 > Bill Herrin
 > 
 > 
 > -- 
 > William D. Herrin  her...@dirtside.com  b...@herrin.us
 > 3005 Crane Dr. .. Web: 
 > Falls Church, VA 22042-3004

Re: IPv4 address length technical design

[David Miller]

On 10/5/2012 9:11 PM, Michael Thomas wrote:
> On 10/05/2012 05:25 PM, Barry Shein wrote:
>> 5. Bits is bits.
>>
>> I don't know how to say that more clearly.
>>
>> An ipv6 address is a string of 128 bits with some segmentation
>> implications (net part, host part.)
>>
>> A host name is a string of bits of varying length. But it's still just
>> ones and zeros, an integer, however you want to read it.
> 
> Wasn't David Cheriton proposing something like this?
> 
> http://www-dsg.stanford.edu/triad/
> 
> Mike

Not exactly. TRIAD is a proposal for distributing content names using a
new routing protocol (in addition to existing routing protocols instead
of as a replacement for existing routing protocols) such that one could
"Route a content request, based on its name, toward the closest server
for that name."(1)

The actual forwarding of packets/requests would continue to use IP.

TRIAD addresses issues with namespace size using Explicit Aggregation
into collections. (2)

-DMM

1. http://www-dsg.stanford.edu/slides/triad-content-netseminar/img15.htm
2.
http://gregorio.stanford.edu/papers/contentrouting/node9.html#SECTION00041000

Re: IPv4 address length technical design

[William Herrin]

On Fri, Oct 5, 2012 at 8:25 PM, Barry Shein  wrote:
> 5. Bits is bits.
> I don't know how to say that more clearly.

Hi Barry,

Bits is bits and atoms is atoms so lets swap all the iron for helium
and see how that works out for us.

You can say "bits as bits" as clearly as you like but however you say
it you'll be wrong. Bits are defined by the semantics of their use.
Any equality or inequality between one bit and another, and in fact
whether they can be meaningfully compared at all, is found in those
semantics.

Bits ain't just bits. Bits are information *in context.* Change the
context, change the bits.

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: IPv4 address length technical design

[Michael Thomas]

On 10/05/2012 05:25 PM, Barry Shein wrote:

5. Bits is bits.

I don't know how to say that more clearly.

An ipv6 address is a string of 128 bits with some segmentation
implications (net part, host part.)

A host name is a string of bits of varying length. But it's still just
ones and zeros, an integer, however you want to read it.


Wasn't David Cheriton proposing something like this?

http://www-dsg.stanford.edu/triad/

Mike

Re: IPv4 address length technical design

[Fred Baker (fred)]

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 00...09. 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.

RE: IPv4 address length technical design

[Barry Shein]

 > While this is an interesting thought experiment, what problem are
 > you trying to solve with this proposal?

(asked privately but it seems worthwhile answering publicly, bcc'd,
you can id yourself if you like.)

Look, as I said in the original message I was asked to speak to a
group of young "hackers" at the HackerSpace in Singapore.

I wanted to be interesting and thought-provoking, make them think
through how this stuff works for an hour or two, encourage them to
poke holes in it, etc. It was one of the audience who pointed out the
potential MTU problem.

What problem does it solve, potentially?

0. Despite fears expressed herein I am not single-handedly planning to
convert the worldwide internet to this over the weekend. I'm going to
need some help :-)

1. It eliminates the need for DNS in its generally used form.

Sure, we've overloaded DNS with other functions from SPF -- in fact it
was Meng Weng Wong, inventor of SPF, who graciously invited me to
speak -- to whatever. But that's begging the point, there's nothing
interesting here about distributed, lightweight databases other than
eliminating one. Keep the DNS protocol per se for those things if you
like.

But given this you won't need to translate between host names and
addresses which is really what DNS was invented to do.

2. It makes "addresses" more transparent to humans, particularly when
you consider ipv6 addresses as typically displayed (hex.) Is this an
important goal? Not sure, but it's certainly true.

3. It's a transfinite space.

That just means that like Dewey Decimal etc it can be arbitrarily
expanded, you can add more levels or even stick levels in between plus
or minus some rules regarding SLDs/TLDs, and other rules which might
or might not be imposed (see #4).

But its total address space is as large as you allow a payload, there
is nothing inherent in the scheme that limits the addressing other
than the permutation of all acceptable Unicode glyphs I guess. But
since one can also have numeric parts and the set of integers is
infinite (that's tongue-in-cheek, somewhat.)

4. Also, because it's transfinite it's arbitrarily segmentable.

Again, that just means you can impose any meaning you like on any
substring or set of substrings. So for example host.gTLD is generally
taken to be something of some significance, or host.co.ccTLD, and that
sort of idea can be applied as needed, or not at all.

5. Bits is bits.

I don't know how to say that more clearly.

An ipv6 address is a string of 128 bits with some segmentation
implications (net part, host part.)

A host name is a string of bits of varying length. But it's still just
ones and zeros, an integer, however you want to read it.

The discussion I was responding to on NANOG involved how we got here
and where might we be going.

I brought up an idea I'd worked out somewhat and have even presented
in a small but public forum as being a possible future to consider
further.

Now you can go back to your regularly scheduled Jim Fleming guffawing.

-- 
-Barry Shein

The World  | b...@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*

Re: IPv4 address length technical design

[Barry Shein]

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 00...09. Not
insignificant in their effect.

There have been various schemes for UUIDs, intended to be unique, for
both hosts and disks or file systems, some quite widely deployed IBM's
System-36 in the early 80s but also Linux extN, others, see RFC
4122.


On October 5, 2012 at 16:47 jo...@iecc.com (John Levine) wrote:
 > In article 
 > <72a2f9af18ec024c962a748ea6cf75b90ed2b...@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

-- 
-Barry Shein

The World  | b...@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*

Re: IPv4 address length technical design

[Jay Ashworth]

- Original Message -
> From: "Barry Shein" 

> 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   j...@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

Re: IPv4 address length technical design

[Barry Shein]

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  | b...@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*

Re: IPv4 address length technical design

[John Levine]

In article 
<72a2f9af18ec024c962a748ea6cf75b90ed2b...@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

RE: IPv4 address length technical design

[Siegel, David]

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.

Dave




-Original Message-
From: Barry Shein [mailto:b...@world.std.com] 
Sent: Thursday, October 04, 2012 5:36 PM
To: nanog@nanog.org
Subject: Re: IPv4 address length technical design


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  | b...@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*

RE: IPv4 address length technical design

[Spurling, Shannon]

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:b...@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  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  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

Re: IPv4 address length technical design

[William Herrin]

On Thu, Oct 4, 2012 at 7:36 PM, Barry Shein  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  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: IPv4 address length technical design

[Jay Ashworth]

- Original Message -
> From: "Barry Shein" 

> 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.

And Whacky Weekend begins early.

Jim?  Jim Fleming?  How'd you break into Barry's email account?

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@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

Re: IPv4 address length technical design

[George Herbert]

On Thu, Oct 4, 2012 at 4:36 PM, Barry Shein  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.herb...@gmail.com

Re: IPv4 address length technical design

[Mark Andrews]

In message <20590.7539.491575.455...@world.std.com>, Barry Shein writes:
> 
> 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.

It's the worst idea I've heard in a long time.  Names have nothing
to do with physical location or how you reach a machine.

> 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  | b...@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*
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: IPv4 address length technical design

[Barry Shein]

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  | b...@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*

Re: IPv4 address length technical design

[William Herrin]

On Thu, Oct 4, 2012 at 4:17 PM, Cutler James R
 wrote:
> On Oct 4, 2012, at 4:00 PM, William Herrin  wrote:
>> On Wed, Oct 3, 2012 at 7:12 PM, Cutler James R
>>  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  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: IPv4 address length technical design

[Cutler James R]

On Oct 4, 2012, at 4:00 PM, William Herrin  wrote:
> On Wed, Oct 3, 2012 at 7:12 PM, Cutler James R
>  wrote:
>> On Oct 3, 2012, at 6:49 PM, Jimmy Hess  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

Yes. 

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

Re: IPv4 address length technical design

[William Herrin]

On Wed, Oct 3, 2012 at 7:12 PM, Cutler James R
 wrote:
> On Oct 3, 2012, at 6:49 PM, Jimmy Hess  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  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: IPv4 address length technical design

[Owen DeLong]

On Oct 4, 2012, at 11:19 AM, Tony Finch  wrote:

> Owen DeLong  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

Re: IPv4 address length technical design

[Valdis . Kletnieks]

On Thu, 04 Oct 2012 09:57:34, Johnny Eriksson said:
> valdis.kletni...@vt.edu wrote:
>
> > 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*).
>
> Not quite correct.  Anywhere from 1 to 36 bits, and not spanning
> a 36-bit word boundary.  Essentialy what is now known as a bit field.

Right - but in actual programming practice, code tended to distinguish
between a "byte" and "N bit wide field of flags or whatever".  And bytes
as character storage ran from 6 to 9 bits depending on the charset in use.


pgpAu3riImDRv.pgp
Description: PGP signature

Re: IPv4 address length technical design

[Tony Finch]

Owen DeLong  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.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.

Re: IPv4 address length technical design

[Bjorn Leffler]

On Wed, Oct 3, 2012 at 12:13 PM, Chris Campbell  wrote:
>
> Is anyone aware of any historical documentation relating to the choice of 32 
> bits for an IPv4 address?

I've heard Vint Cerf say this himself, but here's a written reference
for you. They had just finished building arpanet, which was expensive
to build. Hence why they estimated two networks per country.

http://www.domainpulse.com/2012/06/06/world-ipv6-day/

When developing IPv4, Cerf said that he and Bob Kahn “estimated that
there might be two national-scale packet networks per country and
perhaps 128 countries able to build them, so 8 bits sufficed for 256
network identifiers. Twenty-four bits allowed for up to 16 million
hosts. At that time, hosts were big, expensive time-sharing systems,
so 16 million seemed like a lot. We did consider variable length and
128-bit addressing in 1977 but decided that this would be too much
overhead for the relatively low-speed lines (50 kilobits per second).
I thought this was still an experiment and that if it worked we would
then design a production version.

Re: IPv4 address length technical design

[joel jaeggli]

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

Re: [tt] IPv4 address length technical design

[Masataka Ohta]

Eugen Leitl wrote:

> My (minor) beef with it is that while you offload most of
> heavy lifting to photonics you still use electronics and
> lookup.

Because for non linear operations, electronics is a lot
better than so linear photonics w.r.t. speed, power,
size etc.

And, it's not my idea. See 'The "Staggering Switch": An
Electronically Controlled Optical Packet Switch' by
Zygmunt Haas, which mentioned "almost all optical" in
1993.

> 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).

How can you say BGP, then?

> (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 ;)

The problem with large number (beyond size of CAM with reasonable
power consumption) of MAC is that hash table is necessary,
which means route look up time is not bounded, which means
fiber delay lines can not be used.

Thousands of MAC addresses in a small L2 WAN is fine, except
that BGP does not work.

> If you do it in optics the protocol is completely different
> from IPv4/IPv6,

What I have shown is that what will be completely different will
be L2.

IPv4 uber alles.

Masataka Ohta

Re: [tt] IPv4 address length technical design

[Eugen Leitl]

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.

Re: IPv4 address length technical design

[Marco Hogewoning]

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?

Marco

Re: IPv4 address length technical design

[Masataka Ohta]

Eugen Leitl wrote:

> 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

Seriously speaking, that is the likely future as 1T
Ethernet will be impractical.

The point is to use 1Tbps packet by encoding a packet
simultaneously over, for example, 100 wavelengths each
encoded at 10Gbps.

> while few bits of the header have streamed by your
> photonic router circuit.
> 
> There is no time for any table look-ups, obviously.

At 1Tbps, 500B packet is 4ns long, which is long enough
for full /24 (with limited support for /32) look up.

While wavelengths containing header information are used
for table look up and rewritten, rest of the wavelengths
are delayed.

What you can't use with fiber delay lines is hash table,
which means large number (beyond CAM capacity) of Ethernet
MAC addresses is unusable and IPv6 with current allocation
scheme is bad.

> And optical gates are *really* expensive, so better use few of
> them. And don't add too many gate delays, too.

That's one reason why we should use 1Tbps packets. A gate
should switch not 10Gbps but 1Tbps or faster data.

Another reason is that 1Tbps packet needs 100 times shorter
delay lines to buffer than 10Gbps ones.

> 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.

Re: IPv4 address length technical design

[Johnny Eriksson]

valdis.kletni...@vt.edu wrote:

> 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*).

Not quite correct.  Anywhere from 1 to 36 bits, and not spanning
a 36-bit word boundary.  Essentialy what is now known as a bit field.

--Johnny

Re: IPv4 address length technical design

[Eugen Leitl]

On Wed, Oct 03, 2012 at 06:59:20PM -0400, valdis.kletni...@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.

Re: IPv4 address length technical design

[Barry Shein]

On October 3, 2012 at 17:09 j...@baylink.com (Jay Ashworth) wrote:
 > 
 > So the address space for IPv8 will be...
 > 

Variable.

  -b

Re: IPv4 address length technical design

[George Herbert]

On Wed, Oct 3, 2012 at 4:15 PM, Owen DeLong  wrote:
>
> On Oct 3, 2012, at 3:49 PM, Jimmy Hess  wrote:
>
>> On 10/3/12, Jay Ashworth  wrote:
>>> So the address space for IPv8 will be...
>>> 
>>
>> 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.herb...@gmail.com

Re: IPv4 address length technical design

[Owen DeLong]

On Oct 3, 2012, at 3:49 PM, Jimmy Hess  wrote:

> On 10/3/12, Jay Ashworth  wrote:
>> So the address space for IPv8 will be...
>> 
> 
> 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…

Owen

Re: IPv4 address length technical design

[Cutler James R]

On Oct 3, 2012, at 6:49 PM, Jimmy Hess  wrote:
> On 10/3/12, Jay Ashworth  wrote:
>> So the address space for IPv8 will be...
>> 
> 
> 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.
> 
> Need more bits?   No protocol definition change required.
> 
> 
>> Cheers,
>> -- jra
> --
> -JH
> 

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

Re: IPv4 address length technical design

[Cutler James R]

On Oct 3, 2012, at 4:17 PM, Dave Crocker  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).

Re: IPv4 address length technical design

[David Conrad]

On Oct 3, 2012, at 3:59 PM, valdis.kletni...@vt.edu wrote:
> 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;
> 
> Where's Noel Chiappa when you need him?

Saying "I told you so" I suspect.

>>  (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.

Where are Tony Li, Paul Traina, and the whole TUBA orchestra when you need 
them?  :-)

Regards,
-drc

Re: IPv4 address length technical design

[Valdis . Kletnieks]

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...



pgpdw5TUCJmzT.pgp
Description: PGP signature

Re: IPv4 address length technical design

[Jimmy Hess]

On 10/3/12, Jay Ashworth  wrote:
> So the address space for IPv8 will be...
> 

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.

Need more bits?   No protocol definition change required.


> Cheers,
> -- jra
--
-JH

Re: IPv4 address length technical design

[Owen DeLong]

On Oct 3, 2012, at 12:22 PM, Izaac  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

RE: IPv4 address length technical design

[Naslund, Steve]

Remember that at the time, IP was designed to be classful so having four 8 bit 
bytes was real convenient to look only at the bytes in the host portion of the 
address.  Class A meant three significant bytes, Class B had two significant 
bytes, and Class C had three significant bytes as far as the host portion of 
the address.  If we are looking for matches in a routing table it is much 
easier to search for an entire matching byte than to do it bitwise.  Even 
though systems had varying byte lengths, 8 was still the most common because it 
was the easiest to map extended ASCII into.

Now we could discuss whether there should have been more bytes but at the time 
no one had really envisioned the public deployment of this at the scales we see 
today.  Same reason IBM and Microsoft had barriers like 640k of RAM, no one 
just ever thought you would need more than that.

Steven Naslund

-Original Message-
From: Seth Mos [mailto:seth@dds.nl] 
Sent: Wednesday, October 03, 2012 11:53 AM
To: nanog@nanog.org
Subject: Re: IPv4 address length technical design

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

Re: IPv4 address length technical design

[George Herbert]

On Wed, Oct 3, 2012 at 2:19 PM, Scott Weeks  wrote:
>
>
> --- j...@baylink.com wrote:
> From: Jay Ashworth 
>
> So the address space for IPv8 will be...
> 
> -
>
>
> Jim says:
>
> "IPv8 - 43 bits (3+8+32)
>
> There is a natural routing hierarchy with IPv8
> addressing8 regions, 256 distribution centers
> in each region and full 32 bit Internets from there.
> IPv8 addresses can fit inside the IPv6 address fields."
>
>
>>;-)
> scott

One bit of network address, used to designate whether it is a
broadcast or single-host-recipient packet.

And 511 bit MAC addresses...

(L2 Uber Alles.  Routers are for the Weak.)


-- 
-george william herbert
george.herb...@gmail.com

Re: IPv4 address length technical design

[Scott Weeks]

--- j...@baylink.com wrote:
From: Jay Ashworth 

So the address space for IPv8 will be...

-


Jim says:

"IPv8 - 43 bits (3+8+32)

There is a natural routing hierarchy with IPv8
addressing8 regions, 256 distribution centers
in each region and full 32 bit Internets from there.
IPv8 addresses can fit inside the IPv6 address fields."


>;-)
scott

Re: IPv4 address length technical design

[Jay Ashworth]

- Original Message -
> From: "Dave Crocker" 

> 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...


Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@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

Re: IPv4 address length technical design

[Dave Crocker]

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/

--
 Dave Crocker
 Brandenburg InternetWorking
 bbiw.net

Re: IPv4 address length technical design

[William Herrin]

On Wed, Oct 3, 2012 at 3:22 PM, Izaac  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.

It wasn't. At the time. But at some point people of vision figured out
that CPU word sizes would standardize on power-of-two powers of two.
Really helps when you want to align data elements in memory if exactly
2 16 bit integers fit in the 32 bit word and exactly 2 32 bit integers
fit in the 64 bit word. "And a half" is a phrase that makes life
miserable in both software development and hardware design.

IEEE figured it out later. The replacement for the MAC address is
EUI-64. I still haven't figured out Bell's excuse with ATM.

Regards,
Bill Herrin

-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: IPv4 address length technical design

[Valdis . Kletnieks]

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*).


pgpz78iTf2YW4.pgp
Description: PGP signature

RE: IPv4 address length technical design

[Tony Patti]

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

http://en.wikipedia.org/wiki/PDP-10

http://en.wikipedia.org/wiki/Email

Tony Patti
CIO
S. Walter Packaging Corp.


-Original Message-
From: George Herbert [mailto:george.herb...@gmail.com] 
Sent: Wednesday, October 03, 2012 3:28 PM
To: Tony Hain
Cc: nanog@nanog.org
Subject: Re: IPv4 address length technical design

On Wed, Oct 3, 2012 at 12:11 PM, Tony Hain  wrote:

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.

Re: IPv4 address length technical design

[George Herbert]

On Wed, Oct 3, 2012 at 12:22 PM, Izaac  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.herb...@gmail.com

Re: IPv4 address length technical design

[George Herbert]

On Wed, Oct 3, 2012 at 12:11 PM, Tony Hain  wrote:
>> Sadiq Saif [mailto:sa...@asininetech.com] wrote:
>>
>> On Wed, Oct 3, 2012 at 12:13 PM, Chris Campbell 
>> 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.herb...@gmail.com

Re: IPv4 address length technical design

[Izaac]

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.

-- 
. ___ ___  .   .  ___
.  \/  |\  |\ \
.  _\_ /__ |-\ |-\ \__

RE: IPv4 address length technical design

[Tony Hain]

> Sadiq Saif [mailto:sa...@asininetech.com] wrote:
>
> On Wed, Oct 3, 2012 at 12:13 PM, Chris Campbell 
> 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 ... 

Re: IPv4 address length technical design

[Robert E. Seastrom]

Chris Campbell  writes:

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

8 bit host identifiers had proven to be too short...  :)

-r

Re: IPv4 address length technical design

[Seth Mos]

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

Re: IPv4 address length technical design

[Kevin Broderick]

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

Sadiq Saif  wrote:

>On Wed, Oct 3, 2012 at 12:13 PM, Chris Campbell 
>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
>
>--
>Sadiq S
>O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

Re: IPv4 address length technical design

[Sadiq Saif]

On Wed, Oct 3, 2012 at 12:13 PM, Chris Campbell  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

-- 
Sadiq S
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

IPv4 address length technical design

[Chris Campbell]

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

Cheers.