Re: "Deprecate"

[RJ Atkinson <[e-mail]>]

On 02  Aug 2013, at 03:58 , Ronald Bonica wrote:
> Furthermore, we can now make clear that the two following
> statements regarding *New* applications offer practical
> alternatives.
> 
> These are:
> a) PMTUD/PLMTUD
> and b) short PDUs

Agree.  I am reluctant to say that any of those are sufficient
in all deployments, because there are too many IPv6 deployments
to evaluate, but clearly each of those mechanisms can be useful.

> How about:
>    MUST support PMTUD and SHOULD support PLMTUD,
> just in case ICMP PTB is filtered.

Fine.  "MUST support PMTUD" and "SHOULD support PLMTUD".

>> I would change s/MUST NOT/SHOULD NOT/.
>> 
>> I'd delete the phrase "of 1280 bytes" as well, mainly because it is
>> redundant, and partly so that this BCP would not need updating if the
>> 1280 number changed in future.  (It has already changed from
>> unspecified to 576 to 1280 over time.)
> 
> I think that MUST is OK, so long as we are clear that we are talking
> about an application for which IP fragmentation has already been
> ruled out.

I'd like to read the draft text in an I-D first.

> I would say that ICMP PTB messages MUST never be blocked,
> even if the MTU is small. RFC 2460 specifies one corner case
> where the MTU can be small.

Agree.  Fernando has identified some scenarios where the advertised 
MTU will be smaller than 1280.  Additionally, I've seen some other 
real-world scenarios where it happens.

So, I'd suggest that the document outline several scenarios where
the MTU can be small, so that implementers and operators reading
the document will realise that smaller MTUs can appear in the wild.

> Yes. Currently the section on Tunnels contains one word of text,
> "TBD".  I will fix that in the next revision.

From an implementation perspective, most often it is expensive
& complex for a tunnel endpoint reassemble transit fragments.  

In the current global Internet, few router implementers are 
comfortable trying to reassemble anywhere in the middle of the 
path,  in part because of the additional attack surface that
reassembling transit traffic would create.

Instead, at tunnel egress, any fragments are likely to be 
merely decapsulated and then forwarded.  So, it is critical 
that end systems be able to reassemble fragments as fragments 
will continue to exist in the real world.

Yours,

Ran