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

From: [email-masked]
Date: Mon, 25 Jan 2010 02:15:01 -0800 (PST)

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-06.txt
	Pages           : 28
	Date            : 2010-01-25

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) for both stateless and stateful modes.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-behave-v6v4-xlate-06.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: Xing Li <[email-masked]>
Date: Mon, 25 Jan 2010 18:24:39 +0800

Hi, All,

For draft-ietf-behave-v6v4-xlate-05 during WGLC, we have 4 reviews, many
active discussions on the mailing list and mails to the authors. Thanks
for the reviews and comments. Here is a summary of the main issues
discussed during WGLC.

(1) Discussion if translator is a router (for TTL/Hop-limit handling)
Conclusion: Translator is a router. We made the wording consistent in
different places of the document (in sections 1.4, 2.1, 2.7, 3.1 and
3.6. of the xlate-05)

(2) Discussion if the translator handles TTL/Hop limit before or after
the translation.
Conclusion: Leave it for the implementation.

(3) Handling of nested ICMP error messages.
Conclusion: This process SHOULD stop at first embedded header and drop
the packet if it contains more.

(4) Translating pointer in Parameter Problem
Conclusion: Move Appendix 1 to sections 2.3 and 3.2 of the xlate-05.
Remove ambiguous by setting the pointer value to the first octet of the
specific field if that field contains multiple octets.

(5) What MUST/SHOULD a translator do if the derivation fails for a
source address?
Conclusion: Translator drops the packet which contains illegal source
address.

(6) How to deal with ICMP packets coming from IPv6 addresses that aren't
IPv4-translatable?
Conclusion: 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.

(7) Other technical and editorial comments
We have updated the document based on the suggestions.

We also combined sections 2.2 and 2.6 of the xlate-05, since IPv4 UDP
with checksum zero is a special case of Transport-layer Header Translation.

A general question: Should we add the terminology section in each
document (for example in xlate)? Or list all terminologies in the framework
document (as the current framework does)?

Do we have rough consensus for the above issues? Are there any other
issues?

Regards,

X. Li, C. Bao, F. Baker

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

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Mon, 25 Jan 2010 07:26:43 -0800

Hi Xing,
In one of my previous comment on the earlier draft was to add an example flow and I thought you said you would add it in the future version.
I still don’t see it in the latest version.

Thanks
Senthil

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Xing Li
Sent: Monday, January 25, 2010 5:25 AM
To: [email-masked]
Cc: Behave Chairs
Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-xlate-06.txt

Hi, All,

For draft-ietf-behave-v6v4-xlate-05 during WGLC, we have 4 reviews, many active discussions on the mailing list and mails to the authors. Thanks for the reviews and comments. Here is a summary of the main issues discussed during WGLC.

(1) Discussion if translator is a router (for TTL/Hop-limit handling)
Conclusion: Translator is a router. We made the wording consistent in different places of the document (in sections 1.4, 2.1, 2.7, 3.1 and 3.6. of the xlate-05)

(2) Discussion if the translator handles TTL/Hop limit before or after the translation.
Conclusion: Leave it for the implementation.

(3) Handling of nested ICMP error messages.
Conclusion: This process SHOULD stop at first embedded header and drop the packet if it contains more.

(4) Translating pointer in Parameter Problem
Conclusion: Move Appendix 1 to sections 2.3 and 3.2 of the xlate-05.
Remove ambiguous by setting the pointer value to the first octet of the specific field if that field contains multiple octets.

(5) What MUST/SHOULD a translator do if the derivation fails for a source address?
Conclusion: Translator drops the packet which contains illegal source address.

(6) How to deal with ICMP packets coming from IPv6 addresses that aren't IPv4-translatable?
Conclusion: 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.

(7) Other technical and editorial comments We have updated the document based on the suggestions.

We also combined sections 2.2 and 2.6 of the xlate-05, since IPv4 UDP with checksum zero is a special case of Transport-layer Header Translation.

