Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-03.txt> (LISP EID Block) to Informational RFC

[Geoff Huston <[e-mail]>]

Hi,

We would like to make the following comments in response to the IETF
Last Call on the proposal to publish this draft as an Informational 
RFC.

The guidelines for IP address allocations were documented in RFC2050,
adopted in November 1996 as a Best Current Practice. This document
described the framework of the Internet Registry system, and the roles
and responsibilities of various parties involved in the distribution of
addresses in the Internet. The document was not intentionally related to
any particular routing technology, and addressed guidelines that would
maximise the effective use of address space.

The Memorandum of Understanding between the IETF and ICANN over the IANA
activity, RFC2860, published in June 2000, provides further details of
the address management function. In particular, the document notes that
"assignments of specialised address blocks (such as multicast or anycast
blocks), and experimental assignments are not considered to be policy
issues, and shall remain subject to the provisions of this [document]."

RFC 4773, published in December 2006, provides some guidelines to the
IANA concerning the management of these specialised address assignments
in IPv6: "IANA may undertake IPv6 address designations in support of
special purposes as requested in "IANA Considerations" sections in IESG-
reviewed RFCs, where an address is requested with an intended use of the
designated address block for the purpose of testing or experimental
usage activities initiated by IETF, or for specialised use of the
address block in a context (e.g., anycast) associated with an Internet
Standards track protocol."

In this context the request to IANA to reserve an IPv6 /12 address and
allocate out of it a /16 block for use as an EID space for the
experimental LISP protocol presents some questions.

It is noted that the LISP experiment already makes use of a /32 prefix,
"with more than 250 sites using a /48 sub prefix", as noted in
draft-ietf-lisp-eid-block-03.txt. Even with an overall 50% utilisation
rate of this prefix there is scope in the current /32 address block to
address some 32,000 further sites using a /48 sub prefix.

If the LISP experiment fills this /32 prefix to such a level of
utilisation then there would be reasonable grounds to make the case that
at such a time the LISP activity would no longer be an experimental
effort, as it would be an instance of an application that makes use of
the global unicast address pool. In this case the provisions of RFC
4773, and the applicability of a special purpose address allocation
would not be expected to apply, as this would fall under the terms of
RFC2050 and the address allocation function would be administered by the
Regional internet Registries, according to RFC2860.

If we were to consider this request for the reservation of a /12 and the
allocation of a /16 in the context of support for an experiment, then
the nature of the experiment is unclear. At the scale of a /16 being
capable of supporting a theoretical maximum of some 4.3 billion /48 end
sites, and a /12 supporting a theoretical maximum of 68.7 billion /48
end sites, then the boundary conditions of such an experiment become
challenging to define. How can one define the experiment to have
finished? What are the plans to migrate out of the experimental address
allocation? Would this renumbering out of an experimental address
allocation even be feasible to contemplate if the experiment achieves a
level of deployment that is commensurate with the allocation of /16?

Such large scale deployment activities being undertaken under the
provisions of an experimental activity also raises a number of questions
about the registry services to be provided in support of such a
reservation. Given that this particular experiment is intended to
operate on the global IPv6 Internet it is apparent that some form of
directory (e.g. Whois) and reverse DNS services will be necessary; is
the provision of such services on a large scale (i.e. for potentially
tens of thousands of individual entities) to be performed by the IANA? 
If so then this appears contrary to RFC 4773's statement that the "IANA
will not maintain further sub-registries for any special purpose address
block designated according to this direction."  Further, the
implementation of any large scale directory such as resulting from this
type of experimental reservation would definitely pose serious policy
issues, e.g. trading off operational visibility, privacy, and law
enforcement needs, and by the spirit of the IETF/ICANN MOU on IANA
activities (RFC 2860). It would appear from this perspective that such
an assignment of address resources is not suitable to be made as an
experimental assignment.

The question this draft raises is to identify the basis of the request.
An experimental allocation of this size does not appear to be consistent
with a conventional view of an experiment. The draft's proposals appear
more aligned to the activity of planning for large scale public
deployment of a global routing infrastructure for global unicast
addresses. But if that is indeed the case then the provisions of RFC4773
do not apply, as the special Purpose Address Allocation Registry does
not encompass the allocation of address blocks for use in a global
unicast address context in the context of large scale deployment
activities.

A possible course of action for the LISP Working Group and the IESG to
consider would be for the existing /32 address be documented as an IANA
Special Purpose Address allocation for use in supporting the current
LISP experiment, and for the LISP advocates to make their case for
particular requirements in the handling of global unicast address
allocations in IPv6 to the regional addressing communities. This would
allow the existing address policy development process to generate
outcomes that appropriately address the desires and concerns of the
broader community of stakeholders in supporting the potential
requirements of a broad base of deployment of LISP in the Internet's
routing environment.

We do not support the publication of this draft as an Informational RFC.

regards,

  John Curran,
  Paul Wilson, and
  Geoff Huston