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 PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