A general question: Should we add the terminology section in each document (for example in xlate)? Or list all terminologies in the framework document (as the current framework does)?

Do we have rough consensus for the above issues? Are there any other issues?

Regards,

X. Li, C. Bao, F. Baker

[email-masked] 写道:
> 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

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 25 Jan 2010 11:42:39 -0800

(off-list.)

See below. 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Xing Li
> Sent: Monday, January 25, 2010 2:25 AM
> To: [email-masked]
> Cc: Behave Chairs

The new text is this, and is in the "Translating from IPv4 to IPv6" section:

      If the translator gets an illegal source address (e.g. 0.0.0.0,
      127.0.0.1, etc.), the translator SHOULD silently drop the packet.

I suggest adding "(as discussed in Section 5.3.7 of [RFC1812])" to the end of
that sentence.

Can similar text be added to the "Translating from IPv6 to IPv4" section of
behave-v6v4-xlate?  Currently regarding stateless translation it says only:

   Source Address:  In the stateless mode, which is to say that if the
      IPv6 source address is within the range of a configured IPv6
      translation prefix, the IPv4 source address is derived from the
      IPv6 source address per [I-D.ietf-behave-address-format] section
      2.1.  Note that the original IPv6 source address is an IPv4-
      translatable address.

We probably want to also list IPv6 'martian addresses' (::1, for sure; perhaps
others?) should be simply dropped (no ICMP response), as was added for IPv4.

A question:  for debugging/troubleshooting, it seems useful to send an ICMP
when the source IPv6 address is outside the range of configured IPv6
translation prefix(es).  That is, add a sentence like this to the quoted
paragraph above:

  If the IPv6 source address is not within the range of configured IPv6
prefix(es), 
  the translator SHOULD respond with an ICMPv6 Type=1, Code=5 (Destination 
  Unreachable, Source address failed ingress/egress policy).

Thoughts on that idea?

> document (for example in xlate)? Or list all terminologies in 
> the framework document (as the current framework does)?

On that, I don't have a preference.

-d

> > This draft is a work item of the Behavior Engineering for 
> Hindrance Avoidance Working Group of the IETF.
> >
> >

---

From: Xing Li <[email-masked]>
Date: Wed, 27 Jan 2010 21:31:24 +0800

Hi, Dan,

> I suggest adding "(as discussed in Section 5.3.7 of [RFC1812])" to the end of

Modified as in version 07.
> others?) should be simply dropped (no ICMP response), as was added for IPv4.
Agree. Modified as in version 07.

>   Unreachable, Source address failed ingress/egress policy).

Agree. Modified as in version 07.

So the new text reads,

    Source Address:  In the stateless mode, which is to say that if the
      IPv6 source address is within the range of a configured IPv6
      translation prefix, the IPv4 source address is derived from the
      IPv6 source address per [I-D.ietf-behave-address-format] section
      2.1.  Note that the original IPv6 source address is an IPv4-
      translatable address.  If the translator only supports stateless
      mode and if the IPv6 source address is not within the range of
      configured IPv6 prefix(es), the translator SHOULD drop the packet
      and respond with an ICMPv6 Type=1, Code=5 (Destination
      Unreachable, Source address failed ingress/egress policy).

      In the stateful mode, which is to say that if the IPv6 source
      address is not within the range of any configured IPv6 stateless
      translation prefix, the IPv4 source address and transport-layer
      source port corresponding to the IPv4-related IPv6 source address
      and source port are derived from the Binding Information Bases
      (BIBs) as described in [I-D.ietf-behave-v6v4-xlate-stateful].

      In stateless and stateful modes, if the translator gets an illegal
      source address (e.g. ::1, etc.), the translator SHOULD silently
      drop the packet.

Regards,

xing, congxiao

---

From: Xing Li <[email-masked]>
Date: Wed, 27 Jan 2010 21:04:19 +0800

