[AusNOG] So who's read an RFC or Internet Draft?

Tue Oct 6 00:07:04 EST 2015

Lets not all forget RFC 1149 and RFC 2549..

:)

On Mon, Oct 5, 2015 at 6:10 PM, Mark Smith <markzzzsmith at gmail.com> wrote:
> 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.
> _______________________________________________
> AusNOG mailing list
> AusNOG at lists.ausnog.net
> http://lists.ausnog.net/mailman/listinfo/ausnog