Subject: [BEHAVE] 2nd WGLC, draft-ietf-behave-v6v4-xlate-09

From: "Dan Wing" <[email-masked]>
Date: Fri, 12 Feb 2010 11:18:31 -0800

** We need at least 5 reviewers to tell us this document is ready 
** for submission to IESG.  Please email [email-masked] 
** with a subject line containing the document name, and "ready 
** to submit to IESG" or "not ready to submit to IESG" in the 
** message body.  If not ready to submit, please propose new text.

This email starts the 2nd WGLC for draft-ietf-behave-v6v4-xlate-09, ending in
one week (Friday, February 19).  For reference, the first WGLC was for
draft-ietf-behave-v6v4-xlate-05.

draft-ietf-behave-v6v4-xlate-09 contains all feedback from the working group
to date, including the feedback based on Ben Stasiewicz's analysis of ICMPv6
behavior on the Internet and the resulting discussion on the mailing list,
which resulted in a new sentence and a new paragraph between -07 and -09.
Differences between 07 and 09 are:

http://tools.ietf.org/rfcdiff?url1=draft-ietf-behave-v6v4-xlate-07.txt&url2=dr
aft-ietf-behave-v6v4-xlate-09.txt

Differences between 05 (first WGLC) and 09 (2nd WGLC) are:

http://tools.ietf.org/rfcdiff?url1=draft-ietf-behave-v6v4-xlate-05.txt&url2=dr
aft-ietf-behave-v6v4-xlate-09.txt

-d

---

From: Dave Thaler <[email-masked]>
Date: Tue, 16 Feb 2010 02:45:24 +0000

Mostly editorial issues, but one substantial issue raised during
the 1st WGLC remains in sections 4.2 and 4.3.

Section 1.2:
> addresses [RFC3307] based on the unicast mapping rule.  However, if  
> multicast address mapping rule is defined, the IP/ICMP header

s/multicast address mapping rule/a multicast address mapping mechanism/

