On 2012/02/07, at 16:10, Rémi Després wrote: > > Le 2012-02-07 à 15:26, Satoru Matsushima a écrit : > >> On 2012/02/07, at 14:03, Rémi Després wrote: >> >>> >>> Le 2012-02-07 à 13:07, Satoru Matsushima a écrit : >>> >>>> Hi Remi-san, >>>> >>>> On 2012/02/07, at 11:13, Rémi Després wrote: >>>> >>>>> Hello Ole, Tetsuya-san, Wojciech, >>>>> >>>>> In a use case described in the 4rd-U draft (sec 5.3), an ISP replaces its >>>>> dual-stack routing by IPv6-only routing. >>>>> For this, independently from the number of IPv4 prefixes it has to >>>>> support, it uses only one mapping rule. >>>>> (By replacing each IPv4 route by an equivalent IPv6 route, it ensures >>>>> that all customers keep their IPv4 addresses.) >>>>> >>>> >>>> I don't think that it could work as you explained in that section. For >>>> example, the BR would need to check a received packet from a CE whether it >>>> has correct source address in mapping rule or not. It means that the BR >>>> must know all address mappings for CE between IPv4 addresses and IPv6 >>>> prefixes. Is it correct understanding? >>> >>> Ingress filtering of the domain has checked that the IPv6 source starts >>> with the delegated IPv6 prefix, a /112 which includes the IPv4 address. In >>> the 4rd-E case, the BR checks that the source address in the IPv4 header >>> matches that of the IPv6 address. There is therefore no need for the BR to >>> know all IPv4 prefixes. At its IPv4 interface, all received packets start >>> with one of them. At its IPv6 interface, all packets it receives have an >>> embedded address that starts with one of these prefixes. >>> >> >> It looks like that you treat default mapping rule as a basic mapping rule to >> check source address consistency on the BR. It should work, > > Yes, thanks. > >> and the MAP too. > > I don't see that. > The bit that, in 4rd-U hub&spoke, is changed for the CE-to-BR direction has > been included precisely to support this case. > Otherwise, packets sent by a CE to another CE would be routed directly to its > destination, without a detour via a BR. >
I don't think so. I just mention BR behavior here. You mention CE behavior for whether the bit is set or not. > >>>> 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? --satoru > > Cheers, > RD > > > >> >> >> cheers, >> --satoru >> >>> >>> Regards, >>> RD >>> >>> >>> >>>> they can provision each CE individually, and also they are capable to >>>> distribute the default mapping rule since they should install it into the >>>> CEs. In that situation, what's the motivation of why the operator want to >>>> provision with only default mapping rule? >>>> >>>> cheers, >>>> --satoru >>>> >>>>> For this to work, the 4rd-U draft has a bit that, in the hub&spoke case, >>>>> differs between CE-to-BR and BR-to-CE directions. Thus, packets sent to a >>>>> CE take different routes depending on whether sent by a CE or a BR. >>>>> >>>>> I don't see how the equivalent could work with the MAP documents you >>>>> edited. >>>>> Is it that such a use case is out of scope for MAP? >>>>> Or did I miss something? >>>>> >>>>> Cheers, >>>>> RD >>>>> >>>>> _______________________________________________ >>>>> Softwires mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/softwires >>>> >>> >> _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
