Re: IPv6 w.g. Last Call on "Unique Local IPv6 Unicast Addresses"

Geoff Huston <gih@telstra.net> Thu, 23 October 2003 08:30 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08412 for <ipv6-archive@odin.ietf.org>; Thu, 23 Oct 2003 04:30:41 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACarD-0003NV-5n for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 04:30:21 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9N8UBSG012985 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 04:30:11 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACarC-0003NH-Ns for ipv6-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 04:30:10 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08384 for <ipv6-web-archive@ietf.org>; Thu, 23 Oct 2003 04:30:00 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACar9-0003cU-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 04:30:07 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACar9-0003cR-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 04:30:07 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACar6-0003AZ-Ee; Thu, 23 Oct 2003 04:30:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACaqH-0002v8-2k for ipv6@optimus.ietf.org; Thu, 23 Oct 2003 04:29:13 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08352 for <ipv6@ietf.org>; Thu, 23 Oct 2003 04:29:02 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACaqD-0003bF-00 for ipv6@ietf.org; Thu, 23 Oct 2003 04:29:09 -0400
Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx with esmtp (Exim 4.12) id 1ACaqD-0003aG-00 for ipv6@ietf.org; Thu, 23 Oct 2003 04:29:09 -0400
Received: from gih505.telstra.net (dhcp2.potaroo.net [203.10.60.2]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id h9N8SURc044738; Thu, 23 Oct 2003 18:28:35 +1000 (EST) (envelope-from gih@telstra.net)
Message-Id: <5.1.0.14.2.20031023182433.00b4ec48@kahuna.telstra.net>
X-Sender: gih@kahuna.telstra.net
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 23 Oct 2003 18:28:04 +1000
To: Brian Haberman <brian@innovationslab.net>, ipv6@ietf.org
From: Geoff Huston <gih@telstra.net>
Subject: Re: IPv6 w.g. Last Call on "Unique Local IPv6 Unicast Addresses"
In-Reply-To: <3F96659F.4040702@innovationslab.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Sender: ipv6-admin@ietf.org
Errors-To: ipv6-admin@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Id: IP Version 6 Working Group (ipv6) <ipv6.ietf.org>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>

>Please send substantive comments to the ipv6 mailing list, and minor
>editorial comments to the authors.  This last call period will end on 5
>November 2003.

I do not believe that this document is ready for Proposed Standard.

My comments (both as suggested text corrections and as more
substantive comments on content) are as follows:

Section 3.2
-----------

"The centrally assigned global IDs have a much higher probability that
they are unique"

The intent of the central assignment function is to ensure uniqueness.
Therefore the wording should be:

"The centrally assigned global IDs are uniquely assigned"

Also:

"It is recommended that sites planning to use Local IPv6 addresses for
extensive inter-site communication use a centrally assigned prefix as the
possibility of any conflicts is lower."

should be re-worded as:

"It is recommended that sites planning to use Local IPv6 addresses for
extensive inter-site communication use a centrally assigned prefix as
there is no possibility of prefix assignment conflicts."

Section 3.2.1
-------------

"This to ensure that there is not any relationship between allocations and
to help clarify that these prefixes are not intended to be routed
globally."

Clumsy grammar and perhaps additional words are appropriate. Suggest
change to:

"This to ensure that there is no relationship between allocations and to
help clarify that these prefixes are not intended to be routed globally by
eliminating aggregation possibilities."

Also:

"This is easiest to accomplish if there is a single source of the
assignments."

and

"One time non-refundable allocation fee in the order of 10 Euros (at
January 1, 2004 exchange rates) per allocation."

I question the validity of specifying a single source coupled with service
fees in a document such as this. This appears to be creating regulatory
issues of establishing a global monopoly coupled with price fixing. An
alternate wording that may mitigate this to some extent is to change the
second sentence to remove this item from requirements, and instead phrase
this as a recommendation, namely:

"It is recommended that the registry operate using a service regime of a
single service fee per allocation bearing in mind that the service should
be accessible and affordable to small sites in all parts of the world."

Also:

"The reason for the one time 10 Euro charge for each prefix is to provide
a barrier to any hoarding of the these allocations but at the same time
keep the cost low enough to not create a barrier to anyone needing one.
The charge is one time to eliminate the need for an ongoing relationship
with the allocation authority.  The charge is non-refundable in order to
keep overhead low."

change to:

"The reason for the per-prefix allocation service fee is to allow the
service to operate on a financially sustainable basis. A service fee also
creates an externality of a barrier to any hoarding of the these
allocations. The fee should be low enough to not create a barrier to
anyone needing one.  The charge is one time to eliminate the need for an
ongoing relationship with the allocation authority.  The charge is non-
refundable as the allocation is irrevocable."

Also:

"It is escrowed to insure there are no duplicate allocations and in case
it is needed in the future (e.g., to resolve duplicate allocation
disputes).

add the case of a potential change in allocation registry operator. i.e.

"It is escrowed to insure there are no duplicate allocations and in case
it is needed in the future (e.g., to resolve duplicate allocation
disputes, or to support a change of central allocation registry operator).

Also:

"This document directs the IANA, in section 13.0, to delegate the FC00::/8
prefix to an allocation authority to allocate centrally assigned /48
prefixes consistent with the requirements defined in this section."

change requirements to requirements and recommendations

"This document directs the IANA, in section 13.0, to delegate the FC00::/8
prefix to an allocation authority to allocate centrally assigned /48
prefixes consistent with the requirements and recommendations listed in
this section."

Section 3.3
-----------

"Rather, these prefixes are globally unique, and as such, their
applicability exceeds the current site-local addresses."

Should the word "current" be used in this context? Perhaps:

"Rather, these prefixes are globally unique, and as such, their
applicability exceeds the previously defined site-local addresses."

Section 7.0
-----------

It may be worth mentioning that DNS systems should be configured to
prevent queries relating to such addresses to be passed into the public
DNS system.

To quote the AS112 project home page: "Because most answers generated by
the Internet's root name server system are negative, and many of those
negative answers are in response to PTR queries for RFC1918 and other
ambiguous addresses" (http://www.as112.net/)

Section 13.0
------------

"This allocation authority shall comply with the requirements described in
section 3.2 of this document, including in particular the charging of a
modest one-time fee, with any profit being used for the public good in
connection with the Internet."

It is noted that there are significant problems with this proposed
approach to directions to IANA, particularly with the noted concept that
this is a for-profit activity and IANA is, in effect, being directed to be
in the position of selecting a global monopoly operator. The indeterminate
nature of a fair, open and reasonable definition of "the public good" is
also a problem in the context of these instructions to IANA. Some of the
lessons learned from DNS administration over the past decade would
indicate that this is not a sensible directive to pass to IANA, as it is
unlikely to be reasonably implemented in this precise form.

Additional Comments
--------------------

draft-huston-ipv6-local-use-comments-01.txt contains a number of
additional comments that are not addressed in this draft. In particular,
section 5 of that draft raises issues concerning

- the structure of an allocation fee being a form of monopoly rental. (a
   service fee would be more viable from a regulatory perspective) (section
   5.1 of the comments draft)

- the recording of allocations (section 5.4 of the comments draft)

- reverse mapping of such addresses in ip6.arpa (section 5.5 of the
   comments draft)


regards,

   Geoff Huston



--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------