[ih] IPv4 address size debate

[Vint Cerf]

since I made the decision to go with 32 bits, i can say that at the  
time I thought this was still very much an experiment and that if it  
proved successful, we would design a production version. We sort of  
neglected that step.

vint


On Nov 13, 2009, at 4:34 PM, Noel Chiappa wrote:

>> From: Jack Haverty <jack at 3kitty.org>
>
>> Since I was one of the people arguing for fixed-length addresses back
>> in those days, I guess maybe it's time to explain why...
>
> I don't disagree that fixed-length addresses were the right choice  
> _at the
> time_; I was actually interested in why we didn't pick something  
> with a
> little more long-term flexibility (i.e. flexible syntax, with  
> 'temporarily'
> subsetted semantics to produce _effectively_ fixed-length  
> addresses), and if
> that option was even considered.
>
> Did people think 32 bits was 'more than enough for any conceivable
> circumstances', or did they not think that TCP/IP would be anything  
> other
> than a large-scale trial that would be supplanted by something new,  
> or what?
>
> Had someone suggested a format with address-length fields, and the  
> only
> allowed/supported value in them being '4', do you think that would  
> have been
> accepted?
>
>
>> It was very very desirable to have the hardware put the data into the
>> "right place" for subsequent processing.
>
> I take your point (I used techniques to do the same thing in the  
> router code
> I did, to avoid having to ever move data), but at the same time it  
> undermines
> the then-current reasoning that 'if we need to do anything else, we  
> can do it
> with a header option' - since (as you point out below) using options  
> produces
> variable-length headers, and those negate the advantages of a fixed- 
> length
> header.
>
>> IP packets with no options would be fast, those with options would
>> suffer.
>
> Which is still the situation today... I was going to say 'sadly',  
> but I'm not
> sure that's warranted. But it is certainly a very high bar to the  
> use of
> options for extensions that are anything other than 'low-duty- 
> cycle' (i.e. in
> few packets), and that definitely limits the value of the option-based
> extensibility mechanism.
>
>> There was at least one implementation of Ethernet (MIT? IIRC) that  
>> put
>> the Ethernet header at the *back end* of the packet on the wire -  
>> i.e.,
>> it became a trailer rather than a header.
>
> Ah, no. That was Berzerkley. (See RFC 893.) (Gratuitous comment  
> suppressed... ;-)
>
>> This would have required, among other things, redefining the IP  
>> header
>> so that the checksum was kept in a trailer - since you couldn't  
>> finish
>> computing the checksum until all of the data had come in.
>
> ??? The IP checksum covers only the IP header, no?
>
>
>> Essentially you would end up with a circuit-switched network that had
>> an IP datagram interface ... In this architecture, IP is an interface
>> spec at the edges only, and what goes on inside is hidden and could  
>> be
>> anything. I wonder if today's routers play such tricks....
>
> That's exactly how today's networks actually operate. Things like  
> Frame Relay
> and MPLS avoid processing IP headers on many hops - although on a  
> local basis
> only (i.e. not system-wide).
>
> I do forsee IP becoming an interface-spec at the edges, with  
> something new
> being used _inside_ the network, i.e. router-router (much like an  
> RJ11 analog
> jack is an old interface to a wholly different/modern internals),  
> but then
> again this is hardly a new idea - the Nimrod deployment plan used  
> the same
> concept! So my crystal ball may be a bit out of focus, timewise... :-)
>
> At the moment IP is in fact still used for the generic router-router
> interface, but I do think the day is drawing closer when something  
> else will
> (slowly, admittedly) replace it in that role.
>
> 	Noel