Re: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-xlate-03.txt
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-xlate-03.txt
Hi,
Thanks for the comments.
HUANG, JERRY (ATTLABS) 写道:
Some comments on the xlate-03 draft. They are mostly nits but it doesn't
seem like they've been mentioned so here they are:
1. middle of page 4 "Introduction and Motivation" has this regarding
SIIT:
"However, SIIT is not useful in the case when the IPv6 nodes need to
acquire temporary IPv4 addresses from a "distant" SIIT box operated
by a different administration, or require that the IPv6 Internet
contain routes for IPv6-mapped addresses (The latter is known to be a
very bad idea due to the size of the IPv4 routing table that would
potentially be injected into IPv6 routing in the form of IPv4-mapped
addresses.)"
Much of the text is exactly as they appear in RFC 2765 [page 4] except
that the above omits the reason that "...the IPv6 nodes need to acquire
temporary IPv4 addresses from a distant SIIT box...", which was stated
in RFC 2765, is "...when most of the Internet is IPv6 and there are
only small islands of IPv4 nodes". The point is that the limitation is
something that's explained better in the SIIT RFC. Should that be simply
copied over explicitly and acknowledged here? Such as: "However, [RFC
2765] pointed out that when most of the Internet is IPv6....IPv4-mapped
addresses.)"
The scenarios we are discussion in this document are changed from
RFC2765. It is related to general stateless and stateful translations
and the addresses are define in the draft-ietf-behave-address-format
document. We will try to make the text more clear.
There is another comment here. I could not find any definition or
references for "IPv6-mapped addresses" in the above paragraph (and the
original paragraph in RFC 2765). It appears that it is simply a typo in
the original RFC text that was copied over. Should that have been
"IPv4-mapped addresses" instead (here as well as in RFC 2765)? It seems
to fit the context.
The IPv4-mapped addresses is define in RFC5156, we will add the
reference. The other address types (IPv4-converted and IPv4-translatable
addresses) are defined in draft-ietf-behave-v6v4-framework.
2. typo. ' ...due to the IPv4 address deletion problem' in the next
paragraph. Should be '...due to the IPv4 address depletion problem'.
Thanks.
3. Section 2.1 Translating IPv4 Headers into IPv6 Headers, page 9, "Hop
Limit". The text states: [...decrement either the IPv4 TTL (before the
translation) or the IPv6 Hop Limit (after the translation)...check for
zero and send the ICMPv4 "ttl exceeded" or ICMPv6 "hop limit exceeded"
error.] There is no ICMPv4 "TTL Exceed" or ICMPv6 "Hop Limit Exceed"
error, is there? Do we mean "ICMPv4 Time Exceed and ICMPv6 Time Exceeded
error"? Does it make sense to specify only one option (to decrement the
IPv4 TTL and check for zero before translation and send ICMPv4 "TTL
Exceeded")? It doesn't seem to make sense to translate and find out TTL
would be zero and send ICMPv6 "Time Exceeded" which would then need to
translated again into ICMPv4 to send to the IPv4 host.
Well, we think this should be vendor's decision.
Section 3.1 Translating IPv6 Headers into IPv4 Headers, page 16, "Time
to Live", has exactly the same logic, but in the opposite direction.
Should we specify again only to decrement before translation and check
for zero and send ICMPv6 "Time Exceeded"?
Same as above.
4. Section 3.2 Translating ICMPv6 Headers into ICMPv4 Headers, page 18,
discusses translating IP headers inside the ICMP error messages and
states: "...a special block of the IPv4 address can be used to indicate
this phenomenon". This also appears at the end of Section 3.3. Do we
need a new IANA reserved block? The "IANA Considerations" section says
'No'. But what is this special IPv4 block?
The ISP can use their spare IPv4 block or RFC1918 block as a special
block. We may have another document to discuss the mapping as a
representer of general IPv6 addresses and ask IANA for a new block if
that document makes the justification.
5. Section 3.2, page 18, "Echo Request and Echo Reply translation (Type
128 and 129) Adjust the type to 0 and 8, respectively" should be
"...Adjust the type to 8 and 0, respectively".
Thanks.
xing
Thanks,
Jerry
--
Jerry Huang, AT&T Labs, +1 630 719 4389
-----Original Message-----
From: behave-bounces at ietf.org [mailto:behave-bounces at ietf.org] On Behalf
Of Internet-Drafts at ietf.org
Sent: Saturday, October 24, 2009 8:15 AM
To: i-d-announce at ietf.org
Cc: behave at ietf.org
Subject: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-xlate-03.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-03.txt
Pages : 24
Date : 2009-10-24
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-03.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
Behave at ietf.org
https://www.ietf.org/mailman/listinfo/behave
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
