Re: Use cases for PMTUD and PLPMTUD (was: RE: 6MAN: Adoption call on draft-hinden-6man-rfc1981bis-01)

On 6 February 2016 at 10:06, Mark Andrews <marka@isc.org> wrote:
>
> In message <56B502FB.4050302@si6networks.com>, Fernando Gont writes:
>> On 02/05/2016 04:00 PM, Templin, Fred L wrote:
>> > Hi Fernando,
>> >
>> >> -----Original Message-----
>> >> From: Fernando Gont [mailto:fgont@si6networks.com]
>> >> Sent: Friday, February 05, 2016 10:26 AM
>> >> To: Templin, Fred L; otroan@employees.org
>> >> Cc: Bob Hinden; 6man WG; Fred Baker (fred)
>> >> Subject: Re: Use cases for PMTUD and PLPMTUD (was: RE: 6MAN: Adoption call
>>  on draft-hinden-6man-rfc1981bis-01)
>> >>
>> >> On 02/05/2016 03:13 PM, Templin, Fred L wrote:
>> >>> Starting this under a new thread, IMHO if we want to promote RFC1981 to s
>> tandard
>> >>> we should understand its use cases as well as the use cases for RFC4821.
>> >>>
>> >>> First, it is reasonable to expect that paths that begin and end within th
>> e same
>> >>> well-managed administrative domain can be counted on to deliver the neces
>> sary
>> >>> ICMPs. An example is my employer's corporate network. In that case, tradi
>> tional
>> >>> PMTUD per RFC1981(bis) can be applied alone w/o having to apply RFC4821.
>> >>>
>> >>> On the other hand, paths that lead to Internet destinations cannot be cou
>> nted
>> >>> on to deliver the necessary ICMPs. In that case, RFC4821 provides a mitig
>> ation.
>> >>>
>> >>> But, if we do not believe that there are paths for which traditional PMTU
>> D
>> >>> can still be used safely, then we should be working to deprecate RFC1981
>> >>> instead of making it a standard.
>> >>
>> >> Well, the thing here that you can do RFC1981-only, RFC4821-only, or
>> >> RFC1981/RFC4821 (should I say "dual stack"? :-) ).
>> >>
>> >> With that in mind, one could as well have both RFC1981 and RFC4821 as
>> >> standards, I guess...
>> >>
>> >> But yes, generally speaking, RFC1981-only is certaianly unreliable.
>> >
>> > Except for within well-managed administrative domains where RFC1981-only
>> > is sufficient. They do exist; I am typing this message from within one righ
>> t now.
>>
>> I'd expect 6man to produce protocols that work everywhere, rather than
>> just on some subset scearios...
>
> RFC 1981 works for TCP unless you *deliberately* break it by dropping
> PTB as TCP retries.
>
> RFC 1981 does NOT work in general for UDP.  DNS/UDP is a perfect
> example as it is the responding server that get the PTB and the DNS
> client is trying multiple servers.  Often by the time the server
> is tried again especially when a server is anycast the MTU knowledge
> has been lost.
>

I think the main reason that fragments are dropped by some networks is
that they don't have any upper layer protocol header and port fields
in the payload.

One idea discussed a while ago (on this or the v6ops list) was to
shift fragmentation into the UDP layer, which would mean that every
UDP fragment would have the upper layer protocol header and port
numbers that some people want to look at.

At the time I thought UDP source port 0 could be used to indicate
there are UDP options in the packet, however I found that it actually
means no source port (e.g., protocols like DHCP and SNMP don't use
source ports because both client and server destination ports are well
known.)

I came across this draft by Joe last week, and I was thinking that
that might facilitate UDP layer fragmentation.

"Transport Options for UDP"
https://tools.ietf.org/html/draft-touch-tsvwg-udp-options-02

Fred has also started writing up a draft to shift fragmentation into
the GRE layer:

"GRE Tunnel Fragmentation"
https://tools.ietf.org/html/draft-templin-intarea-grefrag-02

Regards,
Mark.

>> --
>> Fernando Gont
>> SI6 Networks
>> e-mail: fgont@si6networks.com
>> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>>
>>
>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------