rfc 1063 and intermediate routers

Craig Partridge <craig@NNSC.NSF.NET> Mon, 11 December 1989 13:41 UTC

Received: from decwrl.dec.com by acetes.pa.dec.com (5.54.5/4.7.34) id AA01418; Mon, 11 Dec 89 05:41:35 PST
Received: by decwrl.dec.com; id AA10836; Mon, 11 Dec 89 05:41:32 -0800
Message-Id: <8912111341.AA10836@decwrl.dec.com>
To: jnc@allspice.lcs.mit.edu
Cc: mtudwg
Subject: rfc 1063 and intermediate routers
Date: Mon, 11 Dec 1989 08:39:39 -0500
From: Craig Partridge <craig@NNSC.NSF.NET>

>	However, this gives me an idea: the bug with 1063 is that it doesn't
> work if all the intermediate routers (and end host) don't understand it.

Noel:

    Actually, RFC 1063 works fine in the face of one or two non cooperating
routers.  The requirement is that you take lower of the MTU of the inbound
*and* outbound interfaces and compare with the option.  So if someone in
the path drops the ball, its OK.

    Note routers have to have a time when they know both inbound and outbond
interfaces (or ICMP redirects can't be done) but some folks have grumbled
they didn't buy into option processing there...  Dunno if that's proper
of them....

Craig

rfc 1063 and intermediate routers Craig Partridge
Re: rfc 1063 and intermediate routers Noel Chiappa