[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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:

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
fred.l.templin@boeing.com


-----Original Message-----
From: Templin, Fred L
Sent: Wednesday, August 17, 2005 2:55 PM
To: v6ops@ops.ietf.org
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
fred.l.templin@boeing.com

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.