Subject: "Link Adaptation for IPv6-in-IPv4 Tunnels" as WG item?

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 25 Aug 2005 16:12:19 -0700

Hello Fred and Kurt,

On 8/17/05, I announced a new I-D on the v6ops list which (IMHO)
identifies operational issues and proposes improvements for tunnel
path mtu determination. Some on-list discussion followed.

I would like to now ask whether this work can be taken as a
v6ops WG item, given that it addresses operational aspects
of mechanisms associated with the wg?

Fred L. Templin
[email-masked]

-----Original Message-----
From: Templin, Fred L 
Sent: Wednesday, August 17, 2005 2:55 PM
To: [email-masked]
Subject: New draft: "Link Adaptation for IPv6-in-IPv4 Tunnels" 

A new draft of possible interest to v6ops is available
that anticipates MTU-related performance issues for
tunnels and proposes a solution. Document location
and abstract appear below. Comments?

Fred
[email-masked]

http://www.ietf.org/internet-drafts/draft-templin-linkadapt-00.txt

Abstract
   IPv6-in-IPv4 tunneling mechanisms support the minimum IPv6 MTU of
   1280 bytes via static prearrangements at the tunnel encapsulator
   and/or dynamic MTU determination based on ICMPv4 messages, but these
   methods have known operational limitations.  This document proposes a
   new MTU determination mechanism for IPv6-in-IPv4 tunnels that uses a
   link adaptation scheme with simplified IPv4 segmentation/reassembly
   and dynamic segment size probing.

---

From: Fred Baker <[email-masked]>
Date: Fri, 26 Aug 2005 08:51:30 -0700

Let me see first if I understand the protocol you are proposing.

My simple network diagram is:

       +--------+                            +--------+
       |   6A   |                            |   6B   |
       +---+----+                            +----+---+
           |  IPv6                         IPv6   |
      /----+-----------+-----/   /-----+----------+----/
                       |               |
                   +---+----+     +----+---+
                   |  4A    |     |   4B   |
                   +---+----+     +----+---+
                       |   IPv4        |
                  /----+---------------+----/

6A is sending IPv6 datagrams to 6B through the IPv4-only domain  
containing 4A and 4B. The means by which 4A determines 4B is not  
specified, but one might suggest that the tunnel is preconfigured and  
routing determines it through its mechanisms.

So 6A sends IPv6 datagrams up to 9180 bytes in size, through a route  
containing 4A. 4A breaks the 9180 byte datagram up into 7 1280 byte  
segments plus a final 220 byte segment. It encapsulates the 8  
segments into 8 successive tunnel datagrams, and uses the flags field  
to indicate that the IPv4 packet represents a single fragmented IPv4  
datagram, but uses the IPv4 fragment offset field to indicate that  
they represent the blocks starting at bytes 0, 8, 16, 24, 32, 40, 48,  
and 56 of that datagram.

Since the IPv4 implementation in 4B will reassemble the IPv4 datagram  
before attempting to interpret it (per RFCs 791, 1122, and 1812) or  
delivering it to anyone else to interpret, this last statement is a  
matter of some concern. 4B must implement a modified IPv4 reassembly  
algorithm, and it is not clear that there is a way in the IPv4 header  
to identify the packets to which that algorithm should be applied.

The specification also expects that the data crossing the IPv4 domain  
will not be reordered. That is not per the Internet Architecture,  
which presumes a best effort service. The term "Best Effort"  
describes a network in which packets may be reordered, duplicated, or  
dropped at the network layer, and as a result higher layer protocols  
must provide coping mechanisms for these issues, not legislate them  
away.

One thing that wasn't clear to me: where does the Fletcher Checksum  
get stored? I didn't see a specification for the protocol header  
containing that field.

With that commentary, now I will return to your administrative  
question. I would say that this is not describing an operational  
procedure, but a protocol between IPv6-in-IPv4 tunnel endpoints. Our  
charter reads:

         4. Publish Informational or BCP RFCs that identify and analyze
         solutions
         for deploying IPv6 within common network environments, such as
         ISP Networks, Enterprise Networks, Unmanaged Networks (Home/ 
Small
         Office), and Cellular Networks.

         These documents should serve as useful guides to network
         operators and users on possible ways how to deploy IPv6  
within their
         existing IPv4 networks, as well as in new network  
installations.

         These documents should not be normative guides for IPv6  
deployment,
         and the primary intent is not capture the needs for new  
solutions,
         but rather describe which approaches work and which do not.

         IPv6 operational and deployment issues with specific  
protocols or
         technologies (such as Applications, Transport Protocols,  
Routing
         Protocols, DNS or Sub-IP Protocols) are the primary  
responsibility of
         the groups or areas responsible for those protocols or  
technologies.
         However, the v6ops WG may provide input to those areas/ 
groups, as
         needed, and cooperate with those areas/groups in reviewing  
solutions
         to IPv6 operational and deployment problems.

I would understand that we are authorized to provide commentary to  
some other working group regarding such a protocol, but not to  
develop it ourselves.

If I am misunderstanding anything, please advise.

On Aug 25, 2005, at 4:12 PM, Templin, Fred L wrote:

> I would like to now ask whether this work can be taken as a v6ops  
> WG item, given that it addresses operational aspects of mechanisms  
> associated with the wg?
>
>
> Fred L. Templin