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

[[e-mail]]

In general I'd prefer that we reuse existing mechanisms for path mtu discovery, and not invent new ones purely for the case of two directly connected neighbors.

Could we make this work by adding the RFC4861 MTU option to NS/NA messages, and require that PLMTUD probing is used to verify the end to end MTU.

Then the mechanism used is the same for directly connected neighbors and off-link neighbors (apart from the initial discovery).

If we were to invent new probing mechanisms, I would hope we did so under the PLMTUD (4821) umbrella.
Best regards,
Ole

> On 06 Apr 2016, at 19:04, David Lamparter <[e-mail]> wrote:
> 
> 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?)
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------