Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop

[Joe Touch <[e-mail]>]

How does that differ substantively from RFC 4821's advice? See esp. Sec. 
8 of that doc, which seems just as accurate for the current situation.

Joe

On 10/28/2012 11:51 PM, Lorenzo Colitti wrote:
> On Mon, Oct 29, 2012 at 5:08 AM, Mark Smith <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     I don't really disagree with that either, it's more that
>     fragmentation is a current capability of IPv6, so I think the IETF's
>     recommendation should be that it is enabled by default on the
>     Internet. I think that recommendation fits the robustness principle
>     too - "..., be liberal in what you accept from others".
>
>     If the IETF recommends against forwarding fragments, then I think
>     that creates the obligation to provide advice and methods on what do
>     instead,
>     which might include specifying a standardised UDP fragmentation
>     method, and provide alternative methods for protocols that utilise
>     IP layer
>     fragmentation.
>
>     Fragments may still be in use, however they may not used much at the
>
>     application layer. OSPFv2 and OSPFv3 uses them instead of
>     implementing it's own fragmentation mechanism (and that may be
>     across multiple hops in the case of a OSPF virtual link), and they
>     are likely to be commonly used in IPsec and GRE tunnels (PMTUD
>     across the tunnel path and having the tunnel MTU adjusted to it is a
>     more advanced capability).
>
>
> Ok, so how about stating the following, then?
>
> 1. Fragments are unreliable on the Internet today.
> 2. If you're an application developer and your apps need to run on the
> Internet, then fragments will likely not work in many cases. If you want
> your application to work in these cases, you should either use
> application-layer fragmentation, use path MTU discovery, or limit
> yourself to small packets instead of sending fragments.
> 3. If you control the network (e.g., if you're the network operator),
> and want to use fragments for tunnels or other purposes, go ahead, but
> note that in other people's networks, they might be filtered.
>
> Your suggestion of providing a generic UDP segmentation mechanism is a
> fine idea, and one that we discussed before this draft was written, but
> our feeling was that such a solution would be impossible to agree on
> until we have a problem statement. This draft ("FYI: some operators
> filter fragments. Keep that in mind.") was supposed to be the problem
> statement.
>
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>