Section 3:
> When IPv4 node performs path MTU discovery (by setting the Don't
      ^
Insert "an"

Section 3.1:
> workflow example of stateless translation is shown in Appendix of
                                                       ^
Insert "the"

Section 3.2:
> Note that if the IPv4 router  
> did not set the MTU field (zero),

s/did not set the MTU field (zero)/set the MTU field to zero/

Section 3.3:
> In addition, the ICMP error  
> messages contain for the packet in error, which needs to be  
> translated just like a normal IP packet.

s/for the/the/

> This process SHOULD  
> stop at first embedded header and drop the packet if it contains  
> more.

s/first/the first/

Section 4:
> On the other hand, the recent study indicates that only 43.46% of

s/the/a/

Section 4.2:

> In this case, the  
> translator can ether do stateful translation or map them to an IPv4  
> address block as a holder for all non IPv4-translatable IPv6  
> addresses in a stateless manner.

s/ether/either/

I don't understand what "map them to an IPv4 address block as a holder"
means.  I don't see anywhere in the doc where this is specified in
more detail, so this is not implementable as currently stated.
We need to either remove this phrase, or else see text that we can
get WG consensus on.  

My preference would be to just remove that possibility and say:

 In this case, the translator can do stateful translation.

However, I'm open to seeing alternative text posted to the list.

Section 4.3:

> In addition, the ICMP error  
> messages contain for the packet in error, which needs to be  
> translated just like a normal IP packet.

s/for the/the/

> In this case, the translator can ether do stateful  
> translation or map them to an IPv4 address block as a holder for all  
> non IPv4-translatable IPv6 addresses.

Same comment as on section 4.2.

Section 4.4:

> If the reason of sending ICMPv6 is due to that the IPv6 source

Suggest:
"If the ICMPv6 error message is being sent because the IPv6 source"

Section 4.6:

> If the IP/ICMP translator also provides normal forwarding function,
                                         ^
Insert "a"

-Dave

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Dan Wing
> Sent: Friday, February 12, 2010 11:19 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [BEHAVE] 2nd WGLC, draft-ietf-behave-v6v4-xlate-09
> 
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: Xing Li <[email-masked]>
Date: Tue, 16 Feb 2010 19:41:55 +0800

Hi, Dave,

Thanks. We will make modifications and upload version 10 after 2nd WGLC.

Regards,

xing, congxiao

---

From: Xing Li <[email-masked]>
Date: Tue, 16 Feb 2010 19:54:35 +0800

Hi, Dave,

> However, I'm open to seeing alternative text posted to the list.
Thanks. Sorry that we did not make our idea clear enough in the draft 
and it is somehow complicated. We will write another draft to discuss 
this issue. For the xlate draft, we would like to say

 In this case, the translator MAY do stateful translation.

BTW, we have discussed this issue in a mail dated Jan 14, 2010 (attached 
here).

Regards,

xing, congxiao

------------------------ cut here -------------------------

>From - Thu Jan 14 16:49:26 2010
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00800000
X-Mozilla-Keys:                                                                                 
Message-ID: <[email-masked]>
Date: Thu, 14 Jan 2010 16:37:44 +0800
From: Xing Li <[email-masked]>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Dave Thaler <[email-masked]>
CC: Dan Wing <[email-masked]>, congxiao <[email-masked]>, 
 Fred Baker <[email-masked]>,
 Xing Li <[email-masked]>
Subject: Re: [BEHAVE] Comments on draft-ietf-behave-v6v4-xlate-05
References: <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi, Dave,

Dave Thaler 写道:
>
>> Section 3.1 discusses the way to translate normal IP packets:
>> (1) When the source address is IPv4-translatable address, do stateless
>> translation.
>> (2) When the source address is non IPv4-translatable address, do the
>> stateful translation.
>>
>> Section 3.2 and 3.3 discuss the way to translate ICMP packets and the
>> ICMP Error packets:
>> (1) If the ICMP packets or ICMP Error packets are generated from the
>> end
>> system,
>> (1.1) For the stateless translation, the source address is the
>> IPv4-translatable address and it can be translated to the IPv4 address.
>> (1.2) For the stateful translation, the source address is any IPv6
>> address, but it should be in the state table for a given session, it
>> can
>> be translated to the IPv4 address.
>> (2) If the ICMP packets or ICMP Error packets are generated from an
>> intermediate router (for example TTL=0)
>> (2.1) For the stateless translation, the source address is usually not
>> the IPv4-translatable address and it can not be translated to the IPv4
>> address.
>> (2.2) For the stateful translation, the source address is usually not
>> in
>> the state table, it can not be translated to the IPv4 address.
>>
>> However, the ICMP message is important for PMTU or trouble shooting, we
>> should use a "IPv4 special block" as the source address for the ICMP
>> packets. This prevents translated ICMP messages from being discarded
>> due
>> to unknown or private IP source address.
>>     
>
> I don't understand why this would be needed.  As 3.1 behavior would do,
> if you get an ICMP error sourced from an IPv6 address that isn't an
> IPv4 translatable address, you can just do stateful transition and treat
> it the same as you would an ICMP session initiated by the sender.
> This seems much simpler than specifying some other special case.
>
> -Dave
>   
Thanks for the comment. The reasons for specifying this special case are:

(1) For the stateful or stateless/stateful translators, it is possible 
to do stateful translation for the ICMP packets. However, for a (pure) 
stateless translator, the translator cannot do the stateful translation. 
The method proposed above can help in this scenario.

(2) It is a waste of global routable IPv4 addresses for the mapping of 
the IPv6 source addresses of the ICMP packets. Since the IPv4 addresses 
are not used for the real communication between IPv4 end system and IPv6 
end system, but rather for the error reporting concerning the network 
problem. In addition, since there is no port number defined in ICMP, the 
sharing of a single IPv4 address for different non IPv4-translatable 
IPv6 addresses is difficult. Comparing with the above method, the 
special IPv4 block (we may define it as a new Well-Known IPv4 block) can 
be reused by different ISPs.

(3) The special IPv4 block actually servers as the holder of non 
IPv4-translatable IPv6 address in the ICMP packets. It can serve as an 
identifier to tell the end user or system administrator that the ICMP 
packets are generated by non IPv4-translatable IPv6 address. On the 
other hand, the stateful translation of the ICMP packets cannot indicate 
that the ICMP packets are generated by non IPv4-translatable IPv6 
addresses, since the IPv4 source addresses of the ICMP packets are 
general IPv4 addresses and there is no way to know the mapping between 
the IPv4 and IPv6 addresses (the states are maintained inside the 
translator).

(4) Generating states trigged by ICMP packets rather than the IP packets 
in the translator may introduce security problems.

Based on the above reasons, we believe that the method proposed above is 
useful not only for the stateless translators, but also useful for the 
stateful translators. However, we are fine to remove it from the current 
xlate document and willing to write a separate draft to document it.

Regards,

xing, congxiao

---

From: Dave Thaler <[email-masked]>
Date: Tue, 16 Feb 2010 16:07:33 +0000

> From: Xing Li [mailto:[email-masked]]
> Sent: Tuesday, February 16, 2010 3:55 AM
> To: Dave Thaler
> Cc: [email-masked]
> Subject: Re: [BEHAVE] 2nd WGLC, draft-ietf-behave-v6v4-xlate-09
> 
> Hi, Dave,
> 
> Dave Thaler 写道:

I don't believe a MAY is appropriate unless it's clear what the
alternative is in the document.  In the above text, it isn't.

Maybe something like:

   In this case, the translator can do stateful translation.
   A mechanism by which the translator can instead do 
   stateless translation is left for future work.

-Dave

> References:
> <[email-masked]
> ploy.ntdev.microsoft.com> <[email-masked]>
> <[email-masked]
> oy.ntdev.microsoft.com>
> In-Reply-To:
> <[email-masked]
> oy.ntdev.microsoft.com>

---

From: Xing Li <[email-masked]>
Date: Wed, 17 Feb 2010 07:39:39 +0800

Hi, Dave,

>    stateless translation is left for future work.

Agree. We will use this sentence in version 10. Thanks!

Regards,

xing

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 16 Feb 2010 21:50:21 -0500

I have a few comments as I review this draft again...others follow later

I'm assuming the purpose of this document is to update (and improve) on
RFC2765 in two dimensions: applicability and translation algorithm itself.

The latter is very clear but the first is not. For example:

* The third paragraph is basically a copy of what is already written in
RFC2765. In the end I thought I was expecting to see a sentence like ...'and
in section Z we discuss how this document solves these issues...'. But it
seems the issues discussed in RFC2765 (and here) are very much still
present. Or does this spec advances anything specific to solve the long-term
scenario of when all Internet is v6 and you need a translator box 'far
away'? 

In section 1.2 "Applicability and Limitations" there is also no discussion
on SIIT 'distant boxes' or whether this is a limitation or not.

But in general I think section 1 is confusing. Maybe due to the many
interactions of the draft. The paragraphs seem disconnected and not really
seems to advance the 'introduction and motivation' in a cohesive fashion.

* The third paragraph under section 1 seems out of place and not actually
adding to the discussion. I think this can be removed without any loss to
the document. Actually I would suggest it makes the introduction clearer.

The motivation IMO seems clear: we need to interoperate v6 and v4. Whether
'distant boxes' are  issue or not seems at best something you could discuss
in some applicability section.

In summary I would suggest similarly to what we did for SFNAT64 an analysis
on how this document improves or not RFC2765 in the applicability section.

Thanks,

Reinaldo

---

From: Xing Li <[email-masked]>
Date: Thu, 18 Feb 2010 19:56:39 +0800

Hi, Reinaldo,

Thanks for your review and comments.

You are right, the current structure of IPv4/IPv6 translation involves 
several drafts and the
scenarios/solution analysis should not be discussed in xlate, which
is for translation algorithm itself. We will delete the unnecessary part 
in section 1 and section 1.2
in the next upload (version 10) after 2nd WGLC.

Regards,

xing