Re: draft-van-beijnum-multi-mtu-05.txt

[David Lamparter <[e-mail]>]

On Wed, Apr 06, 2016 at 11:20:48PM +0200, David Lamparter wrote:
> On Wed, Apr 06, 2016 at 04:55:46PM -0300, Erik Nordmark wrote:
> > On 4/6/16 12:18 PM, David Lamparter wrote:
> > > On Mon, Apr 04, 2016 at 11:37:17PM +0200, Mikael Abrahamsson wrote:
> > > Ok... easy comments/opinions first:
> > > - should definitely be ICMP, not UDP.  Erik Nordmark's suggestion to
> > >    piggyback on NUD sounds great, though admittedly I haven't thought it
> > >    through looking for pitfalls.
> > One issue compared to a dedicate probe is that a NUD (a unicast NS) of 
> > size X wouldn't necessarily result in a unicast NA that is also padded; 
> > perhaps one can add such behavior so that we can get the bidirectional 
> > probe in both directions.
> 
> That might be (half of) a feature: if the MTU probe is a NS option, and
> the target host does not support it, we still get a NA reply.  That's
> better than timing out waiting.  The downside is that a NA without the
> "MTU response" option doesn't mean that the host doesn't implement the
> protocol -- the NA could be in response to something else.

Obvious easy way: have the "ND NODEMTU" option described in draft sec. 5
mandatory on all NAs if the host implements the protocol; receipt of any
NA without the option can then flag the sender as mtu-probe-incapable.

(Not sure if the last paragraph of sec. 9.1 already implies the option
MUST be put on all NAs and NSs?  Certainly needs better wording.)

-David

> That said, I'd expect the probability of a host ignoring a new NS option
> is much lower than it filtering out unknown new ICMP (sub)types or UDP
> ports.  If that reduces useless probing (or even waiting), I'm all for
> it.
> 
> (As I understand it, the draft in no case suggests waiting for the
> probes to come back, so it's not much of an argument.  Might still
> reduce useless probe traffic?)