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

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 5 Jul 2012 11:30:57 -0700

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.

Fred
[email-masked]

---
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
[email-masked]
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

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 11 Jul 2012 18:09:31 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Templin, Fred L
> Sent: Thursday, July 05, 2012 11:31 AM
> To: [email-masked]
> Subject: New draft: "IPv6 Source Fragmentation for Link Adaptation
> Avoidance"
> 
> Hello,
> 

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

How does a host reconcile those two paragraphs, and know which to
do?  Or are you proposing to replace the existing paragraph with 
the new paragraph?

-d

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 12 Jul 2012 08:40:09 -0700

Hi Dan,

> From: Dan Wing [mailto:[email-masked]]
> Sent: Wednesday, July 11, 2012 6:10 PM
> To: Templin, Fred L; [email-masked]
> Subject: RE: New draft: "IPv6 Source Fragmentation for Link Adaptation
> Avoidance"
> 

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. 

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

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

> 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

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 12 Jul 2012 09:00:39 -0700

> From: Templin, Fred L [mailto:[email-masked]]
> Sent: Thursday, July 12, 2012 8:40 AM
> To: Dan Wing; [email-masked]

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

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 12 Jul 2012 09:37:07 -0700

Hi Dan,

> Sent: Thursday, July 12, 2012 9:01 AM

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

> > > > 	Title           : IPv6 Source Fragmentation for Link
> Adaptation
> > > > Avoidance

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 12 Jul 2012 10:58:46 -0700

> Sent: Thursday, July 12, 2012 9:37 AM
> > > > >    "IPv6 requires that every link in the internet have an MTU
> of
> > > 1280
> > > > >    packet in one piece, link-specific fragmentation and
> reassembly
> > > must
> 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

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.

> 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

> > > > > A New Internet-Draft is available from the on-line Internet-
> Drafts
> > > > > directories.
> > > > >
> > > > >
> > > > >    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
> > > > >    fragmentation to the point that it would be highly desirable
> to
> > > push
> > > > >    the fragmentation burden back to the IPv6 source.  A common
> case
> > > > > that
> > > > >    tunnels.  This document therefore proposes an update to the
> base
> > > > > IPv6
> > > > > ---------------------------------------------------------------
> ----
> > > -
> > > > > Administrative Requests:
> https://www.ietf.org/mailman/listinfo/ipv6
> > > > > ---------------------------------------------------------------
> ----
> > > -

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 12 Jul 2012 13:02:10 -0700

Hi Dan,

> will we see deployment in IPv6 hosts while there are still

About this, one thing I think we can agree on is that the
value 1280 is in no way significant to IPv4 nodes. So, the
final paragraph in Section 5 of RFC2460 might just as well
be adjusted to say that the node is not required to reduce
the size of its subsequent packets to less than 1500 bytes
(not 1280).

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 12 Jul 2012 14:01:08 -0700

Hi Dan,

> will we see deployment in IPv6 hosts while there are still

One other thing to note is that, while IPv6/IPv4 translators
may not be around long enough to matter, IPv6-over-IP tunnels
will be around for the long term. And, encapsulation always
reduces the size of the available MTU (to (1500-HLEN) in the
case of Ethernet).

Since even ICMPv6 PMTUD messages may be lost, and since
Ethernet MTUs prevail, we really need to find a way to
get tunnels to configure an MTU of 1500 or larger. That
is the problem space that draft-generic-6man-tunfrag is
addressing.

Thanks - Fred