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
