Le 2012-02-07 à 17:35, Satoru Matsushima a écrit : > On 2012/02/07, at 16:46, Rémi Després wrote: > > --snip-- > >>>> >>>>>>> I think that operators who already deploy such dual-stack network is >>>>>>> supposed that they have address mapping table, >>>>>> >>>>>> I would rather suppose that ISPs that have added IPv6-prefix delegation, >>>>>> say /56s, to an existing IPv4 network did it without mixing their IPv6 >>>>>> plan with their IPv4 prefixes. >>>>>> I am ready, however, to look seriously at individual cases where choices >>>>>> were different. >>>>> >>>>> Basically provision MAP CE is based on its delegated IPv6 prefix in >>>>> concept. It is opposed to your case but technically possible. >>>> >>>> >>>>> Now I concern that it requires much complicated CE implementation. >>>> >>>> All what is required is that CEs set an address bit if hub&spoke topology >>>> is required. >>>> >>> >>> So how CE decide to set the bit, and when the CE figure it out? >> >> The CE knows it must set this bit if, and only if, it received at >> initialization a Topology-variant parameter set to Hub&spoke (sec 4.1). >> In this case, the CE sets bit 79 to 1 in IPv6 destination addresses of all >> packets it sends. >> >> BTW, this bit should better, for clarity, be given a name, e.g. bit B >> meaning To-BR bit (or whatever better idea one could propose). I plan to do >> it in the next version. >> > > So you mean that if the hub&spoke bit is set, a CE derives /112 IPv6 prefix > as 4rd end point from IPv4 address which is already assigned.
If the CE is delegated a prefix shorter than /64, it isn't concerned with the To-BR bit. If it is delegated a /112, it finds its IPv4 address inom it. It then must set the To-BR bit, in its outgoing IpV6 destinations, iff the Topology variant is Hub&spoke. > Otherwise, a CE derives its IPv4 address from delegated IPv6 prefix. right? The CE always derives its 4rd prefix from its delegated IPv6 prefix, based on the Mapping rule that has the longest match. RD > > cheers, > --satoru _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
