Subject: Response to AD comments on draft-ietf-ipv6-unique-local-addr-03.txt

From: Brian Haberman <[email-masked]>
Date: Thu, 08 Apr 2004 07:34:41 -0400

Margaret Wasserman wrote:

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

Given the follow-on discussion of this point, how about the following
replacement text for section 7.0:

      AAAA records (both forward and reverse) for Local IPv6 addresses
      are not expected to be installed in the global DNS because they are
      intended to be used for local communication inside of a site.  They
      may be installed in the global DNS since they are unique and will
      not create confusion.  They may not be reachable, but that is a
      property common to all types of global IPv6 unicast addresses.

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

How about the following replacement for the above text (courtesy of
Brian C.)?

      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.

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

The purpose of the second bullet is to ensure the permanent allocation
of these prefixes.  Periodic fees are inconsistent with permanent
allocations (e.g., what happens if someone were to stop paying the
periodic fee?, would the allocation be revoked and reassigned?).

In addition, there is precedence for one-time, upfront fees such as
this.  The IEEE mechanism for MAC addresses comes immediately to mind
as a similar model.

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

The escrow is to simply ensure no duplication and allow for conflict
resolution.  As described above the cost for maintaining an escrow can
be paid for with an charge at the time of the allocation.

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

They can use the same machine with the same EUI-64 since the MD5 hash
will sufficiently randomize the bits given the second input of a time
stamp.

However, for the centrally allocated range, we plan to add a step #6
that calls for the newly generated prefix to be tested for duplicity
within the escrow of existing prefixes.

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

Sure.

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

Yes.

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

There is no dependency on the Scoped Addressing Architecture in the
ULA spec.

Regards,
Bob & Brian

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

---

From: Rob Austein <[email-masked]>
Date: Thu, 08 Apr 2004 13:26:00 -0400

>       property common to all types of global IPv6 unicast addresses.

Er, one does not generally install AAAA RRs in the reverse tree.
AAAA RRs in the forward tree, PTR RRs in the IP6.ARPA reverse tree.

---

From: "Stephen Sprunk" <[email-masked]>
Date: Sat, 10 Apr 2004 01:41:08 -0500

Thus spake "Brian Haberman" <[email-masked]>
>  >>    performing the authority duties.

How about:

IANA MAY delegate assignment capabilities to more than one entity.  If this
occurs, the various entities must assign addresses using a method that is
indistinguishable from that of a single entity.  Specifically, the method
MUST prevent collisions between assignments by different entities and MUST
NOT rely on subdividing the assignable address space in a manner that
promotes or resembles any aggregation scheme.

> this.  The IEEE mechanism for MAC addresses comes immediately to mind

I'm still trying to find a better phrasing for this.

> be paid for with an charge at the time of the allocation.

Would the escrow come into play if the allocating entity goes bankrupt or
pulls out?  i.e. how would these assignments get transferred to a new
authority?  Given the issues with NET and COM, should we specify that IANA
is the owner of all assignment records (e.g. the escrow)?

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: Thu, 15 Apr 2004 09:40:13 +0200

> promotes or resembles any aggregation scheme.

I don't think we need to say this. The simple fix s/source/authority/
in the earlier text puts the whole matter in IANA's hands, where it
belongs.

For the record, I agree with all Brian H's proposals except for the DNS
bit that needs to be fixed.

   Brian