Re: Comments on PMTU-Draft-RFC

mogul (Jeffrey Mogul) Fri, 02 February 1990 17:40 UTC

Received: by acetes.pa.dec.com (5.54.5/4.7.34) id AA18426; Fri, 2 Feb 90 09:40:48 PST
From: mogul (Jeffrey Mogul)
Message-Id: <9002021740.AA18426@acetes.pa.dec.com>
Date: 2 Feb 1990 0940-PST (Friday)
To: mtudwg
Cc:
Subject: Re: Comments on PMTU-Draft-RFC

I'll save the hard ones for the IETF meeting, but there are a few of
Steve Deering's comments that are easy to take care of:

    page 6, third paragraph: I agree with Pradeep, concerning the
    confusion over whether or not the next-hop field contains zero.
    Seems to me there is *no* need ever to set it to zero -- the
    decision can always be: "is this my address or not".  As it is,
    you've introduced three states (my address, zero, other), when only
    two are needed (my address, other), making it harder to understand
    the protocol.  Or have I missed some subtle requirement for three
    states?

One thing that some people apparently have missed is that the whole
point of this next-hop business is so that when the option reaches
the last-hop router, it is possible to know if ALL the routers on
the path have correctly updated the MTU value.  Steve is correct, though,
that if we change the protocol so that a router simply stops updating
the next-hop field if it isn't "right", rather than setting it to zero,
it will be "wrong" when it reaches the last-hop router; that is, there
is no need for the zero state.  Keith pointed out to me that this
change means that, at least at the receiver, you automatically get the
address of the (first) router that doesn't understand the option.  This
might make finger-pointing easier!

    page 20, section 8.5: do you want to mention proxy-ARP situations?  That's
    a case where PMTU discovery would be useful, but the sender thinks it is
    sending to a neighbor.  Of course, in that case, the next-hop field doesn't
    work too well.  Is proxy ARP being actively discouraged yet?

Proxy ARP is only "used" (unwittingly) by senders that have not been
upgraded to support subnetting (or more precisely, RFC950).  I see no
reason to expect that a sender that is upgraded to support MTU discovery
would not also be upgraded to meet the existing mandatory standards.
Does the RFC have to include explicit prohibitions against stupidity?

-Jeff