> -----邮件原件----- > 发件人: Rémi Després [mailto:[email protected]] > 发送时间: 2010年1月14日 18:23 > 收件人: Xu Xiaohu > 抄送: 'Mark Townsley'; [email protected] > 主题: Re: [Softwires] Please review 6rd > > > Le 14 janv. 2010 à 11:04, Xu Xiaohu a écrit : > > >> > >> On 1/11/10 7:39 PM, Rémi Després wrote: > >>> > >>> In 9.2, after > >>> "Additionally, a CE MUST allow packets sourced by the configured BR IPv4 > Address" > >>> I suggest to add, for anti spoofing, > >>> ", provided their IPv6 source address doesn't start with the 6rd prefix" > >>> > >> We've had operators interested in at least having the option to send > >> traffic through the BR even for CE sourced traffic from within the same > >> domain. Also, it is useful in some possible transition-to-native > >> scenarios to allow this. So, unless you have an identifiable security > >> concern that this helps to mitigate, I'd rather not add this kind of > >> restriction on the CE (and, it's an extra check, adding to complexity). > > Following a discussion with Mark, who also made this point, and who noted than > without this provision IPv6-address spoofing possibility are still those of > their embedded IPv4 addresses, not less, not more, _I withdraw the proposal_. > Thanks for the comment. > > >>> I will also try to propose something on routing-loop avoidance. > >>> > >> Thanks. Note that I'd rather avoid a detailed discussion on all the > >> looping possibilities (that's fine for the research paper Ole cited, or > >> the slides I put together in Hiroshima, or an Internet Draft on 6rd > >> Operations that I still hope to see some Operators produce, etc.). For > >> this document, I think it is better to keep the text limited strictly to > >> the implementation specification necessary to keep the possibilities of > >> spoofing and looping limited so 6rd cannot be exploited to invoke a > >> serious attack. I think we've captured that already, but please let me > >> know if you think we are missing some important normative language. > > Agreed. > After discussing also this point with Mark, I agree to keep the text on this > subject as is. > > > There was a related discussion about how to avoid routing loops between > > multiple ISATAP routers (See > > http://www.ietf.org/mail-archive/web/softwires/current/msg00857.html). > > Somebody argued that it is not practical for the ISATAP routers to use IPv4 > > address which is unreachable outside the ISATAP domain in some cases. Hence > > I wonder whether the argument is also suitable for the 6rd scenario. > > > > By the way, would it be better for preventing the routing loops if there > > were some well-known bits in the 6rd prefix? > > This would IMHO add complexity, unnecessarily since routing loops are avoided > with the described ingoing and outgoing filters in the BRs.
Sorry for late response. Will this approach of blindly filtering any packet sourced from the BRs drop the normal tunneled packets mistakenly? Xiaohu _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
