Subject: regarding draft-hinden-ipv6-global-local-addr-02

From: "Alan E. Beard" <[email-masked]>
Date: Mon, 18 Aug 2003 23:33:54 -0400 (EDT)

Bob:

I have read carefully your Unique Local IPv6 Unicast Addresses internet
draft, and here are my reactions:

First, as regards IPv6 engineering strategy: the use of non-globally
routable, globally unique (or nearly so) PI addresses as proposed in the
Local IPv6 addresses ID would alleviate many (but, of course, not quite
all) of the difficulties previously identified as arising from use of
Site-Local addressing.  With the proposed deprecation of Site-Local
addressing, a great clamor has arisen for some convention which might
provide an improvment over S-L where stable local addressing is required.
Your draft seems to define such a convention.  While the Local IPv6
addresses proposal does not resolve quite _all_ the issues surrounding
address allocations for local environments (more on this below), the
current draft nevertheless has much to commend it.  In short, I am of the
opinion that the mechanisms and practices proposed in INTERNET-DRAFT
Unique Local IPv6 Unicast Addresses, or some very similar scheme, should
be adopted.  Please see below for notes on issues which are likely to
continue to fester even after adoption of a scheme such as proposed in the
current draft.

Now, concerning specific elements of the proposal:

Section 3.1 Format

The proposals herein are unobjectionable.  The suggestion of a /7 space
divided into one /8 for local assigns and one /8 for central assigns seems
reasonable to me.  I am somewhat less sanguine than are you concerning the
assumption that the central-assign /8 will never be exhausted, but, as
pointed out in the draft, it is possible to augment the space with an
additional /7 at some later time if necessary.  It might be prudent to ask
(or direct) the IANA to reserve another /7 for later use, with the proviso
that the additional space will be freed after an agreed length of time if
allocation rates prove no higher than expected.  After all, the v4 design
wallahs didn't think they would exhaust the 32-bit space either.

3.2.1 Centrally Assigned Global IDs

I do not see (although I may have overlooked it) any requirement that the
allocation authority ensure that a  prefix generated in response to a
request  for a centrally assigned global ID be unique.  Since one of the
purposes of most central assignment mechanisms is to ensure
non-duplication of allocations, it would seem useful to require an
allocation authority to enforce uniqueness of assignments which it
originates.  Although, as pointed out in the text, risk of duplicate
assigments is quite low, a simple search of the escrow database or some
similar repository of previously assigned values would be, at a minimum,
useful; I think it should be required.   The imposition of a small,
one-time fee for each allocation seems entirely reasonable to me, as does
the requirement that allocation requests may be submitted by means other
than network facilities, as well as via online access. Although not
mentioned (at least to my memory) in the text, good operational practice
would militate in favor of an allocation records repository mirrored in at
least two widely separated geographic locations, and accessible by wholly
independent network paths; however, it is to my mind an open question
whether or not we need to specify this level of operational detail in the
draft.

*.*.* not enumerated above

These sections seem entirely unobjectionable, subject to notes below.

Additionally, as noted above, the conventions and mechanisms described in
the extant draft will not (and, by my reading, do not purport to) resolve
all the issues discussed in the IPv6 WG with regard to use of site-local
addressing. In my view, additional work, almost all well beyond the scope
of said draft, will be required before many of the issues enumerated below
are susceptible of resolution. However, the mere fact that the draft is
not catholic (note small 'c') in its obviation of problems in no way
detracts from the soundness and desirability of the concepts and
conventions described in said draft.

Specifically, what is proposed in said draft does not:

*  Drive a stake through the heart of NAT

It would appear that the fondest desire of many in the IPv6 WG is to
consign NAT to a rapid, and exceeding painful, death.  While this may be
an admirable goal (for NAT is truly a pernicious beast, and productive of
far more trouble than benefit), experience to date seems to show that we
will not see the demise of NAT until the designers and admins of user
networks have no requirements which can be satisfied by the use of NAT,
or have available for each requirement which might be satisfied by a NAT
implementation an alternative facility which is functionally markedly
superior and administratively much less troublesome than current NAT
boxes.

However, the provision of globally unique address allocations (if we
discount the very low risk of a collision arising from the random prefix
generation algorithm) does substantially (perhaps markedly) reduce the
number of instances in which NAT implementation is required to handle
private implementations which use overlapping address spaces and
nevertheless require application-level interoperation for business
reasons. This is, ipso facto, a desirable outcome, and IMHO it is not
reasonable to expect more of any proposal of the nature of that before us.

* Resolve at a single stroke all multihoming issues

As pointed out in the text of the draft, unique local unicast addresses
may be candidates in some circumstances for use in multihoming
implementations.  It seems to me most likely that configurations which
feature multiple private interconnections between private networks. (NB:
for the purposes of this discussion, VPNs, whether operated over pivate
links or over the Internet, are considered private interconnections.) The
more general cases (specifically, site multihoming and system multihoming
over arbitrary transport) are not affected by this set of proposals.
Further, I don't know of anything in the multi6 WG which would have
direct bearing upon the extant proposal.

The availability of stable, unique unicast addressing, even if not
globally routable, does enable multihoming over private interconnections
using techniques defined by current standards - as far as I can determine,
no new protocols or facilities should be required.  I see this as
sufficient benefit; again, it is not reasonble to expect more of any
proposal of the nature of that before us.

