Ralph, > 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".
there is a wish to have terminology which makes a distinction between WAN facing (towards the SP) and customer facing interfaces. but note that this isn't _my_ terminology and I take no responsibility for it. ;-) > 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. correct. so as I said to Woj are these requirements complete? do we need new protocol work or an IETF specification describing how this should work? is it a problem we need to resolve? e.g could we just say that having two ULA prefixes in the network is fine. or we just state that this is a problem which require manual configuration? cheers, Ole > 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 >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
