On 2010-01-20 15:22, Ranjith ......knowing peking wrote:
> 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.
It seems to me trivial for a CPE router to do this (after a factory reset,
for example). We just need to specify it as a requirement.
> 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.
The filter is on the WAN side. That also seems trivial to automate, since the
CPE knows where its WAN interface is.
The only tricky bit that I can see is avoiding multiple ULAs if there's more
than
one CPE router. But that is a nice-to-have; there isn't really any harm in
having more than one ULA prefix configured.
Brian
>
>
>> 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 <[email protected]> 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 <[email protected]> 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
>> [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
--------------------------------------------------------------------
