Le 22 janv. 2010 à 02:39, Xu Xiaohu a écrit : > > >> -----邮件原件----- >> 发件人: Rémi Després [mailto:[email protected]] >> 发送时间: 2010年1月21日 17:51 >> 收件人: WashamFan >> 抄送: Xu Xiaohu; [email protected] >> 主题: Re: [Softwires] routing loop issue//re: Please review 6rd >> >> Le 21 janv. 2010 à 10:31, WashamFan a écrit : >> >>> If 6rd-A and 6rd-B belong to the same 6rd domain, I don't see the > routing >> loops. >> >> This a limit case, but if a BR accepts tunnels toward other BRs of the > same >> domain, an IPv6 Internet host with a spoofed source address can initiate a > loop: >> >> v6dst = v6src = PA.Aa >> >> +------------------------+ >> | ====> | >> | | >> | IPv6 Internet | >> | | >> +------+-----------+-----+ >> | | >> |prefix PA |prefix PA >> +--+--+ +--+--+ >> +---+6rd-A+-----+6rd-B+--+ >> | +-----+ +-----+ | >> | address Aa address Aa | >> | <==== | >> | | >> | IPv4 ISP | >> +------------------------+ >> > > Assuming 6rd-A receives a packet with v6dst = v6src = PA.Aa.x from the IPv6 > Internet, will it forward a tunneled packet (after 6rd encapsulation) whose > IPv4 destination address is itself (i.e., the anycase address Aa)?
In the absence of security check, yes it would forward it. (This is precisely the reason for having, for security, outgoing filters that eliminate all IPv4 destinations that are BR IPv4 addresses). > By the > way, if the strict uRPF is enabled on 6rd-A, the above IPv6 packet should be > dropped before performing 6rd encapsulation. Correct? If IPv6 packets entering a 6rd BR traverses an IPv6 routing function before entering the 6rd function, and if this function has the strict RPF activated, yes you are right: the IPv4 outgoing filter may not include the BR IPv4 address of the BR itself. IMHO, however, including it always may not be, even in this particular configuration, a significant waste. In any case, this remains an implementation choice. RD _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
