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 --------------------------------------------------------------------
