[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: I-D ACTION:draft-hinden-ipv6-global-local-addr-00.txt



Zefram wrote:
...
> 
> 2. You propose allocation by a central registry.  There is an obvious
>    alternative of uncoordinated random allocation by end users, which
>    has already been suggested on this list.  Why not support both?
>    Some arrangement like fc00::/8 being centrally allocated and fd00::/8
>    being reserved for independent random allocation.  It's a bit like the
>    UUID system, where there is a choice between putting a MAC address
>    in the UUID or using the space for randomness.  Obviously random
>    allocation doesn't have a strong guarantee of uniqueness, and in
>    fact the birthday paradox applies, which is why central allocation is
>    useful, but that doesn't make independent random allocation unuseful.

I'm sure that unless a guaranteed-unique allocator is available, some
user sites will be uncomfortable. Allowing a probably-unique alternative
without a central allocator is OK, but it has to come with health
warnings.

>
> 3. Whether it's officially supported or not, I expect some people will
>    randomly allocate their own prefix, so advice on how to do it right
>    (use a strong entropy source, such as in the last resort tossing coins)
>    would be worth adding to the draft.

Yes. And in fact, since people will do it anyway, it is safer to allow for
it in the spec.
> 
> 4. The privacy of prefix ownership looks like a good idea.  Escrow of it
>    sounds innocuous, but I don't think you've justified the need for it.
>    The draft says "It is escrowed to insure there are no duplicate
>    allocations and in case it is needed in the future.".  Duplicate
>    allocations, more than one prefix to one user, are not a problem:

It means duplicate allocations of the same prefix, I think, and they
would certainly be a problem. In other words the list of prefixes that
have been allocated certainly needs to be stored in ultra secure
archival, in case the allocator crashes and burns. For this purpose,
we don't need to escrow the "ownership". But...

>    the EUR10 fee will prevent large-scale abusive allocation, and some
>    organisations might have a legitimate need for more than 16 bits of
>    subnet ID within unroutable global address space.  I suggest that all
>    the "in case it is needed in the future" scenarios that we want to
>    allow can be handled by having a cryptographically signed certificate
>    from the registry that allows a prefix owner to prove ownership of
>    their prefix, without the registry needing to keep records of who
>    owns which prefix.  This also has the advantage that pseudonymous
>    allocations, and similar scenarios, aren't a problem for the registry.

Yes they are, if local law enforcement makes them a problem. There are 
plenty of precedents for that.

Actually, this is why we probably do need the alternative random
mechanism - so that a user site that doesn't want its prefix
escrowed can still get a prefix, subject to the low risk of a collision.

   Brian

> 
> -zefram
> --
> Andrew Main (Zefram) <zefram@fysh.org>
> --------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------