Re: RFC 1812 Section 6.2 Clarificaiton

Fred Baker <fred@cisco.com> Thu, 14 September 1995 18:18 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18032; 14 Sep 95 14:18 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa18025; 14 Sep 95 14:18 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa27569; 14 Sep 95 14:18 EDT
Received: from stilton.cisco.com by venera.isi.edu (5.65c/5.61+local-22) id <AA13179>; Thu, 14 Sep 1995 10:51:13 -0700
Received: from [171.69.128.114] (fred-mac-fr.cisco.com [171.69.128.114]) by stilton.cisco.com (8.6.8+c/8.6.5) with SMTP id KAA14188; Thu, 14 Sep 1995 10:50:52 -0700
X-Sender: fred@stilton.cisco.com
Message-Id: <v02130506ac7e130d4445@[171.69.128.114]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 14 Sep 1995 10:51:02 -0700
To: Mike Benefield <mikeb@basenet.net>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Fred Baker <fred@cisco.com>
Subject: Re: RFC 1812 Section 6.2 Clarificaiton
Cc: desker@basenet.net, rreq@isi.edu

At 10:50 AM 9/13/95, Mike Benefield wrote:
> My colleagues and I are utilizing RFC 1812 extensively and we're
> very grateful for its present state and usefulness, and we do thank
> you and your 1812 group.

I am glad it is more useful in its current state. I would like to believe
that it's perfect. My bet is that somewhere in those 200+ pages there is an
imperfection. You may have found it...

> We are developing a MIL-STD for IP (with PICS) and are presently
> involved with the section dealing with the transport layer,
> specifically UDP and TCP router requirements.
>
> We referred to RFC 1812, section 6 (Transport Layer) and sections
> 6.1 (UDP) and 6.2 (TCP).  We fared well with UDP, but we have some
> questions about TCP section 6.2 and we hope that you might be
> willing to help us with a better understanding of the section.
>
> The first open-faced circle (bubble) near the beginning of section
> 6.2 explains that,
>
>       "This specification does not specify the interfaces between the
>       various protocol layers.  Thus, a router need not comply with the
>       following requirements of "RFC 1122" (except of course where
>       compliance is required for proper functioning of Application Layer
>       protocols supported by the router.)"  ....
>
> Then we looked at the second bubble, which explained,
>
>       "For similar reasons, a router need not comply with any of the
>       requirements of "RFC 1122."
>
> Note:  In the earlier router documents, RFC 1122 section 4.2.4 was
> cited.  This new entry implies the entire "1122."
>
> Finally, the Discussion paragraph immediately following says, "It
> should particularly be noted that a TCP implementation in a router
> must conform to the following requirements of "RFC 1122" ...."
>
> Note:  The sub-bubble items listed in this "Discussion" paragraph
> had 1122 references in the earlier router documents, including one
> (TOS) in section 4.2.4, (excluded above).
>
> We are most interested in making TCP mandatory for at least our
> border routers (with BGP-4) and we're not certain how to cite RFC
> 1812, section 6.2 and not cause undo interoperability problems,
> etc.  We considered invoking full TCP for our routers in the
> MIL-STD but aren't sure of the ramifications of bypassing the
> router considerations stated in RFC 1812 section 6.2.
>
> And we would like your thoughts on this matter if you have a
> moment. We are facing a very short deadline and any assistance you
> may provide for us would be most appreciated.

I am glad to say that this isn't my verbiage: a quick comparison with RFC
1716 says that I didn't modify it from there. :^(

It think the major issue is bubble two, which appears to drop out the
requirements of 1122 altogether. I think it was intended to read "...any of
the following requirements of 1122" referencing the following two bullets.
Either that, or it was cruft from writing the first bullet, and should have
been dropped out entirely. In any case, it is an editing error - mine.

The issue with 1122/1123 is this: it was written first, and RFC 1716/1812
later. Some technology, notably Path MTU Discovery, was developed and
deployed in the meantime, and other deployment experience was gained. In
the process of writing the router requirements draft (which was a hotly
debated document) a number of places were found where 1122's wording was
unnecessarily restricted to host implementations or was just plain wrong.
The tack taken, rather than rewrite 1122, was to specify differences from
it. Realistically, many of these differences also apply to hosts, and the
documents should really be re-edited as a group, the data link layer
specified for routers and hosts, routers acting as a protocol endpoint (in,
for example, ARP or TCP) treated as hosts in that context, and the
differences between a router a host limited to routing protocols and
forwarding behavior. That effort was far more than I had time for or anyone
else had the energy left to contemplate.

But OK, here's where we stand. A router that uses TCP (for telnet, BGP,
tunnels, or whatever) is a host in that context and should follow the
specifications of 1122. However, 1122 is in error or fails to specify some
technology that was developed later, and so a router using TCP must:

        correctly implement URGENT and handle connection failures (these
        comments probably are places where the working group felt 1122 was
        incorrect)

        correctly handle multihoming (not discussed in 1122)

        correctly implement path MTU (not specified in 1122, 1122 says the
        MTU is 536 unless otherwise negotiated)

        not abort TCP connections on receipt of ICMP Unreachable
        (error in 1122)

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
So Bill Gates has paid Mick and the boys 12 million dollars to use "Start Me
Up" to sell Windows 95.

For those who don't know the song, it's the one that goes "You make a grown
man cry...".

Food for thought