> 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. 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
