On Wed, Oct 5, 2011 at 9:56 AM, Rémi Després <[email protected]> wrote: > > 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)?
Curious and look forward to clarifications to above too. Thanks, Xiaohong > > Thanks, > RD > > >> >> Cheers, >> Rajiv >> >> >>> -----Original Message----- >>> From: [email protected] [mailto:[email protected]] On >>> Behalf >>> Of xiaohong deng >>> Sent: Tuesday, October 04, 2011 3:26 AM >>> To: Wojciech Dec (wdec); [email protected]; [email protected]; >>> [email protected]; [email protected] >>> 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 >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/softwires >> > _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
