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

Thu Feb 14 00:08:54 PST 2019

Responding to two messages in one:

>> I wonder when (and if) the Internet ever graduated from "interim
>> solution" status...
>>
>> /Jack Haverty

In Europe, it was somewhat official when RARE, the research networks'
association (later renamed TERENA and now named GÉANT) recognized TCP/IP
as an acceptable solution in January 1990 "without putting into question 
its OSI policy." I think that Dennis Jennings' choice of TCP/IP for NSFnet
in 1986 (?) was determinant in the US.

A related question is when the various OSI strategies were formally dropped.
Possibly never, because of the amour-propre of civil servants.

On 2019-02-14 15:12, Jack Haverty wrote:
> 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.
> 
> 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.

Policy based routing was a major issue when we first started interconnecting
research networks internationally in the NSFnet era. BGP4 helped, but
configuring it appropriately was (and is) a black art.

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

Still a hot topic. There's a current very active thread in the IETF IPv6
maintenance WG about 'Re: A common problem with SLAAC in "renumbering"
scenarios' which is really about this. It's a hard problem, present
in Pouzin's 1974 catenet paper and still tricky. I've been worrying about
multihoming for 20 years. 

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

Yep. Usually called ECMP these days (equal cost multipath routing).
Still a problem when packets are fragmented and the fragments might
follow different paths.

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

That's *supposed* to be handled by the diffserv (differentiated services)
mechanisms that replaced the original TOS mechanism via RFC2474, but diffserv
across ISP boundaries remains a bit tricky.
> 
> 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....
> 
> I haven't been involved for a while, but I wonder if those outstanding
> problems have been solved, perhaps in IPV6.

They are IMNSHO largely orthogonal to the address size. We intentionally
designed diffserv, for example, to be identical for IPv4 and IPv6. The IPv6
flow label is supposed to help the ECMP and load balancing problem, but is
only now coming into widespread deployment.

Regards
    Brian

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