Re: [Softwires] 4rd Address Mapping - version-01

[Rémi Després <[e-mail]>]

Le 5 oct. 2011 à 03:28, Rajiv Asati (rajiva) a écrit :

>> ability instead of the more general five-tuple based IPv4
>> classification ability should be reserved, when deliver IPv4 over
>> IPv6?
> 
> How would one get 5-tuple based classification when delivering IPv4 "over" IPv6, if the v4 packet is not translated into v6?
> 
> The fact of the matter is that "5-tuple" could be a luxury that may not always be available.

Questions for clarification about 5-tuple-based actions of intermediate nodes that are currently used:
- Do we know whether they generally work with IPv6 packets having extension headers?
- If yes, with which ones?
- In particular, are fragment headers always supported (with ports available only in first fragments)?

Thanks,
RD


> 
> Cheers,
> Rajiv
> 
> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf
>> Of xiaohong deng
>> Sent: Tuesday, October 04, 2011 3:26 AM
>> To: Wojciech Dec (wdec); [e-mail]; [e-mail];
>> [e-mail]; [e-mail]
>> Subject: Re: [Softwires] 4rd Address Mapping - version-01
>> 
>> Hi Remi, Ole, Woj, and all,
>> 
>> I understand the argument of IID bits is resulted from a last minute
>> agreement between 4rd and divi-pd people that having full IPv4 address
>> embedded in the address format helps source based classification, but
>> before we argue that, shall we first make this agreement also be
>> accepted by community wide? As far as current time-being concerned, I
>> don't see a consensus has been reached on this agreement from
>> community wide.
>> 
>> It IMHO would be helpful if anybody would clarify some details to 1)
>> first prove source based classification is either a valid or a
>> non-valid requirement for address mapping; For this regard, I would
>> begin with that why do we think the source based IPv4 classification
>> ability instead of the more general five-tuple based IPv4
>> classification ability should be reserved, when deliver IPv4 over
>> IPv6?
>> 
>> 
>> and 2) then show us how much other efforts are required to achieve so
>> besides address format definition itself, in other words, if it's a
>> valid requirement, let's first have feasibility of this requirement
>> analyzed from both deployment and operational perspectives:
>> 
>> 1. For double translation, how does a traditional router perform the
>> source based IPv4 packet classification on IPv6 (translated from IPv4)
>> packets? Or does it suggest that using IPv6 classification filters to
>> filter IPv4 packets? If so, should we also note that this suggests
>> IPv4 operation and managed are tightly coupled with IPv6 operation and
>> management? which in turn implies complexity in operational, or put in
>> other words, OPEX increasing, the last thing among others that
>> operators would like to see.
>> 
>> 2. For encapsulation, even if embedding source IPv4 addresses in the
>> lower bits of the address formats, where does the router find the
>> source port without de-capsulation? Are you suggesting also encode 16
>> bits port in the lower part of address? In either case, it leads to
>> the concerns of increased OPEX to operators stated above.
>> 
>> Thoughts?
>> 
>> Cheers,
>> Xiaohong
>> 
>>> Hi Qiong,
>>> 
>>> Some fields of a unified address format for double translation and
>>> encapsulation might be unnecessary for hub and spoke, but using the
>>> same format should be advantageous for maintenance and training if for
>>> nothing else (assuming that any added complexity is negligible
>>> enough).
>>> 
>>> Believing that a completely unified format is possible, I mentioned it to
>> Alain.
>>> Also, I volunteered to be editor-coordinator for this to happen, but
>>> decision of who does what is his.
>>> 
>>> Regards,
>>> RD
>>> 
>>> 
>>> Le 4 oct. 2011 à 00:13, Qiong a écrit :
>>> 
>>>> Hi Remi and Wojciech,
>>>> 
>>>> Thanks for your clarification. I fully agree with you that embedding the
>> full IPv4 address in the last 64 bits would be quite helpful for some kind of
>> source address classification and I also suggest that this can be taken in the
>> same way for encapsulation-based approach. It would be easier for systems in-
>> the-middle to identify the IPv4 address without packet decapsulation.
>>>> 
>>>> I guess the thing that Ole has mentioned to "look at 24 bits in the middle
>> of IPv6 address" is for CE to determine whether a downstream IPv6 packet
>> should be taken for translation or native forwarding. Here, for a dual-stack
>> host, there would be no difference in the first /64 bits for a native IPv6
>> packet and a translated packet. What's why the CE should further looking into
>> the last 64 bits to determine the translation process or native forwarding.
>> Maybe Ole can clarify for this part again.
>>>> 
>>>> However, the situation would still be different in "Hub & Spoke" and "Mesh"
>> mode. For Hub & Spoke case, since BR will have a default prefix/address, it
>> would be easily to identify the translated traffic from native IPv6 traffic by
>> just doing source address routing lookup for a downstream packet. So, the
>> corresponding mechanics would be different.
>>>> 
>>>> Thanks
>>>> 
>>>> Best wishes
>>>> 
>>>> Qiong
>>>> 
>>>> 2011/10/3 Wojciech Dec <wdec at cisco.com>
>>>> 
>>>> 
>>>> 
>>>> 
>>>>    On 02/10/2011 02:58, "Qiong" <bingxuere at gmail.com> wrote:
>>>> 
>>>>        Hi Ole and Remi,
>>>> 
>>>>> This is my answer to your first (double) question.
>>>>> If it is not enough, as suggested below, please explain what
>> you don't understand.
>>>> 
>>>>            I specifically do not want a solution that changes forwarding
>> behaviour for _all_ IPv6 packets.
>>>>            e.g. looking at 24 bits in the middle of an IPv6 address is
>> such a change.
>>>> 
>>>>            Woj> What are you referring to? Routing "just works" as normal
>> and is non disaggregated because of the CE-index in the prefix. Classification
>> can/is done on a subset of the v6 address, and that is perfectly legit.
>>>> 
>>>> 
>>>>            I don't understand what requirements you are basing this
>> 'solution' on.
>>>>            if the 4rd / dIVI CE takes (a well known or provisioned) /64
>> prefix out of the delegated prefix. then why do you need any of that?
>>>> 
>>>> 
>>>>        Qiong : I agree that routing lookup for a provisioned /64 prefix
>> would be better that extracting certain bits for each IPv6 address in CE. This
>> would bring less change to existing routing model.
>>>> 
>>>>        Woj> There is no change to the existing destination based routing
>> model. Each CE is uniquely addressed by the CE bits in the top /64 - ie the CE
>> index is as proposed by all the 4rd and divi-pd drafts. The full v4 source
>> address of each CE is however also embedded in the interface-id, as per
>> RFC6052. There appears to be no cost for this operation, and has the upside of
>> the full v4 info visible in the header and allowing source based
>> classification (should one want to do that).
>>>> 
>>>>        Regards,
>>>>        Woj.
>>>> 
>>>>        Best wishes
>>>> 
>>>>        Qiong
>>>> 
>>>>            _______________________________________________
>>>>            Softwires mailing list
>>>>            Softwires at ietf.org
>>>>            https://www.ietf.org/mailman/listinfo/softwires
>>>> 
>>>> 
>>>> 
>>> 
>> _______________________________________________
>> Softwires mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/softwires
>