Tore,
Thanks for these very actionable comments. I will address them in the next
draft version.
Ron
> -----Original Message-----
> From: Tore Anderson [mailto:t...@fud.no]
> Sent: Saturday, June 22, 2013 5:29 AM
> To: Ronald Bonica
> Cc: ipv6@ietf.org 6man-wg
> Subject: Re: FW: New Version Notification for draft-bonica-6man-frag-
> deprecate-00.txt
>
> * Ronald Bonica
>
> > [draft-bonica-6man-frag-deprecate]
>
> Being an operator I would definitively welcome getting rid of the
> complexities dealing with IPv6 fragments bring. That said, the draft
> needs additional discussion on this could be accomplished without
> breaking assumptions made by other protocols, though.
>
> On my network, I have two legitimate consumers of IPv6 fragments:
>
> 1) OSPFv3. RFC 2740 A.1 says <OSPF does not define a way to fragment
> its protocol packets, and depends on IPv6 fragmentation when
> transmitting packets larger than the link MTU>. It does goes on to say
> <the OSPF packet types that are likely to be large [...] can usually be
> split into several separate protocol packets, without loss of
> functionality. This is recommended; IPv6 fragmentation should be
> avoided whenever possible>.
> In my experience however, the implementation vendors appears to have
> skipped over that last recommendation.
>
> 2) SIIT (RFC 6145). There are several corner cases where a SIIT
> translator, or an IPv6 node communicating with an IPv4 node through
> such a translator, have to deal with IPv6 fragments. In particular:
>
> - When a SIIT translator receives an IPv4 packet with DF=0 that would
> result in an IPv6 packet that would exceed the IPv6 link MTU, it will
> split the original packet into IPv6 fragments.
>
> - When a SIIT translator receives an IPv4 fragment, it will translate
> this into one or more IPv6 fragments.
>
> - When the SIIT translator receives an IPv4 packet with DF=0 it <SHOULD
> always include an IPv6 Fragment Header to indicate that the sender
> allows fragmentation>. (I wouldn't miss this feature going away though,
> as I disable it anyway.)
>
> - When an IPv6 node receives an ICMPv6 Packet Too Big message
> indicating a Path MTU less than 1280, it should either 1) simply heed
> the indicated Path MTU, or 2) limit the size of subsequent transmitted
> packets to 1280 and include a Fragmentation header (w/MF=0, i.e., an
> "atomic" fragment) in them. See RFC 2460 section 5. I know that Linux
> takes this second approach, at least.
>
> I cannot support your draft until it discusses or provides solutions
> for the above considerations.
>
> Finally I'll note that in all of the above cases, the use of IPv6
> fragments is limited to within a single administrative domain (i.e., my
> network), so the rationale that IPv6 fragmentation does not work over
> the Internet does not really apply.
>
> Best regards,
> Tore Anderson
>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
