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

[Xing Li <[e-mail]>]

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:[e-mail]] 
> Sent: Wednesday, January 27, 2010 8:04 AM
> To: Senthil Sivakumar (ssenthil)
> Cc: [e-mail]; 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: [e-mail] [mailto:[e-mail]] On 
>> Behalf Of Xing Li
>> Sent: Monday, January 25, 2010 5:25 AM
>> To: [e-mail]
>> 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
>>
>>
>>
>> [e-mail] 写道:
>>   
>>     
>>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/behave
>>>   
>>>     
>>>       
>> _______________________________________________
>> Behave mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/behave
>>
>>
>>   
>>     
>
>
>
>