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

From: "HUANG, JERRY (ATTLABS)" <[email-masked]>
Date: Thu, 5 Nov 2009 15:31:39 -0500

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.)"

  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.

2. typo. ' ...due to the IPv4 address deletion problem' in the next
paragraph. Should be '...due to the IPv4 address depletion problem'. 

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. 

  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"? 

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? 

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,
Jerry
--
Jerry Huang, AT&T Labs, +1 630 719 4389
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Saturday, October 24, 2009 8:15 AM
To: [email-masked]
Cc: [email-masked]
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.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 06 Nov 2009 15:08:59 +1300

Could we have an explicit list of the differences from SIIT?
Maybe this would fit naturally in section 1.2.

Also in section 1.2:

>    Fragmented IPv4 UDP packets that do not contain a UDP checksum (i.e.
>    the UDP checksum field is zero) are not of significant use over wide-
>    areas in the Internet and will not be translated by the IP/ICMP
>    translator [Miller].

That is a pretty old reference. We have some more recent data,
e.g. Dongjin Lee's data:
http://www.ietf.org/mail-archive/web/behave/current/msg06856.html

(It doesn't change the conclusion, and the fact that the result is stable
over a number years makes it stronger.)

> 2.1.  Translating IPv4 Headers into IPv6 Headers
> 
>    If the DF flag is not set and the IPv4 packet will result in an IPv6
>    packet larger than 1280 bytes the IPv4 packet MUST be fragmented
>    prior to translating it.  

draft-defeche-ipv6-traffic-in-p2p-networks-00.txt seems to tell us that
this will be a very common case, which has engineering implications.
I don't think there is any choice, however.

    Brian

---

From: Xing Li <[email-masked]>
Date: Fri, 06 Nov 2009 22:30:18 +0800

Hi,

Thanks for the comments.

> 2765] pointed out that when most of the Internet is IPv6....IPv4-mapped

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.

> "IPv4-mapped addresses" instead (here as well as in RFC 2765)? It seems
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.

> paragraph. Should be '...due to the IPv4 address depletion problem'. 

Thanks.
> translated again into ICMPv4 to send to the IPv4 host. 

Well, we think this should be vendor's decision.
> for zero and send ICMPv6 "Time Exceeded"? 

Same as above.

> '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.
> "...Adjust the type to 8 and 0, respectively".

Thanks.

xing

> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>
>
>

---

From: Xing Li <[email-masked]>
Date: Fri, 06 Nov 2009 22:31:47 +0800

> Maybe this would fit naturally in section 1.2.

We will try to have a list.
Thanks.

> I don't think there is any choice, however.

Agree.

xing

---

From: Simon Perreault <[email-masked]>
Date: Sat, 07 Nov 2009 00:29:19 +0800

Xing Li wrote:
>> Does it make sense to specify only one option (to decrement the

Indeed. Our implementation does it before translation. The spec doesn't
need to be changed for what amounts to an implementation detail.

Simon
-- 
DNS64 open-source   --> http://ecdysis.viagenie.ca
STUN/TURN server    --> http://numb.viagenie.ca
vCard 4.0           --> http://www.vcarddav.org

---

From: "HUANG, JERRY (ATTLABS)" <[email-masked]>
Date: Fri, 6 Nov 2009 11:41:01 -0500

-----Original Message-----
>From: Xing Li [mailto:[email-masked]] 
>Sent: Friday, November 06, 2009 8:30 AM

My point was that the relevant text (both in the draft and in RFC 2765)
uses "IPv6-mapped addresses" 
(not "IPv4-mapped addresses") in that one place. "IPv4-mapped" is well
understood.  I was wondering
whether that was just a typo in both documents. Perhaps both should have
been "IPv4-mapped addresses".

Jerry Huang

---

From: Xing Li <[email-masked]>
Date: Sat, 07 Nov 2009 10:33:18 +0800

HUANG, JERRY (ATTLABS) 写道:
>>> 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
>   
>>> "IPv4-mapped addresses" instead (here as well as in RFC 2765)? It
>>>       
> seems
>   
>>> to fit the context.
>>>   
>>>       
>> reference. The other address types (IPv4-converted and
>>     
> IPv4-translatable 
>   

It is just a typo. Thank you very much for the correction. xing