I would shy away from drawing that conclusion, given the implementation specifics.
Cheers, Rajiv > -----Original Message----- > From: Rémi Després [mailto:[email protected]] > Sent: Tuesday, February 07, 2012 8:28 AM > To: Rajiv Asati (rajiva) > Cc: Satoru Matsushima; Softwires WG; Wojciech Dec (wdec) > Subject: Re: [Softwires] MAP&4rd-U - DS routing replaced by v6-only routingin > hub&spoke topology > > > Le 2012-02-07 à 14:18, Rajiv Asati (rajiva) a écrit : > > > the 4rd-E case, the BR checks that the source address in the > IPv4 header matches that of the IPv6 address. > > > Could this check (and filtering) be done without incurring a > performance penalty? > > > > Yes indeed.. > Consistency check between source IPv4 address and source IPv6 address is > always part of encapsulation solutions (translation or header-mapping > solutions > are not concerned). > They are needed to avoid introducing vulnerability to spoofing attacks. > > Cheers, > RD > > > > > > > Cheers, > Rajiv > > Sent from my Phone > > On Feb 7, 2012, at 8:03 AM, Rémi Després > <[email protected]> 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. > > > > 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. > > 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 > > _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
