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

From: Xing Li <[email-masked]>
Date: Tue, 02 Feb 2010 06:46:36 +0800

Senthil Sivakumar (ssenthil) 写道:
> 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. "
>   

OK, we will use this in the next uploaded version.

regards,

xing

> 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.
>
> 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
>
>
> Senthil Sivakumar (ssenthil) 写道:
>   
>> 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] 写道:
>>   
>>     
>>> 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.t
>>> x
>>> t
>>>
>>> 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: Xing Li <[email-masked]>
Date: Tue, 02 Feb 2010 06:48:31 +0800

Kentaro Ebisawa 写道:
> 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.
>
>   

OK, we will use your suggested words in the next uploaded version.

regards,

xing

---

From: jouni korhonen <[email-masked]>
Date: Fri, 5 Feb 2010 15:41:35 +0200

Hi,

On Jan 25, 2010, at 12:24 PM, Xing Li wrote:

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

In Section 3.1 it says:

   ...
   If the DF bit is set and the MTU of the next-hop interface is less
   than or equal to the total length value of the IPv4 packet minus 20,
   the translator MUST send an ICMPv4 "Fragmentation Needed" error
   message to the IPv4 source address.
   ...

Am I just reading/understanding this wrong but shouldn't the text say?

   ...
   If the DF bit is set and the MTU of the next-hop interface is less
   than to the total length value of the IPv4 packet plus 20,
   the translator MUST send an ICMPv4 "Fragmentation Needed" error
   message to the IPv4 source address.
   ...

-Jouni

---

From: Xing Li <[email-masked]>
Date: Sat, 06 Feb 2010 07:30:37 +0800

Senthil Sivakumar (ssenthil) 写道:
> 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. 
>   

OK. we will add an appendix containing the work-flow example of
stateless translation. The example of stateful translation is already in
the xlate-stateful document.

regards,

xing

---

From: Xing Li <[email-masked]>
Date: Sun, 07 Feb 2010 13:46:54 +0800

jouni korhonen 写道:

You are correct. Thanks. We will make corrections in the next version.

Regards,

xing

---

From: Jouni <[email-masked]>
Date: Sun, 7 Feb 2010 15:34:17 +0200

Hi Xing,

Thanks! I still think the text in Section 3.1 of -07 needs a bit fixing. The ICMPv4 error message needs to be sent only when the next hop interface MTU is *less* that IPv4 packet size plus 20 bytes. Equal size is ok. So change "less than or equal to the total" -> "less than the total".

-Jouni

---

From: Xing Li <[email-masked]>
Date: Mon, 08 Feb 2010 10:12:18 +0800

> Thanks! I still think the text in Section 3.1 of -07 needs a bit fixing. The ICMPv4 error message needs to be sent only when the next hop interface MTU is *less* that IPv4 packet size plus 20 bytes…

thanks. although this is marginal, we will update to "less than" in the 
next upload. xing