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

[Michael Richardson <[e-mail]>]

[e-mail] wrote:
    > 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.

Yes, but plmtud can only be provided as a service to applications when they
use TCP or SCTP.  It can't find bigger UDP paths at present: that would have
to be built in to the application.  But, the kernel can provide the service
for UDP users by doing the discovery in NUD....
Basically we can run the plpmtud mechanism with NUD in the kernel.

There is another use for this MTU option:  it appears that it is sometimes
possible to run both 802.15.4-2012 (the 127 byte version) and 802.15.4g (the
2K or something byte version) on the same radios.
("802.15.4-2015" includes 802.15.4g, btw, thus the need for a year to be precise)

A 15.4g MAC ought to be able to speak to a -2012 MAC by using all of our 6lowpan
mechanisms, but two 15.4g would like to discover that they don't need to
fragment.  I had *assumed* that the RA MTU option could be used for this, and
was surprised when I read that it wasn't specified for this....

So I'm in favour of having this ND option defined; and I care not if it's a
new number or reuses the RA number.


--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-