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