[AusNOG] So who's read an RFC or Internet Draft?
Mark Smith
markzzzsmith at gmail.com
Mon Oct 5 19:10:58 EST 2015
Hi Greg,
On 24 September 2015 at 13:50, Greg <mclennan at internode.on.net> wrote:
> I am finishing off a Uni assignment project(subnetting) at the moment
> and have had my head buried in some RFC's of late. What has stood out for me
> in RFC's has been the history timelines of basic topics like subnets and how
> they came to pass!
>
> RFC791- (1981) introduced IP as well as classfull addressing concepts e.g
> class A,B,C concepts (subnetting was implicitly integrated into each class,
> without actually using the word 'subnet' you either got 16Million/65K/254..
> addresses on your particular network class to use!).
>
> RFC917- (1984) the concept of subnetting was introduced !
>
> RFC950-(1985) A standard for subnetting was introduced.
>
> RFC1518/1519(1993) - Classless Inter-Domain Routing (CIDR) - A realization
> that IP exhaustion would occur and super/subnetting could assist with this
> issue. This had me then researching how big the internet was and who owned
> what IP's in those days.. Then I found this little goldmine text document
> showing effectively who owned what IP ranges back 1992 >>
> ftp://nic.funet.fi/index/FUNET/history/a.dump.of.funet.fi-ftp.archive.1996-10-25/netinfo/netinfo/network-contacts.txt
>
So to take this further back (having researched it a while back
because I thought that would make it easier to teach when I used to)
RFC760 (Jan 1980) - didn't have address classes - Addresses were all
"Class A" format, namely 8 bit network number, 24 bit host number
(i.e., N.H.H.H). So somewhere between RFC791 (September 1981) the
first likely "running out" event - network numbers - was recognised,
and so Classes were introduced in RFC791.
This was a few years before ARP (RFC826 (November 1982)). The method
of resolving IP layer addresses into link-layer addresses was achieved
by placing the link-local addresses directly in the 24 bit host
number, as Novell's IPX did (and since IPX is based on Xerox's XNS,
XNS probably did the same.). You can see these mappings for pre-ARP
IPv4 in Internet Engineering Note 115 (August 1979) (IENs were
somewhat of an alternative to RFCs for a while).
https://www.rfc-editor.org/ien/ien115.txt
IPv6 is interesting in this regard - default IPv6 interface
identifiers (IIDs) are currently formed from link-layer addresses for
convenience (basically flip a bit in the link-layer address and insert
FF-FE), however IPv6 still has a neighbor discovery protocol to
resolve layer 3 to layer 2 addresses. The reason is so that we don't
have to use link-layer addresses to form IIDs - allowing
temporary/privacy addresses, cryptographic Generated addresses (CGAs)
etc.
RFC760 obsoletes IEN123 (December 1979), which also specifies a
revision of IPv4 with 32 bit addresses in the form N.H.H.H.
If you follow the chain of revisions IEN123 replaces (IENs 111, 80,
54, 44, 41, 28, 26), you get to IEN44 (June 1978) - still IP version 4
- where it says,
"Addresses are variable length multiples of octets, the source and
destination addresses may be of different lengths. An address begins
with an one octet network number. Following the network number the
address is composed of fields appropriate to the specified network".
It then presents an example for the ARPANET network, where the 1 octet
network number (Network 10 - yes, reclaimed for RFC1918 private
addresses) was followed by a 1 octet IMP number and a two octet host
number.
IEN28 (February 1978) is for IP version 2. It says that an address
could be extended even further than just identifying a host, to also
identify different instances of the TCP on a host. There also mention
of the idea of having short form addresses for when "an internet
message is to be delivered within a smaller environment."
IEN26 (14 February 1978) is also for IP version 2, mentions having a
version field that only supports 2 versions. Unfortunately the PDF
scan of this IEN is missing page 3, which is where the addressing text
is!
This is around the time when TCP was split away from IP - originally
it was all "TCP", which included IP functionality. IEN2 "2.3.3.2
Comments on Internet Protocol and TCP" (15 August 1977), says in the
Introduction,
" The position taken here is that
internetwork communication should be view as having two components: the
hop by hop relaying of a message, and the end to end control of the
conversation. This leads to a proposal for a hop by hop oriented
internet protocol, an end to end oriented host level protocol, and the
interface between them."
Then Jon gets blunt!
"Discussion
We are screwing up in our design of internet protocols by violating the
principle of layering. Specifically we are trying to use TCP to do two
things: serve as a host level end to end protocol, and to serve as an
internet packaging and routing protocol. These two things should be
provided in a layered and modular way. I suggest that a new distinct
internetwork protocol is needed, and that TCP be used strictly as a host
level end to end protocol."
>From the addressing perspective, this is where this IEN is really
interesting - because it supports variable length addressing in units
of 4 bits, and cycles through them:
"Addresses
Addresses are variable length strings of 4 bit chunks prefixed by a
length. As address chunks are processed they are removed from their
position at the head of the address chunk string and placed at the
end of the string. This chunk by chunk circular shifting of the
address allows each node in the hop by hop processing of a message
to examine the part of the address it consumes with out knowing how
much address preceeds or follows that part."
It is also interesting as there were no source address in the
"internet protocol message"!
" The internet protocol message format has the following fields:
Version
Flags
Data Identifier
Acknowledgement Identifier
Type of Service
Destination Address
Fragment Information
Message Identifier
Fragment Sequence Number
Last Fragment Flag
Data Length
Data
Checksum"
More detail of the Destination address format is provided:
"The Destination Address field is a variable length extensible
address composed of 4 bit chunks. The first chunk is the length of
the address in chunks, except that the value 0 indicates that the
next two chunks as a 8 bit number indicate the length."
So if the first 4 bit length chunk is non-zero, then the destination
address could be up to 16 times 4 bits, or 64 bits. If the first 4 bit
length chunk is zero, then the next two 4 bit chunks are the number of
4 bit chunks in the destination address, which means up to 256 times 4
bits or 1024 bit destination addresses - much bigger than IPv6's 128
bits. There is a note that this encoding scheme for address length
could actually go on indefinitely, supporting any length addresses. Of
course, this is a much more complicated scheme than we've ended up
with in IPv4 and IPv6, and probably may not have ever been able to be
implemented in fast forwarding hardware.
An earlier form of 4 bit "chunk" addressing is described in RFC675,
"SPECIFICATION OF INTERNET TRANSMISSION CONTROL PROGRAM" (December
1974) which doesn't use a magic leading 4 bit length value of 0 to
indicate that there will be further length field 4 bit chunks. So this
version would support variable length addresses up to 64 bits in
length.
Finally, there is a paper by Vint Cerf and Bob Kahn, "A Protocol for
Packet Network Intercommunication", May 1974
(http://www.cs.princeton.edu/courses/archive/fall06/cos561/papers/cerf74.pdf),
which describes a "TCP address" as 8 bit Network number and 16 bit TCP
Identifier:
"The choice for network identification (8 bits) allows up to 256
distinct networks. This size seems sufficient for the foreseeable
future. Similarly, the TCP identifier field permits up to 65 536
distinct TCP’s to be addressed, which seems more than sufficient for
any given network."
So Internet addressing evolved a lot before we ended up with the IPv4
addressing we have today. It is worth remembering that Vint Cerf, Bob
Kahn and many others (excepting Jon Postel (RFC2468) and a few others)
are still around, and having had the above experiences, I think the
rest of us can be fairly confident that IPv6's 128 bit address size is
going to be adequate.
(Good thing the archive is public, so this brief history of Internet
addressing will hopefully show up in various search engines!)
Regards,
Mark.
More information about the AusNOG
mailing list