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

> -----Original Message-----
> From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]
> Sent: Thursday, July 12, 2012 8:40 AM
> To: Dan Wing; ipv6@ietf.org
> Subject: RE: New draft: "IPv6 Source Fragmentation for Link Adaptation
> Avoidance"
> 
> Hi Dan,
> 
> > -----Original Message-----
> > From: Dan Wing [mailto:dwing@cisco.com]
> > Sent: Wednesday, July 11, 2012 6:10 PM
> > To: Templin, Fred L; ipv6@ietf.org
> > Subject: RE: New draft: "IPv6 Source Fragmentation for Link
> Adaptation
> > Avoidance"
> >
> > > -----Original Message-----
> > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On
> Behalf Of
> > > Templin, Fred L
> > > Sent: Thursday, July 05, 2012 11:31 AM
> > > To: ipv6@ietf.org
> > > 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.

-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
> fred.l.templin@boeing.com
> 
> > -d
> >
> >
> >
> > > Fred
> > > fred.l.templin@boeing.com
> > >
> > > ---
> > > 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
> > > I-D-Announce@ietf.org
> > > 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
> > > ipv6@ietf.org
> > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > -------------------------------------------------------------------
> -