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

From: Zefram <[email-masked]>
Date: Fri, 9 May 2003 11:42:54 +0100

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) <[email-masked]>
--------------------------------------------------------------------
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 [email-masked]
--------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 09 May 2003 13:30:58 +0200

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

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

>    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

---

From: Zefram <[email-masked]>
Date: Fri, 9 May 2003 13:17:06 +0100

Brian E Carpenter wrote:
>we don't need to escrow the "ownership".

Ah, yes.  That interpretation of "duplicate allocation" hadn't occurred
to me, since it's got nothing at all to do with the identity of prefix
owners.  Might I suggest that the "ultra secure archival" here ought to
include widespread public mirroring -- there's no need for the list of
allocated prefixes to be secret.

>plenty of precedents for that.

My intent in proposing not keeping ownership records was that this avoids
the possibility of law-enforcement-like problems.  If the registry has
a big secret list of prefix owners, we have to decide who gets access
to that list, and then get issues of people violating the policy,
accusations, suspicions, and so on.  If the registry doesn't keep
this secret then it doesn't need to protect the secret.  I propose
that the only long-lived secret the registry has should be its private
certificate-signing key, which is much less of a problem.

Or so it seems to me, at least.  I don't have any real experience with
coerced-disclosure issues.  Maybe it just doesn't work the way I think
it does.

>escrowed can still get a prefix, subject to the low risk of a collision.

That's certainly a source of users that are going to use random allocation
whether or not it's officially supported.

-zefram