[ih] When did "32" bits for IP register as "not enough"?

[Dave Taht]

Jack Haverty <jack at 3kitty.org> writes:

> Well, I know that I personally didn't think bigger addresses were
> highest priority.  We used to put a list of "things we have to figure
> out" on the whiteboard at every Internet/ICCB/IAB meeting.  Address size
> was there, but there were several issues that had to be worked first,
> since the outcome would likely impact any new address structure.  This
> was early/mid 80s.

Yes, we had other issues besides address space!

Mine at the time was somehow getting IPX/SPX based networks to
interop. Didn't succeed.

> E.G., the "Expressway Routing" problem - namely how do you force traffic
> going from one computer to another on the same network to take a detour
> through gateways to use another intermediate net.  The practical case
> was the Wideband Net which was high-bandwidth satellite-based and
> attached to the ARPANET on both coasts.  But no traffic would naturally
> go that way since it would involve two hops instead of one.

Most DDOS providers offer this capabliity nowadays. I have no idea
how it works aside from "it takes BGP magic".

>
> E.G., the "Multi-homed Host" problem - namely how do you deal with a
> user computer attached to more than one network.  Does it have two IP
> addresses?  Can it effectively use both network ports at the same time? 
> Can it be constrained to not act as a gateway?

For IPv6, SADR routing has emerged. This involves having at least one
IPv6 address per possible uplink. It's a subset of policy routing.

https://en.wikipedia.org/wiki/Source-specific_routing

It is nearly universal now in embedded linux routers as it eliminates
the default route entirely, and thus any need for bcp38.

10 years ago (?), in babeld and linux it became possible to have
one IPv4/32 and IPv6/128 address per computer, no matter how many interfaces it
had. It broke broadcast and mcast to some extent but could and did work
for mobile IP, multiple routes to multiple destinations via the best
local path, etc. It did not solve the load balancing problem, however.

I still miss the days where I had a connection nailed up over ethernet,
and I moved to the (ad-hoc wifi) to walk to another location - plugged
back in - and went back to ethernet. Despite things like mosh, and vpns
smoothing that transition out now for me, still find it quite jarring.


> E.G., the "Multipath" problem - namely if you have several possible
> paths, how do you cause traffic to split and utilize both paths instead
> of just the one that seems best at the time, in order to achieve higher
> throughput and efficient line utilization.

See MPTCP, ECMP, etc.

We did some multipath work with mosh:

https://hal-univ-diderot.archives-ouvertes.fr/hal-01114285/document

>
> E.G., the "TOS Routing" problem - namely how do you make traffic with
> different TOS take different routes, such as a satellite one for traffic
> that doesn't need low delay.  This is one case of a larger "Policy
> Routing" issue - namely how you make traffic take routes constrained by
> someone's policy (like only ARPA projects can use ARPANET).
>
> There were more that I can't remember offhand.
>
> So, there was lots of stuff still to be done, all of which seemed likely
> to require experimentation.  Not a good time to change the basic address
> structure....

Agreed!

