Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-xlate-01.txt

From: Xing Li <[email-masked]>
Date: Fri, 16 Oct 2009 09:50:39 +0800

Thanks for the info.

Note that the extension-header handling is discussed in other places of 
the document.

> If there is no IPv6 Fragment header, the IPv4 header fields are set
>
> as follows:
>
> Protocol: Next Header field copied from IPv6 header.
>

> If any of an IPv6 hop-by-hop options header, destination options
>
> header, or routing header with the Segments Left field equal to zero
>
> are present in the IPv6 packet, they are ignored i.e., there is no
>
> attempt to translate them. However, the Total Length field and the
>
> Protocol field is adjusted to "skip" these extension headers.
>
> If the IPv6 packet contains a Fragment header the header fields are
>
> set as above with the following exceptions:
>
> Protocol: Next Header value copied from Fragment header.
>
regards,

xing

Xiangsong Cui 写道:
> Hello all,
>
> I'm reading this draft and I have a comment.
>
> In section 3.1 Translating IPv6 Headers into IPv4 Headers,
> for the protocol translation, it says
> "Protocol: Next Header field copied from IPv6 header."
>
> It seems that in the translation procedure, the protocol type
> copying is before the IPv6 extension headers' being ignored.
>
> For the example mentioned in section 4 of [RFC2460],
>
> +---------------+----------------+------------------------
> | IPv6 header | Routing header | TCP header + data
> | | |
> | Next Header = | Next Header = |
> | Routing | TCP |
> +---------------+----------------+------------------------
> The value of Next Header field in IPv6 header is for Routing header.
>
> So, how about changing this sentence to a clearer statement?
> such as "Next Header field copied from IPv6 header if there is no
> IPv6 extension header, or copied from the last IPv6 extension header"...
>
> Regards
> Xiangsong
>
>
> ----- Original Message ----- From: <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, September 09, 2009 5:15 PM
> Subject: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-xlate-01.txt
>
>
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> This draft is a work item of the Behavior Engineering for Hindrance 
>> Avoidance Working Group of the IETF.
>>
>>
>> Title : IP/ICMP Translation Algorithm
>> Author(s) : X. Li, et al.
>> Filename : draft-ietf-behave-v6v4-xlate-01.txt
>> Pages : 24
>> Date : 2009-09-09
>>
>> This document specifies an update to the Stateless IP/ICMP
>> Translation Algorithm (SIIT) described in RFC 2765. The algorithm
>> translates between IPv4 and IPv6 packet headers (including ICMP
>> headers).
>>
>> This specification addresses both a stateless and a stateful mode.
>> In the stateless mode, translation information is carried in the
>> address itself, permitting both IPv4->IPv6 and IPv6->IPv4 session
>> establishment without maintaining state in the IP/ICMP translator.
>> In the stateful mode, translation state is maintained between IPv4
>> address/transport port tuples and IPv6 address/transport port tuples,
>> enabling IPv6 systems to open sessions with IPv4 systems. The choice
>> of operational mode is made by the operator deploying the network and
>> is critical to the operation of the applications using it.
>>
>> Significant issues exist in the stateless and stateful modes that are
>> not addressed in this document, related to the address assignment and
>> the maintenance of the translation tables, respectively. This
>> document confines itself to the actual translation.
>>
>> Acknowledgement of previous work
>>
>> This document is a product of the 2008-2009 effort to define a
>> replacement for NAT-PT. It is an update to and directly derivative
>> from Erik Nordmark's [RFC2765], which similarly provides both
>> stateless and stateful translation between IPv4 [RFC0791] and IPv6
>> [RFC2460], and between ICMPv4 [RFC0792] and ICMPv6 [RFC4443]. The
>> original document was a product of the NGTRANS working group.
>>
>> The changes in this document reflect five components:
>>
>> 1. Redescribing the network model to map to present and projected
>>
>> usage [I-D.ietf-behave-v6v4-framework].
>>
>> 2. Moving the address format to the address format document
>>
>> [I-D.ietf-behave-address-format], to coordinate with other drafts
>>
>> on the topic.
>>
>> 3. Describing both stateful and stateless operation.
>> 4. Some changes in ICMP.
>>
>> 5. Updating references.
>>
>> Requirements
>>
>> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>> document are to be interpreted as described in RFC 2119.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-behave-v6v4-xlate-01.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>>
>
>
> -------------------------------------------------------------------------------- 
>
>
>
>> _______________________________________________
>> Behave mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/behave
>>
>
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>
>

---

From: Xiangsong Cui <[email-masked]>
Date: Fri, 16 Oct 2009 14:02:54 +0800

Thanks for your detailed explanation,
I find the "skip" adjustment in the document.

Regards
Xiangsong