> -----邮件原件----- > 发件人: [email protected] [mailto:[email protected]] 代 表 > Mark Townsley > 发送时间: 2010年1月12日 4:02 > 收件人: Rémi Després > 抄送: [email protected] > 主题: Re: [Softwires] Please review 6rd > > On 1/11/10 7:39 PM, Rémi Després wrote: > > Mark, > > > > I may have a few more minor points to review with you when we meet as planned, > but the following are for immediate consideration by all. > > > > > > In 7.2, after > > "However, the 6rd IPv4 relay anycast addresses must be advertised in the > service provider's IGP" > > I suggest to add, > > " and, to avoid undesirable traffic in 6rd border relays (BRs), should not > be advertised outside the 6rd domain (see also security considerations in > [section 12])" > > > The major point is that the BR IPv4 address be unreachable outside the > 6rd domain, and this is one way to help restrict that scope. In that > vein, I think it would be OK to recommend this (but its of course not > the only tool at he operators disposal). > > > > 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). > > 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.
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? Best wishes, Xiaohu > > > > > > > > > > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
