Most of the current implementations of ULA does not support automatic generation of the global IDs corresponding to the ULAs. Users have to generate the global id by using some external software (using the interface id and current NTP time on the router). The User will have to do a lot to generate and configure an ULA address, which he may tend to avoid.
Besides this, Once a global id is generated, filters should be added at the site boundaries. As Site is ambiguous, i feel manual configuration is required for supporting ULA based network. > 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 I think the above will not help, as we are trying to restrict one site to one ULA. It may not be case always. On Tue, Jan 19, 2010 at 7:21 PM, Thomas Narten <nar...@us.ibm.com> wrote: > Seems to me, that there is a fairly big problem here for which a > solution would be useful, namely, "zeroconf" of small sites (like home > networks). This involves a combination of: > > 1) It might be useful to generate a ULA automatically, without the > user having to be involved. But, you only want one ULA per site, > which means you need a protocol/practice that handles multiple > routers at the site that think *they* should generate it if no one > else does. And maybe a user wants to disable the use of ULAs. So > you also need a mechanism for saying "don't automatically generate > a ULA on my network" > > 2) small sites may well have more than one ISP connection, so you have > the problem of automatically (?) identifying the site > boundaries. (Again, presumably, you don't want grandma to be > configuring this stuff, it needs to be automatic.) > > 3) There may well be more than on link (e.g, ethernet) present, so you > have to subdivide any prefix for the site into individual subnets > and distribute those (sub)prefixes to the appropriate routers. This > is true whether you are using ULAs, global addresses or both. You > also presumably want all the links to be assigned the same subnet > number (for simplicity). > > The IETF has never solved the above problem. Yet, if we just leave the > problem to individual vendors, I suspect we will end up with a mess. > > Ole Troan <otr...@employees.org> writes: > > the reason for me asking the question was: > > - are these requirements violating any RFC? > > no. But this is the sort of thing that I would think is out of scope > for an IETF document to even say, unless it was targeted specifically > at the above problem. So, even though no RFC forbids it, doesn't mean > we recommend it either. > > > - as this behaviour is not covered in existing IPv6 RFCs are they > > clear enough for implementors to implement? > > Clear, perhaps. But I'm not sure how much it really helps... > > > - are these requirements sufficient to solve the whole problem? > > Not a chance. > > > - do we need any IETF work to cover these 'gaps'? > > - is this a problem which should be solved? > > I tend to think that there is work here to be done. And better in the > IETF where a more holistic approach can be taken. But it is a hard > problem and I'm not sure we'd be successful... And we've done zeroconf > work before, without really producing a result. > > I do know though that just saying: > > > > 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? > > Won't come close to solving your problem and I suspect you will find > that the above doesn't help a whole lot... > > Thomas > -------------------------------------------------------------------- > 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 --------------------------------------------------------------------