>
> I haven't been involved for a while, but I wonder if those outstanding
> problems have been solved, perhaps in IPV6.
>
> /Jack Haverty
>
> On 2/13/19 5:14 PM, Paul Ruizendaal wrote:
>>>> Around the same time [1980] I privately mentioned to Vint that
>>>> instead of going from an 8 bit network number plus a 24 bit subnet
>>>> address to class A,B,C addresses, instead they should go to 64
>>>> bits. He said this would be too disruptive.
>>> I suspect Vint didn't want yet another major change to TCP/IP to
>>> halt other experimental work in how to use the Internet for the
>>> year or two it would take to change all the software again.
>> Maybe Vint can chime in. Looking at it almost 40 years later, it
>> would seem to me that just changing the addresses from 32 to 64 bit
>> would have been about the same level of disruption as the GGP/ICMP
>> split that occurred in 1981. My hypothesis would be that the case
>> for 64 bit was at that time simply viewed as not very strong - which
>> would fit with both the “experiment” and “interim” views you
>> describe.
>>
>> Paul
>>
>>> On 14 Feb 2019, at 01:12, Jack Haverty <jack at 3kitty.org> wrote:
>>>
>>> I think what you're seeing is that the various people and groups
>>> working on "the Internet" in the early times (80s) didn't have the
>>> same view of the goal.
>>>
>>> The "let's experiment with new ideas for routing, protocols,
>>> congestion control, etc." crowd saw 32 bits as plenty for what they
>>> envisioned doing.  This would include a lot of the DARPA
>>> "experimental" work.  I suspect Vint didn't want yet another major
>>> change to TCP/IP to halt other experimental work in how to use the
>>> Internet for the year or two it would take to change all the
>>> software again.
>>>
>>> The "how do we build something for the whole planet" crowd saw 32
>>> bits as totally inadequate.  This would include the emerging ISPs
>>> who wanted a big market, and the ISO designers targeting the long
>>> vision.  These efforts produced a lot of paper, and software and
>>> hardware that worked if you adopted their particular "walled
>>> garden", but nothing with TCP/IP's universality that was embodied
>>> in things you could actually buy.
>>>
>>> IMHO, both were right in their positions.  They were simply working
>>> on different problems, and probably didn't realize it at the time.
>>>
>>> TCP/IP was later widely viewed as the "interim system" to be used
>>> outside of the experimental world, while the ISO et al were getting
>>> the final system in place.  It worked well enough, and much better
>>> than anything else that was available.  Plus there was a small army
>>> named IETF tweaking and patching the system to solve operational
>>> problems that came up.
>>>
>>> That "interim solution" viewpoint sidestepped a lot of bureaucratic
>>> obstacles since it was easier to get approvals, and fight fewer
>>> battles, for an interim stopgap.
>>>
>>> I wonder when (and if) the Internet ever graduated from "interim solution" status...
>>>
>>> /Jack Haverty
>>>
>>> On 2/13/19 2:34 PM, Ross Callon wrote:
>>>> There was some mumbling about 32 bits not being enough as early as
>>>> 1980. In 1980 there was the beginning of the effort that became
>>>> CLNP. The first related proposal came out of BBN and NBS (National
>>>> Bureau of Standards, which is now called NIST) in 1980 and
>>>> proposed that what became CLNP should be just IPv4 with 64 bit
>>>> addresses and the source quench removed, and nothing else changed
>>>> other than the version. At the time BBN had a contract with
>>>> NBS. This proposal was taken into ANSI bound in bright orange
>>>> cover paper, which caused it to be unofficially named the “pumpkin
>>>> paper”.  I didn’t find out until the ROAD meetings many years
>>>> later that someone else, I think probably Bob Hinden, had told
>>>> Vint the same thing at about the same time.
>>>>
>>>> Of course, at the time I had absolutely no idea how to get anyone
>>>> to agree with this change, and I was unaware that ANSI and ISO
>>>> would be unable to get anyone to follow their standards.
>>>>
>>>> I recall the ROAD group as occurring while I was still at BBN,
>>>> which I left in 1988. As such the group must have met no later
>>>> than 1988. NAT was discussed. I thought that Van Jacobsen brought
>>>> the idea into the ROAD group although Paul Francis was also
>>>> participating, and there was someone else whose name escapes me
>>>> (possibly Vince Fuller) who was also proposing NAT, and of course
>>>> this doesn’t say whose idea it was originally.
>>>>
>>>> I think of CIDR as having two parts. One was just getting away
>>>> from the class A, B, C restrictions. I don’t know where this came
>>>> from. The other was assigning addresses topologically. I think
>>>> that the topological part came later than the “no A,B,C” part.
>>>>
>>>> Bob Hinden might remember some of this. 
>>>>
>>>> Ross
>>>>
>>>>> On Feb 13, 2019, at 5:01 PM, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
>>>>>
>>>>>> From: Craig Partridge
>>>>>> NAT was a product of the ROAD (Routing and Addressing) working group
>>>>> Err, I don't think so. AFAICR, the IETF stuck its head in the sand for a long
>>>>> time over NAT. (Which definitely has its downsides...)
>>>>>
>>>>>> I recall, NAT was Van Jacobson's idea
>>>>> He and Paul Francis/Tsuchiya independently invented it, I think? I first heard
>>>>> about it from Van at the IAB 'addressing/routing retreat', or whatever that
>>>>> meeting was called.
>>>>>
>>>>>> CIDR, I think, was Jeff Mogul's idea.
>>>>> I don't think so; I'm pretty sure Jeff was out of the IETF world by then. Maybe
>>>>> you're thinking of his earlier document on subnetting a la MIT?
>>>>>
>>>>> CIDR came out of the ROAD meetings, but I don't know if it was any specific
>>>>> person's? Also, like I said, it was in mechanism identical to Roki's
>>>>> supernetting thing (in fact, the early RFC's on it call it 'supernetting', not
>>>>> CIDR), although he had proposed it for a totally different reason/need (IIRC,
>>>>> he wanted a host on an X.25 VAN to be able to send packet to a host on a
>>>>> different VAN, without going through a router).
>>>>>
>>>>> 	  Noel
>>>>> _______
>>>>> internet-history mailing list
>>>>> internet-history at postel.org
>>>>> http://mailman.postel.org/mailman/listinfo/internet-history
>>>>> Contact list-owner at postel.org for assistance.
>>>>
>>>>
>>>> _______
>>>> internet-history mailing list
>>>>
>>>> internet-history at postel.org
>>>> http://mailman.postel.org/mailman/listinfo/internet-history
>>>>
>>>> Contact 
>>>> list-owner at postel.org
>>>>  for assistance.
>>>>
>>> _______
>>> internet-history mailing list
>>> internet-history at postel.org
>>> http://mailman.postel.org/mailman/listinfo/internet-history
>>> Contact list-owner at postel.org for assistance.
>>
>> _______
>> internet-history mailing list
>> internet-history at postel.org
>> http://mailman.postel.org/mailman/listinfo/internet-history
>> Contact list-owner at postel.org for assistance.
> _______
> internet-history mailing list
> internet-history at postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-owner at postel.org for assistance.