Hi， Senthil,

Thanks for your reply.

Comparing version 05 and version 06
(http://tools.ietf.org/rfcdiff?url2=draft-ietf-behave-v6v4-xlate-06.txt).
In version 05 section 1.3 we have cited

"An implementation example of the stateless translation is summarized in
[I-D.xli-behave-ivi]. "

However, according to the comments we received from the reviewers, we
deleted this sentence. If you think this helps the explanation, we can
add it back.

For a complete example flow, we think xlate may not be the right place
to do so, since the example flow will mainly present the address
translation between IPv4 and IPv6 and the address translation is defined
in address-format document, not xlate.

What should we do?

Regards,

xing

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 27 Jan 2010 09:11:51 -0800

Thanks.
-d

> Sent: Wednesday, January 27, 2010 5:31 AM
> To: Dan Wing
> Cc: [email-masked]; 'Behave Chairs'

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Thu, 28 Jan 2010 08:14:33 -0800

Hi Xing,
My preference is to have an example flow in this document. It helps to visualize and understand. I really don’t understand why it does not belong  
in this draft. 

Thanks
Senthil

-----Original Message-----
From: Xing Li [mailto:[email-masked]] 
Sent: Wednesday, January 27, 2010 8:04 AM
To: Senthil Sivakumar (ssenthil)
Cc: [email-masked]; Behave Chairs
Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-xlate-06.txt

Hi， Senthil,

Thanks for your reply.

"An implementation example of the stateless translation is summarized in [I-D.xli-behave-ivi]. "

However, according to the comments we received from the reviewers, we deleted this sentence. If you think this helps the explanation, we can add it back.

For a complete example flow, we think xlate may not be the right place to do so, since the example flow will mainly present the address translation between IPv4 and IPv6 and the address translation is defined in address-format document, not xlate.

What should we do?

Regards,

xing

Senthil Sivakumar (ssenthil) 写道:
>> http://www.ietf.org/internet-drafts/draft-ietf-behave-v6v4-xlate-06.t
>> x
>> t
>>
>> ---------------------------------------------------------------------
>> -
>> --
>>

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Fri, 29 Jan 2010 08:33:17 -0800

Also noticed this is still present.
Section 3.1 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.  Since IPv4 packets with DF not set will

The "must" above. I was of the impression that you were change the must. Kentaro provided some text that keeps the must but
still conveys the idea.

"If the DF flag is not set and the IPv4 packet will result in an IPv6
   packet larger than 1280 bytes, the packet MUST be fragmented so the
   resulting IPv6 packet (with Fragment header added to each fragment)
   will be less than or equal to 1280 bytes. For example, if the packet
   is fragmented prior to the translation, the IPv4 packets must be
   fragmented so that their length, excluding the IPv4 header, is at
   most 1232 bytes (1280 minus 40 for the IPv6 header and 8 for the
   Fragment header).  The resulting fragments are then translated
   independently using the logic described below. "

Thanks
Senthil

-----Original Message-----
From: Xing Li [mailto:[email-masked]] 
Sent: Wednesday, January 27, 2010 8:04 AM
To: Senthil Sivakumar (ssenthil)
Cc: [email-masked]; Behave Chairs
Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-xlate-06.txt

Hi， Senthil,

Thanks for your reply.

What should we do?

Regards,

xing

---

From: Kentaro Ebisawa <[email-masked]>
Date: Sun, 31 Jan 2010 21:38:39 +0900

Hi Xing,

Thanks for the updated doc.

The chages seems good to me except for the wording in
 "3.1. Translating IPv4 Headers into IPv6 Headers"
which Senthil has pointed out in another e-mail.

I would wait for your response to Senthil and add comment to that thread
if anything.

Regards,
-- 
Kentaro Ebisawa <[email-masked]>

On Mon, 25 Jan 2010 18:24:39 +0800
Xing Li <[email-masked]> wrote:

> [email-masked] ミエオタ: