Subject: AD Evaluation of draft-ietf-ipv6-unique-local-addr-03.txt

From: Margaret Wasserman <[email-masked]>
Date: Sun, 14 Mar 2004 21:29:59 -0500

Apparently there are some people in the IETF who use mail readers 
that cannot handle standard text attachments.  For those people, here 
is a resend of the e-mail I sent earlier with the attachment included 
in-line.  Sorry for the duplication.

Hi All,

I've completed my AD evaluation of 
draft-ietf-ipv6-unique-local-addr-03.txt.  My comments (attached 
below) include a few substantive issues that I would like to discuss 
with the WG before sending this draft to IETF last call. Thoughts?

I have also included a few non-blocking editorial comments that 
should be addresses in the next revision, if any.

Margaret

SUBSTANTIVE ISSUES:

(1) This draft doesn't mention the reverse DNS tree.  Is it expected that
     whatever registry assigns these values will also populate the reverse
     DNS tree?  Or not?

(2) The document says:

>    Global IDs should be assigned centrally by a single allocation
>    authority because they are pseudo-random and without any structure.
>    This is easiest to accomplish if there is a single source for the
>    assignments.

     This would appear to be incompatible with the IANA considerations
     section that says:

>    If deemed
>    appropriate, the authority may also consist of multiple organizations
>    performing the authority duties.

     To avoid a situation where a single entity can request a large number
     of local prefixes and aggregate them, it isn't strictly necessary that
     the addresses be allocated from a single pool.  If there were several
     pools (for different geographical regions, for example) random
     allocations from one of those pools would achieve the same result.

(3) The document also says:

>    The requirements for centrally assigned global ID allocations are:
>
>       - Available to anyone in an unbiased manner.
>       - Permanent with no periodic fees.

     It seems strange to say that there can be no periodic fees when the
     document doesn't mention fees anywhere else...  Perhaps this is a
     leftover from previous versions of the document that did include a fee
     structure?

>       - Allocation on a permanent basis, without any need for renewal
>         and without any procedure for de-allocation.
>       - Provide mechanisms that prevent hoarding of these allocations.
>       - The ownership of each individual allocation should be private,
>         but should be escrowed.

     I am not sure that requiring a permanent escrow is consistent with the
     idea that there will be no ongoing revenue stream (i.e. periodic fees)
     associated with an address.

(4) The algorithm for random number generation is:

>3.2.3  Sample Code for Pseudo-Random Global ID Algorithm
>
>    The algorithm described below is intended to be used for centrally
>    and locally assigned Global IDs.  In each case the resulting global
>    ID will be used in the appropriate prefix as defined in section 3.2.
>
>      1) Obtain the current time of day in 64-bit NTP format [NTP].
>      2) Obtain an EUI-64 identifier from the system running this
>         algorithm.  If an EUI-64 does not exist, one can be created from
>         a 48-bit MAC address as specified in [ADDARCH].  If an EUI-64
>         cannot be obtained or created, a suitably unique identifier,
>         local to the node, should be used (e.g. system serial number).
>      3) Concatenate the time of day with the system-specific identifier
>         creating a key.
>      4) Compute an MD5 digest on the key as specified in [MD5DIG].
>      5) Use the least significant 40 bits as the Global ID.
>
>    This algorithm will result in a global ID that is reasonably unique
>    and can be used as a Global ID.

     Are you intending that centrally assigned addresses will all be
     generated using the EUI-64 address of a server at the centralized
     registration authority?  What affect would this have on the randomness
     of these allocations, and does that matter?

EDITORIAL COMMENTS

>       - Allows sites to be combined or privately interconnected without
>         creating any address conflicts or require renumbering of
>         interfaces using these prefixes.

s/require/requiring

>    Site border routers and firewalls should not forward any packets with
>    Local IPv6 source or destination addresses outside of the site unless
>    they have been explicitly configured with routing information about
>    other Local IPv6 prefixes.

s/other//  ??

>14.1 Normative References

Did you really manage to get through this entire document without
requiring any reference (normative or informative) to the Scoped
Address Architecture?  I seem to recall some mention of link-local
addresses, for example.

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

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 15 Mar 2004 09:08:46 +0100

Margaret Wasserman wrote:
...
>      whatever registry assigns these values will also populate the reverse

I think it is better to leave this question for a separate document (which
certainly needs to be written). I don't think we should delay the present
document for this.

>      allocations from one of those pools would achieve the same result.

Yes. I suggest rewriting the first extract as:

 Global IDs should be assigned under the authority of a single allocation
 organization because they are pseudo-random and without any structure.
 This is easiest to accomplish if there is a single authority for the
 assignments.

>      leftover from previous versions of the document that did include a fee

No, I think it is a principle and a directive to the IANA that we should
keep. 

>      associated with an address.

But it's a matter of principle. If the IANA really thinks this is an issue,
it's for them to say so, not us.

>      of these allocations, and does that matter?

Actually the randomness doesn't matter much - we need enough randomness to
ensure that people don't imagine these things aggregate, but there is no
need for a mathematically "good" randomness.
 
   Brian

---

From: "Stephen Sprunk" <[email-masked]>
Date: Mon, 15 Mar 2004 02:57:42 -0600

Thus spake "Brian E Carpenter" <[email-masked]>
> certainly needs to be written). I don't think we should delay the present

I think this revolves around a basic question of whether information about
centrally-assigned local prefixes should be available to third parties.  If
so -- and that is my preference -- then WHOIS information should be provided
and DNS delegations should be available, though not mandatory.  Optional
global DNS delegations may be beneficial to those using local addresses to
communicate privately between organizations because it can remove the need
for split DNS.

