Got it. Thanks Remi. washam
2011/8/21 Rémi Després <[email protected]>: > Hi Washam, > > Please see below. > > Le 21 août 2011 à 08:01, Washam Fan a écrit : > >> Hi Remi, >> >> Please see inline. >> >>>> 7. in example a in section 6, how come a mapping rule responding to 2 >>>> cpe ipv6 prefix length? cpe will get confused when it did forwarding. >>> >>> CPE prefix lengths may be different. (It is the Domain prefix length that >>> is given in the rule.) >>> This is key to be able to assign port sets of different sizes (including >>> 64K) to different customers (at least when the CPE-cascade option isn't >>> necessary). >> >> Yes. But my concern was, for example, a CPE has the below mapping >> rule, cited from the draft: >> +--------------------+--------------------+-------------------------+ >> | Domain IPv4 prefix | Domain IPv6 prefix | AFTR IPv6 subnet (e.g.) | >> +--------------------+--------------------+-------------------------+ >> | 192.32../12 | 2001:db0::/28 | 2001:db0:aaaa:aaaa::/64 | >> +--------------------+--------------------+-------------------------+ >> >> when the CPE forwards a IPv4 packet whose destincation address is >> within 192.32../12, how the CPE know it will use /48 CE prefix or /52 >> CE prefix? Or the mapping rule implies the CPE should use the same CE >> preifx length as its own delegated prefix? > > Ah, I think I better understand your question now. > > The SRC CPE _doesn't need to know_ the length of the DST CPE IPv6 prefix > length. > If this DST length is 48, the DST IPv6 /64 can contain port-derived bits that > have no effect on the route toward this CPE. (It is reachable at its /48, > irrespective of bits beyond the /48). > The DST CPE simply makes NO USE of these extra bits (except possibly to check > their consistency with the L4 payload). > > Does this answer you question? > > In any case, I believe that a later version of the draft should contain an > explanation of that kind, preferably more detailed. > I will work on that. > > Thanks for your question. > RD > > > > >> >> THanks, >> washam > > _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
