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

[Xing Li <[e-mail]>]

于 2011/10/5 3:28, Rajiv Asati (rajiva) 写道:
>> 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?

Yes, this is why we need the whole IPv4 address plus port ID in the IPv6 
address. xing

> The fact of the matter is that "5-tuple" could be a luxury that may not always be available.


> 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
> _______________________________________________
> Softwires mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/softwires
>
>