Re: [TUHS] core

[jnc@mercury.lcs.mit.edu (Noel Chiappa)]

    > From: Derek Fawcus <dfawcus+lists-tuhs@employees.org>

    > my scan of it suggests that only the host part of the address which were
    > extensible

Well, the division into 'net' and 'rest' does not appear to have been a hard
one at that point, as it later became.

    > The other thing obviously missing in the IEN 28 version is the TTL

Yes... interesting!

    > it has the DF flag in the TOS field, and an OP bit in the flags field

Yeah, small stuff like that got added/moved/removed around a lot.


    > the CIDR vs A/B/C stuff didn't really change the rest.

It made packet processing in routers quite different; routing lookups, the
routing table, etc became much more complex (I remember that change)! Also in
hosts, which had not yet had their understanding of fields in the addresses
lobotomized away (RFC-1122, Section 3.3.1).

Yes, the impact on code _elsewhere_ in the stack was minimal, because the
overall packet format didn't change, and addresses were still 32 bits, but...


    > The other bit I find amusing are the various movements of the port
    > numbers

Yeah, there was a lot of discussion about whether they were properly part of
the internetwork layer, or the transport. I'm not sure there's really a 'right'
answer; PUP:

  http://gunkies.org/wiki/PARC_Universal_Packet

made them part of the internetwork header, and seemed to do OK.

I think we eventually decided that we didn't want to mandate a particular port
name size across all transports, and moved it out. This had the down-side that
there are some times when you _do_ want to have the port available to an
IP-only device, which is why ICMP messages return the first N bytes of the
data _after_ the IP header (since it's not clear where the port field[s] will
be).

But I found, working with PUP, there were some times when the defined ports
didn't always make sense with some protocols (although PUP didn't really have
a 'protocol' field per se); the interaction of 'PUP type' and 'socket' could
sometimes be confusing/problemtic. So I personally felt that was at least as
good a reason to move them out. 'Ports' make no sense for routing protocols,
etc.

Overall, I think in the end, TCP/IP got that all right - the semantics of the
'protocol' field are clear and simple, and ports in the transport layer have
worked well; I can't think of any places (other than routers which want to
play games with connections) where not having ports in the internetwork layer
has been an issue.

    Noel