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

[Zefram <zefram@xxxxxxxx>]

Overall this looks like a very good idea.  I'm enormously more comfortable
about the idea of using these Globally Unique addresses than site-local
addresses.  A handful of minor points:

0. The name you're using to refer to the addresses, "globally unique
   IPv6 local addresses", doesn't express the essential characteristics
   of these addresses.  There are many types of IPv6 address that
   are globally unique (most of them, in fact), and the word "local"
   is too vague in this context.  The interesting characteristics
   of these addresses are that they're (a) provider-independent,
   (b) globally scoped (globally unique), (c) not generally routable.
   A better tag, therefore, might be "unroutable global IPv6 addresses".
   "local", as in local routeability, is one way they can be used, but
   isn't an inherent property of the address type, and so shouldn't be
   mentioned in this tag at all.

1. Why reserve the all-zeroes and all-ones global IDs?  The convention
   in IPv6 is that we don't reserve these values in any field.  If the
   intent is merely to prevent these IDs being allocated in the normal
   manner, it seems better to say that they must never be assigned at all,
   rather than saying that they might be used in the future.

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.

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.

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

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