[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: "Link Adaptation for IPv6-in-IPv4 Tunnels" as WG item?
Fred,
Thank you for the feedback. It looks like you have identified
an issue regarding the proposed use of fragment offset bits.
The intention is not to re-write IPv4 fragmentation/reassembly
but rather to aviod it and perform link adaptation (i.e.,
segmentation/reassembly) at a "layer 2.5" that sits above
IPv4 but below IPv6. So, instead of (re)using the IPv4 header
bits as currently specified, a small (8 bytes or less) L2.5
header that sits above the IPv4 header could be defined with:
- a segment ID field (i.e., instead of using the
fragment offset bits as in the current draft)
- a "more fragments" bit
- flow identifier fields
- a next header field
- etc.
About packet reordering, there are some words about that
throughout the document and also in the 4th paragraph of
Appendix A. But, along with the new L2.5 header described
above, the document could be re-worded to say that the IPv4
Identification field carries an ID used to protect against
packet splicing errors due to reordering. (Idea is to have
all L2.5 segments of the same L3 packet encode the same ID
value in the Identification field of the IPv4 header.)
About the checksum, it is encoded as a trailing 4-byte field
immediately following the upper layer payload, i.e., it occurs
as the final 4 bytes of the final segment in multi-segment
datagrams rather than in a header field of some sort.
Fred
fred.l.templin@boeing.com
> -----Original Message-----
> From: Fred Baker [mailto:fred@cisco.com]
> Sent: Friday, August 26, 2005 8:52 AM
> To: Templin, Fred L
> Cc: Lindqvist Erik Kurt; v6ops@ops.ietf.org
> Subject: 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.
> >
>