* Eliminate operational difficulties with DNS and related services
regarding destinations which may be reachable only by traffic which
originates from a subset of the global set of interfaces or protocol
addresses

We have recently seen in the IPv6 WG a number of messages suggesting that
use of address spaces which are not globally routable and, to some extent,
use of scoped addresses, will inevitably give rise to dire consequences in
the form of split-face (sometimes called two-face) DNS implementations.
Based on experience to date, we are likely to continue to find two-faced
DNS implementations as long as we have in user environments addresses
which are valid in one or more, but not in _all_, routing contexts. The
extant draft does little to alter this situation where v6 is concerned. As
pointed out in other messages to the WG, user network administrators, in
the absence of permanently stable registered address allocations, are
likely to continue to use some form of non-globally-routable space coupled
with a set of mechanisms (eg NAT, ALGs, or the like) which enable traffic
flow (at least at the application level) from devices on non-routable
allocations to devices in globally-routable space. Unless we can persuade
user network administrators to use globally-routable addresses for
*everything* (see below), split-face DNS implementations may be as
persistent and ubiquitous as the common cold. It appears likely, absent a
miracle (and I don't have one in my hip pocket this week), that split-face
DNS will be a fact of life in the IP world for some time to come.

* Obviate all legitimate objections to use of PA addresses in all
environments

The extant proposal clearly does not address the violent objections voiced
by some (in my experience, by many) enterprise network managers to use of
PA space throughout enterprise networks.  These objections have, at least
in summary form, been well aired in the WG; although some WG members have
questions the validity of the premises from which the objections are
derived, we have not so far succeeded in wishing the objections out of
existence. It appears that a fair proportion of small- to medium-size
enterprise networks (by my estimate, a majority of those supporting host
counts of 30 to about 32,000 interfaces) will continue to object to some
of the operational difficulties percieved as arising from exclusive use of
PA space in their environments.  Unique Local IPv6 Unicast addresses, as
proposed in the draft here considered, can, if used in accordance with
sound network engineering practice, alleviate some of the more pernicious
difficulties perceived by user network administrators. Specifically, these
non-globally-routable PI blocks can be used to provide partial immunity of
private networks (those which do not require _direct_ access tot he
Internet) from forced renumber events triggered by ISP actions or by a
change of ISP on the part of the enterprise network administrators.
Other benefits, as enumerated in the draft, also obtain.

Although, as pointed out immediately above, the  Unique Local IPv6 Unicast
addresses proposal is not a panacea for all ills of IPv6, it does provide
substantial benefit.  However, additional work in other areas will be
_required_ if we are to have v6 as widely accepted and implemented by the
user community as most of us desire.  In particular, additional work would
be highly desirable (IMO, absoloutely required) on the following matters:

* Globally-routable, aggregatable, provider-independent address
allocations for use in enterprise and some other types of end-user
networks

I do not suggest that the use of PA addressing be discontinued; there are
substantial numbers of network for which PA blocks are entirely suitable,
and for which the PA addressing model may be clearly preferred.  However,
there is a non-trivial number of networks, as pointed out above, for which
the PA model is not well suited; in many of these cases, globally-routable
PI space is a superior choice for operational reasons.  Granted, this may
present scaling problems for extant routing protocols.  However, there are
a number of aggregation schemes proposed for PI space, some of which seem
to have the potential to reduce the prefix count in global routing tables
to perhaps managable proportions.  Work in this area is not likely to
proceed with celerity, much less alacrity.

* Renumbering

For all v6 networks, a set of tools and techniques is required (IMHO)
which will render a renumber event wholly transparent to users and
applications (transparent in this context is interpreted as
non-service-disrupting with no manual intervention required), and
productive of minimal administrative overhead to network engineers,
applications administrators, and network managers. Availability of such
tools and techniques may encourage some (but clearly not _all_) user
network administrators to accept PA allocations, rather than deferring
migration to v6 until globally-routable PI space is available, or
remaining on v4 'till the proverbial cows come home.  We aren't there yet,
but there may eventually achieve these goals.  My bet it that it will take
a while.

* Multihoming

The multi6 WG has been wrestling with the technical issues for some time
now.  It seems to me that many of the more intractable issues arise
directly from the route aggregation requirements imposed by the current
address allocation model, and contents of the multi6 drafts I have read
seem to bear this out, as almost every mechanism and protocol proposed has
an exclusion clause for large enterprise networks which acquire their own
globally-routable (PI) prefixes.

* DNS, DHCP, and autoconfig

The outstanding issues in these areas have been mentioned in any number of
posts to the ipv6 WG; it's not necessary to amplify on what has already
been said.

OK, now a summary:

IMO, draft-hinden-ipv6-global-local-addr-02, while not a panacea for all
IPv6 ills, is a sound work which presents a format of local IPv6 addresses
which, if implemented in accordance with sound network engineering
practice, can be of substantial benefit to end-user networks.  The
proposals in said draft provide interim relief for several problems
identified as being of particular and marked concern to adminstrators of
end-user networks in enterprise and some other environments.  I am in
favor of further work on this proposal, with a view to eventual adoption
of this, or similar, facilities. Additionally, this WG, in conjunction
with others, should countine to work on other logically distinct issues
enumerated above.

That's my $.02 worth.

AEB

-- 
Alan E. Beard <[email-masked]>
AEBeard Consulting; 4109 Chelsa Ln; Lakeland FL 33809
863.815.2529

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------