Re: [tram] Suresh Krishnan's Discuss on draft-ietf-tram-stun-pmtud-10: (with DISCUSS)

[Dan Wing <[e-mail]>]

Sorry, I just noticed this message.  Filtering problem on my gmail configuration.  See below.

>> 4.1.  Simple Probing Mechanism
>>  
>>    The Simple Probing mechanism is implemented by sending a Probe
>>    Request with a PADDING [RFC5780] attribute over UDP with the DF bit
>>    set in the IP header for IPv4 packets and IPv6 packets without
>>    the Fragment Header included.  A router on the path to the server can
>>   reject this request with an ICMP message or drop it.
>  
> The router could also forward the 'request' (actually, it's just an IP packet as far as the router is concerned, it isn't a "request"), so three things can happen to that packet.
>  
> [FG]. In my opinion this is implicit. Do you think specific language needs to be added? If so, what do you have in mind?

I suppose it's implicit.

> Separately, we all know some routers are configured to strip DF bits (that is, set to zro), and some routers are configured to fragment even if DF=1.  Is there implementation guidance we can give to assist detecting such behavior and learning the real underlying MTU, or should we ignore that routers do this and would interfere with the MTU learned by STUN-PMTUD?
>  
> [FG] We’ve discussed this, and while we agree. we feels this is outside the scope of this document. If you have some (hopefully short) text that may convey this crisply let us know.

Perhaps something like,

  "Note: routers can be configured to clear the DF bit or ignore the DF bit which can be difficult or impossible to detect if reassembly occurs prior to receiving the packet, rendering PMTUD inaccurate."

-d

>  
> -d
>  
> 
> 
>>  
>> 4.2.2.  Receiving an ICMP Packet
>>  
>>    If an ICMP packet "Fragmentation needed" or "Packet Too Big" is received then this is
>>    interpreted as a Probe Failure, as defined in [RFC4821] Section 7.5.
>>  
>> Suresh Krishnan has entered the following ballot position for
>> draft-ietf-tram-stun-pmtud-10: Discuss
>> 
>> 
>> 
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html <https://www.ietf.org/iesg/statement/discuss-criteria.html>
>> for more information about IESG DISCUSS and COMMENT positions.
>> 
>> 
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-tram-stun-pmtud/ <https://datatracker.ietf.org/doc/draft-ietf-tram-stun-pmtud/>
>> 
>> 
>> 
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>> 
>> Section 4.1.x and 4.2.x
>> 
>> Please specify how this simple probing mechanism will work with IPv6. It
>> shouldn't be too difficult to do (cleanup references to the DF bit, use Type 2
>> "Packet Too Big" to identify failures etc.). Similar treatment will be required
>> for the complete probing mechanism as well.
>> 
>> 
>> 
>> 
>> 
>>  
>> _______________________________________________
>> tram mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/tram <https://www.ietf.org/mailman/listinfo/tram>