Re: [v6ops] PMTUD issue discussion

[joel jaeggli <[e-mail]>]

On 8/25/14 1:49 PM, Joe Touch wrote:
> Hi, all,
> 
> Speaking from TCPM-land, I would observe the following:
> 
> - PMTUD already has many known problems, which is why PLMTUD is
> recommended instead

I agree, operationally however I'm trying not to break existing devices
attempting to connect to me, is the motivation for the note.

> - the issue here appears to be a device that routes TCP and UDP packets
> based on a hash, but does not apply that hash to the ICMP messages
>     that's clearly an oversight of those devices.
>     ICMP feedback is a known part of the Internet architecture,
>     and any device that demultiplexes packets based on transport
>     info needs to similarly process ICMP messages

If you use source / dest / flow label or even just source / dest you
have the same issue. e.g. using the transport header for hash
computation is not required to induce this.

>     that goes for NATs, load balancers, or anything else.

This requires that I not only be transport aware but be able to parse
into the payload. As noted, the data I would need can probably be found
at a fixed offset (modula extension headers) so in fact that  is
probably feasible.

> I'm not sure what would be added other than to say "we found this
> problem here too". It's a bug that ought to be fixed, but endpoints that
> intend to be robust already know not to rely on ICMP.

I don't disagree with that sentiment.

> Joe
> 
> On 8/25/2014 10:20 AM, Fred Baker (fred) wrote:
>> http://datatracker.ietf.org/doc/draft-v6ops-pmtud-ecmp-problem
>> http://tools.ietf.org/html/draft-v6ops-pmtud-ecmp-problem
>>   "Close encounters of the ICMP type 2 kind (near misses with ICMPv6
>>   PTB)", Matt Byerly, Matt Hite, Joel Jaeggli, 2014-08-24,
>>
>> As requested at IETF 90, Joel has edited and reposted his draft. There
>> are two questions before the house:
>>   - do we want to make this a working group draft?
>>   - what do we want to do next?
>>
>> Note that, by charter, what we are not permitted to do is change
>> implementations or protocols; we are allowed to define operational
>> procedure. That said, we *can* make recommendations to other working
>> groups, asking them to change something.
>>
>> So, for example, we might ask 6man to do something specific, or we
>> might ask tcpm to do something specific. Something specific that we
>> might ask tcpm to do would be to get operational experience with RFC
>> 4821 and commit it back to open source, for example.
>>
>> _______________________________________________
>> v6ops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>