RE: New draft: "IPv6 Source Fragmentation for Link Adaptation Avoidance"

["Templin, Fred L" <[e-mail]>]

Hi Dan,

> -----Original Message-----
> From: Dan Wing [mailto:[e-mail]]
> Sent: Thursday, July 12, 2012 9:01 AM
> To: Templin, Fred L; [e-mail]
> Subject: RE: New draft: "IPv6 Source Fragmentation for Link Adaptation
> Avoidance"
> 
> > -----Original Message-----
> > From: Templin, Fred L [mailto:[e-mail]]
> > Sent: Thursday, July 12, 2012 8:40 AM
> > To: Dan Wing; [e-mail]
> > Subject: RE: New draft: "IPv6 Source Fragmentation for Link Adaptation
> > Avoidance"
> >
> > Hi Dan,
> >
> > > -----Original Message-----
> > > From: Dan Wing [mailto:[e-mail]]
> > > Sent: Wednesday, July 11, 2012 6:10 PM
> > > To: Templin, Fred L; [e-mail]
> > > Subject: RE: New draft: "IPv6 Source Fragmentation for Link
> > Adaptation
> > > Avoidance"
> > >
> > > > -----Original Message-----
> > > > From: [e-mail] [mailto:[e-mail]] On
> > Behalf Of
> > > > Templin, Fred L
> > > > Sent: Thursday, July 05, 2012 11:31 AM
> > > > To: [e-mail]
> > > > Subject: New draft: "IPv6 Source Fragmentation for Link Adaptation
> > > > Avoidance"
> > > >
> > > > Hello,
> > > >
> > > > I have posted a new draft that calls for an update to RFC2460.
> > > > The document proposes to enlist the support of IPv6 hosts in
> > > > offloading the burden carried by links that must perform
> > > > link-specific fragmentation/reassembly per RFC2460, Section 5:
> > > >
> > > >    "IPv6 requires that every link in the internet have an MTU of
> > 1280
> > > >    octets or greater.  On any link that cannot convey a 1280-octet
> > > >    packet in one piece, link-specific fragmentation and reassembly
> > must
> > > >    be provided at a layer below IPv6."
> > > >
> > > > The draft announcement appears below. Please review and send
> > > > comments to the list.
> > >
> > > The draft adds a paragraph to the IPv6 spec which says, effectively,
> > > if an ICMPv6 PTB is received with a certain MTU, the IPv6 host should
> > > try to send packets of that size.
> >
> > The paragraph is asking the host to treat MTU sizes less
> > than 1280 for IPv6 destinations as an indication of the
> > maximum fragment size it should use, and then use IPv6
> > fragmentation when sending future packets to the IPv6
> > destination.
> >
> > > The existing IPv6 specification (RFC2460) and its predecessor
> > (RFC1883)
> > > have an existing paragraph that says something different should
> > happen
> > > when such an IPv6 PTB is received.  The existing text says a 1280
> > > byte packet can be sent, but needs a fragmentation header added.
> >
> > The existing paragraph says: "In response to an IPv6 packet
> > that is sent to an IPv4 destination ..."
> >                    ^^^^
> >
> > > How does a host reconcile those two paragraphs, and know which to
> > > do?
> >
> > My proposed paragraph tells what to do for packets sent
> > to *IPv6* destinations, whereas the existing paragraph
> > tells what to do for packets sent to *IPv4* destinations.
> > So, the destination's IP protocol version is used to
> > reconcile the two paragraphs.
> 
> I can see two ways to detect that -- the NAT64 well known
> prefix or detection with draft-ietf-behave-nat64-discovery-heuristic
> being used to determine if the destination is IPv4 or IPv6.
> Neither of those are in IP stacks today.  That is, existing
> stacks -- if they follow that last paragraph in Section 5
> of RFC2460 at all -- simply treat all destinations the same
> and do not discriminate that it is "an IPv4 destination".
> 
> I could sortof see that working for translators within the
> same administrative domain, where those two techniques
> are viable (those two techniques being WKP and NAT64
> discovery heuristic).
> 
> But translators that are in other networks cannot be
> detected using those techniques.

Thanks for clarifying that. But then, maybe we need to
take a closer look at the final paragraph of Section 5
of RFC2460. It goes on to say that:

   "In that case, the IPv6 node
   is not required to reduce the size of subsequent packets to less than
   1280, but must include a Fragment header in those packets so that the
   IPv6-to-IPv4 translating router can obtain a suitable Identification
   value to use in resulting IPv4 fragments."

But, the IPv6 node has no way of knowing whether the
IPv4 destination is capable of reassembling as much
as 1280, because IPv4 nodes are only required to
reassemble 576 at the minimum. Also, the IPv6
Identification value chosen by the host would not
be fully reflected in the IPv4 Identification value
produced by the translator, since there is no way
to squeeze 32 bits into 16.

So then, maybe what my draft should be shooting for
is a replacement of the final paragraph of Section 5?

Thanks - Fred
[e-mail]

> -d
> 
> > > Or are you proposing to replace the existing paragraph with
> > > the new paragraph?
> >
> > No; keep it as two paragraphs - i.e., leave the existing
> > paragraph alone.
> >
> > Thanks - Fred
> > [e-mail]
> >
> > > -d
> > >
> > >
> > >
> > > > Fred
> > > > [e-mail]
> > > >
> > > > ---
> > > > A New Internet-Draft is available from the on-line Internet-Drafts
> > > > directories.
> > > >
> > > >
> > > > 	Title           : IPv6 Source Fragmentation for Link
> Adaptation
> > > > Avoidance
> > > > 	Author(s)       : Fred L. Templin
> > > > 	Filename        : draft-generic-6man-tunfrag-02.txt
> > > > 	Pages           : 5
> > > > 	Date            : 2012-07-05
> > > >
> > > > Abstract:
> > > >    IPv6 intentionally deprecates fragmentation by routers in the
> > > >    network.  Instead, links with restricting MTUs must either drop
> > each
> > > >    too-large packet and return an ICMP Packet Too Big message or
> > > > perform
> > > >    link-specific fragmentation (also known as "link adaptation") at
> > a
> > > >    layer below IPv6.  This latter category of links is often
> > > >    performance-challenged to accommodate steady-state link-specific
> > > >    fragmentation to the point that it would be highly desirable to
> > push
> > > >    the fragmentation burden back to the IPv6 source.  A common case
> > > > that
> > > >    exhibits these link characteristics is seen for IPv6-within-IP
> > > >    tunnels.  This document therefore proposes an update to the base
> > > > IPv6
> > > >    specification to support link adaptation avoidance.
> > > >
> > > >
> > > > The IETF datatracker status page for this draft is:
> > > > https://datatracker.ietf.org/doc/draft-generic-6man-tunfrag
> > > >
> > > > There's also a htmlized version available at:
> > > > http://tools.ietf.org/html/draft-generic-6man-tunfrag-02
> > > >
> > > > A diff from previous version is available at:
> > > > http://tools.ietf.org/rfcdiff?url2=draft-generic-6man-tunfrag-02
> > > >
> > > >
> > > > Internet-Drafts are also available by anonymous FTP at:
> > > > ftp://ftp.ietf.org/internet-drafts/
> > > >
> > > > _______________________________________________
> > > > I-D-Announce mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/i-d-announce
> > > > Internet-Draft directories: http://www.ietf.org/shadow.html
> > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > > >
> > > >
> > > > -------------------------------------------------------------------
> > -
> > > > IETF IPv6 working group mailing list
> > > > [e-mail]
> > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > > -------------------------------------------------------------------
> > -