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

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

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



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