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

On 4/6/16 12:18 PM, David Lamparter wrote:
> On Mon, Apr 04, 2016 at 11:37:17PM +0200, Mikael Abrahamsson wrote:
>> I'll be presenting
>> https://tools.ietf.org/html/draft-van-beijnum-multi-mtu-05 in 6man on
>> Wednesday. There are operational considerations here, so I encourage
>> people to drop in and/or comment on this draft.
> 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.

Note that just like TCP can suppress the need for NUD (per RFC 4861) a 
TCP implementation could also indicate to the IP layer than a packet of 
size X got through, which could be used to suppress the MTU probe. That 
applies independently of what protocol is used to do the MTU probing.
>
> - if possible (not sure on NUD interactions), this should use RFC5082
>    TTL security, sending HL=255 and discarding packets !=255
Yes, it would make sense to use the TTL security approach for the probe 
protocol, whether it is UDP or NUD or something else.
>
> - there's probably a lot of 4821 that can be incorporated by reference,
>    shortening the draft by quite a bit
Are you referring to the choice of sizes to try? I haven't re-read 4861 
next to this draft.
>
> - Mark Townsley's comment about extension headers doesn't make sense to
>    me; we're looking at a single subnet here -- do we really want to
>    support a non-fully-transparent layer 2 bridge messing up the packets?
My understanding is that the muti-mtu draft is for the local link, and 
not for end-to-end.

An observation is that if/where RFC4821 is implemented, then the 
dependency on ICMP PTB is removed. Hence addresses Mark's comment.

>
> - the padding should be specified as "MUST be non-zero" and checksum
>    validation a "MUST";  I've personally seen devices that zero out
>    packets beyond their size limits but still switching them.
Good point.

Regards,
    Erik

>
> - ditch IPv4, but +1 to Mark's "MUST NOT interact/break" room comment
>
>
> Now the hard bit; L2 devices messing with L2 addresses.  The device
> class I have in mind here are 802.11 "client to wired" bridges.  They
> connect to wifi as plain clients and have one or more LAN ports
> supporting multiple devices.  802.11 restricts them to the single MAC
> address their radio has, so what they do is they "MAC-NAT" everything
> behind them.  (They rewrite ARP & ND and have an address table to undo
> it on incoming wireless packets.)
>
> The -05 draft currently says "Neighbors are identified by combination of
> a link address and an IP version".  (NB: IP version, not IP address...)
>
> I believe the better choice here is "Neighbors are identified by their
> IPv6 link-local address".  This removes any possibility for 2 hosts to
> be conflated into a single neighbor even in the presence of 'broken' L2
> devices.
> It also makes clear that for forwarded packets beyond the subnet, the
> mechanism operates on the (host, router) pair and in no way interacts
> with L3 PMTUD or holds state for any global-scope address.  The (host,
> router) pair would establish the maximum possible MTU for packets taking
> that route, from which PMTUD then works downwards.
>
> (Using link-local would introduce other corner cases, particularly if
> the link layer address changes, probe data isn't implicitly
> auto-discarded; this should become an explicit action.  There's probably
> more corners I didn't think of.)
>
>
> -David
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>