Hi Fred, On Tue, 12 Jan 2010 23:31:42 -0800 Fred Baker <[email protected]> wrote:
> My initial sense... for SPF-based protocols (OSPF/IS-IS) it actually > makes little difference whether they do or don't. If they are > forwarding directly to host in their subnet (my preferred term for > what Ole calls a LAN), and only the router beyond them is advertising > the prefix, they will in the normal case be the router en route to the > advertising router. As such, while it is possible to construct > exception cases, For SPF-based protocols it is sufficient of only the > router they learned it from advertises the prefix. > > Distance vector protocols like RIP are a different case because we now > have to put a funny case in them - "if I learned it from another > router in the subnet but I am in the same subnet, ..." In distance > vector protocols, yes, they should advertise it away from the subnet. > I should have qualified my thoughts. My concern was a security one - it'd probably be possible to inject a large number of malicious RAs with differing prefixes. I think having 'learning' routers not inject those prefixes into IGPs or EGPs automatically would prevent the consequences off the attack from propagating past the local subnet. Of course that's a threat we have today, which we mitigate with authenticated routing information, so only learning and using prefixes from trusted peer routers' RAs would overcome my concern. In the likely residential CPE context of what Ole raised, having residential end-users being capable of setting up trust relationships between routers might be a bit of an ask unfortunately. > On Jan 12, 2010, at 11:16 PM, Mark Smith wrote: > > > On Tue, 12 Jan 2010 21:07:53 -1000 > > Ralph Droms <[email protected]> wrote: > > > >> Ole - I have a problem with some of the terminology in the > >> requirements: specifically, the use of "LAN" is ambiguous and should, > >> I think, be replaced with some more specific like "to all links on > >> which the device has an active interface". > >> > >> One issue with this mechanism is what to do if the "ULA-router" > >> flaps? Will another router begin to advertise a new ULA? Will the > >> original router honor the new ULA and refrain from advertising its > >> own > >> ULA when it comes back up? All of which leads to a "ULA-flap" in the > >> subscriber network, which seems like a bad event. > >> > > > > IIRC, Appletalk did this sort of thing, with "seed" routers etc. It > > might be worth seeing if it dealt with these sorts of situations, and > > how. > > > > Another related issue, although not so much of one with small > > residential/SOHO offices, is if a router configures it's local > > interface with prefixes in other routers' RAs, should the learning > > router then automatically announce those prefixes into any IGPs or > > EGPs > > its operating? I think Appletalk did, however these days I'd think > > it'd > > be better not to. > > > > Regards, > > Mark. > > > >> - Ralph > >> > >> On Jan 12, 2010, at 7:50 AM 1/12/10, Ole Troan wrote: > >> > >>> hi, > >>> > >>> a question arose from work I'm doing with the BBF and their CPE > >>> requirements document (TR-124/WT-192). an issue has been raised with > >>> regards to a requirement about CPE routers automatically offering > >>> ULA addresses on the LAN. in the case of multiple CPE routers on a > >>> link, the suggestion is the following two requirements: > >>> > >>> LAN.ADDRESSv6. 3 The device MUST send a Router Solicitation to > >>> the > >>> LAN, to determine if there > >>> are other routers > >>> present. MUST > >>> LAN.ADDRESSv6. 4 If the device determines other routers are > >>> present > >>> in the LAN, and that another > >>> router is advertising > >>> a ULA prefix, the device MUST be configurable to > >>> automatically use > >>> this information to decide not to advertise its own > >>> ULA prefix. MUST > >>> > >>> any opinion on these requirements and how they compare with expected > >>> behavour as specified in RFC4861? > >>> > >>> cheers, > >>> Ole > >>> -------------------------------------------------------------------- > >>> IETF IPv6 working group mailing list > >>> [email protected] > >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >>> -------------------------------------------------------------------- > >> > >> -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list > >> [email protected] > >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >> -------------------------------------------------------------------- > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > [email protected] > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > http://www.ipinc.net/IPv4.GIF > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