>  This is easiest to accomplish if there is a single authority for the

This wording still doesn't seem consistent with the possibility of having
multiple central authorities.  If we are going to allow IANA the discretion
to assign multiple allocators, then we need to specify how that will be
handled, i.e. either assigning sub-prefixes to each authority or requiring
real-time checking between authorities to prevent collisions.

> No, I think it is a principle and a directive to the IANA that we should

Agreed.  Perhaps we should emphasize the permanent (i.e. rent-free) nature
of these allocations earlier in the draft so this statement doesn't seem out
of place?

> it's for them to say so, not us.

This is more of a business concern than a technical one, which seems outside
the IETF's purview.  Maybe under IANA considerations we could add a
statement about how IANA should require a prospective allocation authority
present how it can fund indefinite operation from one-time fees?  As has
been discussed, any competent accountant can figure how to determine a
one-time fee that equates to indefinitely recurring fees.

It might be desirable for IANA/ISOC/whoever to set up a permanent trust
which receives one-time allocation fees and pays recurring fees (from
interest) to the actual allocation authority; such trust could also be
responsible for the escrow of registrations.  This would protect against
bankruptcy of (or subsequent change in) the particular allocation authority.
I'm not sure this level of detail belongs in the draft, but this is the
model I had in mind.

> Actually the randomness doesn't matter much - we need enough
> randomness to ensure that people don't imagine these things aggregate,
> but there is no need for a mathematically "good" randomness.

It's possible that the generation method could be bottlenecked by the rate
of timestamp changes if centrally-assigned prefixes become very popular.
Since the centrally-assigned half of the address space doesn't need the
level of collision prevention that the locally-assigned half does, could we
change this from a MUST to a SHOULD for the former?  Any pseudo-random
algorithm should be sufficient for a central authority, provided it gives no
potential for aggregation.

S

Stephen Sprunk        "Stupid people surround themselves with smart
CCIE #3723           people.  Smart people surround themselves with
K5SSS         smart people who disagree with them."  --Aaron Sorkin

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 15 Mar 2004 10:30:11 +0100

in line...

> real-time checking between authorities to prevent collisions.

Send text? I meant mine to say that the authority (IANA) is unique - that
doesn't preclude (or require) sub delegation.

> I'm not sure this level of detail belongs in the draft, but this is the

That certainly doesn't belong in an IETF document. But saying "no recurring
fee" seems to me to be something we *can* say. And that's the text that went 
through WG last call.

   Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM

---

From: Alain Durand <[email-masked]>
Date: Mon, 15 Mar 2004 10:07:23 -0800

> communicate privately between organizations because it can remove the 

I too would like to see the reverse tree DNS being delegated. However, 
as there is no
structure, the entire /8 to /48 address space would have to be within 
one single zone...
I'm afraid we are going to create a monster zone that will be very 
difficult to sign with DNSsec.

	- Alain.

---

From: Zefram <[email-masked]>
Date: Tue, 16 Mar 2004 13:26:09 +0000

>structure, the entire /8 to /48 address space would have to be within 

There is structure within the domain name segment between /8 and /48
-- it's a sequence of ten DNS labels, not just one.  Zone cuts can be
introduced at any level to split the job up.

-zefram

---

From: Alain Durand <[email-masked]>
Date: Tue, 16 Mar 2004 13:08:41 -0800

> introduced at any level to split the job up.

If you cut at /8, the zone is too big. if you cut at /48, there are too 
many zones.
Where do you cut?

	- Alain.

---

From: "Stephen Sprunk" <[email-masked]>
Date: Tue, 16 Mar 2004 17:05:31 -0600

Thus spake "Alain Durand" <[email-masked]>
> >> I too would like to see the reverse tree DNS being delegated
> >> However, as there is no structure, the entire /8 to /48 address
> >> space would have to be within one single zone...
> >

If you need AXFR and standard BIND code, then /8 /18 /28 and /38 zones are
logical; just create the necessary cascading zones (if any) when new
assignments are made.  Yes, this creates tons of sparsely populated zones,
but that's a weak point of BIND (and probably not envisioned by DNS'
designers way back when).

However, since there's no structure to these assignments, it seems more
logical to hack up BIND or some other server to handle the unusually sparse
namespace in a more appropriate manner.  Presumably these servers would
synchronize via means other than AXFR.

S

---

From: Mark Andrews <[email-masked]>
Date: Wed, 17 Mar 2004 14:47:15 +1100

> difficult to sign with DNSsec.

	No it doesn't have to be within one zone.  You can split
	the namespace between as many zones / servers as are required
	to make the job managable.

	How this is done really should be left to the authority
	which is managing the space.

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Rob Austein <[email-masked]>
Date: Wed, 17 Mar 2004 02:53:18 -0500

At Wed, 17 Mar 2004 14:47:15 +1100, Mark Andrews wrote:
> At Mon, 15 Mar 2004 10:07:23 -0800, Alain Durand wrote:
> >
> > I too would like to see the reverse tree DNS being
> > delegated. However, as there is no structure, the entire /8 to /48
> > address space would have to be within one single zone...  I'm
> > afraid we are going to create a monster zone that will be very

Furthermore, the signed unit in DNSSEC is an RRset, so it's almost
always possible to sign incrementally (even during an emergency key
rollover, if one has the foresight to generate spare keys and
signatures in advance).

> 	which is managing the space.

Unsurprisingly, I agree.