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: [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
