Subject: I-D ACTION:draft-ietf-ipv6-unique-local-addr-01.txt

From: [email-masked]
Date: Wed, 24 Sep 2003 10:09:11 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Version 6 Working Group Working Group of the IETF.

	Title		: Unique Local IPv6 Unicast Addresses
	Author(s)	: R. Hinden, B. Haberman
	Filename	: draft-ietf-ipv6-unique-local-addr-01.txt
	Pages		: 15
	Date		: 2003-9-24
	
This document defines an unicast address format that is globally
unique and is intended for local communications, usually inside of a
site.  They are not expected to be routable on the global Internet
given current routing technology.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipv6-unique-local-addr-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ipv6-unique-local-addr-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ipv6-unique-local-addr-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Bob Hinden <[email-masked]>
Date: Thu, 25 Sep 2003 16:07:44 -0700

>         Filename        : draft-ietf-ipv6-unique-local-addr-01.txt

The changes in this draft based on discussion on the mailing list are:

       o Removed example of PIR as an example of an allocation authority
         and clarified the text that the IANA should delegate the
         centrally assigned prefix to an allocation authority.
       o Changed sample code for generating pseudo random Global IDs to
         not require any human input.  Changes from using birthday to
         unique token (e.g., EUI-64, serial number, etc.) available on
         machine running the algorithm.
       o Added a new section analyzing the uniqueness properties of the
         pseudo random number algorithm.
       o Added text to recommend that centrally assigned local addresses
         be used for site planning extensive inter-site communication.
       o Clarified that domain border routers should follow site border
         router recommendations.
       o Clarified that AAAA DNS records should not be installed in the
         global DNS.
       o Several editorial changes.

Bob

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Steven Blake <[email-masked]>
Date: 26 Sep 2003 12:09:39 -0400

I have some comments about Section 3.2.1 (Centrally Assigned Global IDs)

1.  I don't understand the necessity for the requirement to generate IDs
    consistent with [RANDOM].  The IDs need to be unique and 
    sufficiently "randomized" (one could argue how important this need 
    really is) so that there is no plausible way to aggregate them.  I
    don't think it is necessary to be unable to guess the date or
    relative order in which a particular ID was allocated, however.

2.  I don't find the argument for a single allocation authority
    compelling.  It is still possible for a single authority (i.e.,
    IANA) to delegate blocks of the global ID space to multiple
    registries.  The naive way would be to delegate lists of random
    numbers generated by IANA.  A more elegant way would be to delegate
    ranges in the sequence space of a non-repeating PRNG (e.g., maximal
    period 40-bit LFSR).  Note that the requirement (1) above precludes
    this latter method.

3.  I don't believe it is essential to have alternative registration
    methods besides web and e-mail.  Anyone can establish a new network
    using only PA addresses (and locally assigned local IDs if
    necessary) before acquiring a "centrally assigned" local ID.  One
    could also ask a friend with connectivity, or go to a local library.
    Requiring non-automated means of registration significantly drives
    up the allocation cost.

4.  I don't believe that it is necessary for the allocation registry to
    escrow each allocation; I think it is sufficient for the allocation
    recipient to do so.  In a dispute one can prove that he or she owns
    an allocation by producing a non-repudiatable (e.g., signed) message
    from a registry.  The registries would only have to escrow their
    public keys.

5.  I don't believe that the 10 euro fee is appropriate.  I suspect that
    the cost to collect the money is substantially higher than the
    cost to manage the registry infrastructure, especially if the
    requirements are relaxed sufficiently such that the process can be
    fully automated.  Although I'm not volunteering to foot the costs
    of a registry myself, I suspect sponsors could be found to operate
    them.

6.  I believe a centralized registry is more susceptible to a DoS
    attack.

Regards,

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Steven L. Blake               <[email-masked]>
Ericsson IP Infrastructure                +1 919-472-9913

---

From: Zefram <[email-masked]>
Date: Fri, 26 Sep 2003 18:02:00 +0100

>    relative order in which a particular ID was allocated, however.

Someone will have a reason to want such unguessability.  That is
sufficient.  This is one of those cases where making it work in 100%
of cases is worthwhile because it means we don't need to keep in mind
the limitations of the compromise that we chose.

>    methods besides web and e-mail.

I think this should be decided by the other issues that determine whether
it is necessary to charge for allocation.

If it works out to be feasible, I think we should have no-cost allocation,
via an automated web/email system -- no need for distribution of the
registration function, no need for the mechanisms to handle payments,
and so on.  It'd require an investment by someone of the hardware
(roughly a PC plus 256GB disk space plus backup provisions -- total
cost a couple of thousand dollars), and would lead to a fantastically
hassle-free registration process.  I think it's worth sacrificing offline
means of registration in order to get this simplification.

It is only if this really cannot be done that we should accept a
non-zero-cost registration process: the need to handle a payment
complicates the process for everyone involved, and makes it a lot less
accessible than the free-to-end-user system would be.  In this system,
offline registration mechanisms would effectively come for free alongside
the payment-handling infrastructure.

>                         In a dispute one can prove that he or she owns
>    from a registry.

I note that the automated system I suggest above can do this admirably.

-zefram

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 29 Sep 2003 15:34:04 +0200

>     relative order in which a particular ID was allocated, however.

Strictly, that's true, but isn't it easier to simply refer to
an existing method?

>     period 40-bit LFSR).  Note that the requirement (1) above precludes

Yes but why bother ? There is no geographical aspect here, so why set up
more than one registry?

>     Requiring non-automated means of registration significantly drives

I would agree, but how does someone in the middle of a developing country
with no connected friends and no such thing as a library do it?

>     from a registry.  The registries would only have to escrow their

Yes, I think that is better.

>     of a registry myself, I suspect sponsors could be found to operate

The fee is the abuse-prevention mechanism. We know from other examples that
automated registries can and do operate at that level of fee. And in the
conditions of the early 21st century, no, I don't think it's trivial to
find sponsorship.

> 6.  I believe a centralized registry is more susceptible to a DoS

That's true. But if each probe of the attack takes 10 Euros out of the
attackers credit card, who cares?

   Brian

---

From: Steven Blake <[email-masked]>
Date: 29 Sep 2003 11:10:36 -0400

> Yes but why bother ? There is no geographical aspect here, so why set up

Well, the main reason is to prevent one registry from ripping people off
at 10 euros a piece.

> with no connected friends and no such thing as a library do it?

How do they come up with 10 euros to spend on a random number?

The simplest thing to do is use a locally assigned local ID until they
get a PA allocation, and then go get their "centrally assigned" local
ID.
 
> conditions of the early 21st century, no, I don't think it's trivial to

If the registration page requires some manual action by the registree
then that should be effective to prevent widespread abuse.  The typical
approach is to imbed a string in some graphic and require the user to
type in the string.
 
> attackers credit card, who cares?

Attackers would be more clever than that.

Anyway, I think the 10 euro fee is arbitrary and absurdly high.  I hope
IANA puts this out to competitive bid.

Regards,