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

["Dan Wing" <[e-mail]>]

> -----Original Message-----
> From: Templin, Fred L [mailto:[e-mail]]
> Sent: Thursday, July 12, 2012 9:37 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: 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.

Yep.

That problem is also pointed out in draft-ietf-intarea-ipv4-id-update.

That final paragraph in Section 5 of RFC2460 is nearly identical
to the paragraph in its predecssors, RFC1883.  In RFC1883 the
IPv6 minimum MTU was 576 (which matched IPv4's reassembly minimum).
One of the many changes between RFC1883 and RFC2460 was changing
IPv6's minimum MTU from 576 to 1280.  See 
http://tools.ietf.org/rfcdiff?url1=rfc1883.txt&url2=rfc2460.txt#diff0059

I believe this MTU mismatch between IPv6 and IPv4 was not deeply 
considered when RFC2460 was updated from MTU 576 to 1280.  But, 
I wasn't there at the time.  No matter how it occurred, we have 
two immovable objects at this point in time.

> 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.

Sure.  But there is also no encouragement in RFC2460 for
the IPv6 host to try to make the lower 16 bits unique.  

A problem that the IPv6 host cannot overcome is that the IPv4
address might be shared amongst several IPv6 hosts.  This problem
is described in draft-ietf-intarea-ipv4-id-update, and does not
solely affect IPv6->IPv4 translation, but any sort of IPv4
address sharing.  I don't see a way to solve that with stateless
translation.  And solving that at scale with stateful translation
appears to be a significant challenge.

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

That may well help towards fixing the problem identified 
by draft-ietf-intarea-ipv4-id-update related to stateless IPv6/IPv4
translators.  It still won't be a perfect fix, but it can
improve the situation.  Returning an ICMP message back to the
IPv6 node, as draft-generic-6man-tunfrag proposes, hinting that
the IPv4 address is shared, perhaps combined with ways to assign
bits to (what will become) the IPv4 IPID field, might be an
avenue worth considering.  RFC4884 could be used to convey which
fragmentation behavior is desired.

The engineering effort to improve this situation is closely tied
to how severe the problem really is, and how often we hit the
small MTU layer 2 links (that draft-generic-6man-tunfrag is
trying to fix) and how often we hit IPv6/IPv4 translators (that
the last paragraph of Section 5 of RFC2460 is trying to fix, but
doesn't quite handle well with stateless IPv6/IPv4 translators).

Myself, I am frustrated with layer 2 networks that have smaller
than 1500 byte MTUs, because we know anything that looks like
Ethernet succeeds (even if it isn't Ethernet, e.g., WiFi), and
technologies that don't look like Ethernet have enjoyed less
success.  Can we expect those networks to fail in the market,
or to look enough like Ethernet that IP works well on top of 
them, making draft-generic-6man-tunfrag unnecessary?  There
is a similar question for IPv6/IPv4 translators -- will they
persist long enough to make the engineering effort to improve
that last paragraph in Section 5 of RFC2460 worth while, and
will we see deployment in IPv6 hosts while there are still
IPv6/IPv4 translators?

-d

> 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
> > > > > ---------------------------------------------------------------
> ----
> > > -