Unique Local IPv6 Unicast Addresses
RFC 4193

E-mail from Mark Andrews raising concerns with the level of DNS review this document has received:

To: iesg@ietf.org, iab@iab.org
From: Mark Andrews
Date: Tue, 25 Jan 2005 11:54:05 +1100
Subject: Re: draft-ietf-ipv6-unique-local-addr-09.txt

It was suggested that I send this to you.

>      Has anyone talked to the admins for IP6.INT / IP6.ARPA over
>      the impact this will have on the servers for IP6.INT / IP6.ARPA
>      if they don't do a AS 112 style deflection?
>
>      Currently there are no words in draft-ietf-ipv6-unique-local-addr-09.tx
t
>      saying that sites using these addresses should prevent
>      the reverse queries leaking out.  I tried hard to get words
>      in but got squashed by the chairs.
>
>      As far as I can see draft-ietf-ipv6-unique-local-addr-09.txt
>      has not been referred to either of the DNS working groups for
>      review but it as a DNS section that is woefully incomplete.

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742         INTERNET: Mark_Andrews@isc.org

[Ballot discuss]
In the interests of moving forward on this document, I'm picking up
many of Ted's concerns.  They are restated in my own words, and I will
work with the authors, WG and ADs to resolve them.  Updated again
after discussions with the ADs.

It is clear that there is a rough consensus in the IPV6 working group
to advance this document as is.  However the IESG has an important
duty to judge the rough consensus of the entire IETF, particularly
focusing on cross-area/cross-constituency issues and issues a working
group might weight differently than other parts of the IETF.  There is
not rough consensus within the IETF to support one of the assumptions
of this document.  In particular, many have argued that the
operational requirements that ULAs not be routed globally will not be
followed.  There is no rough consensus on this issue either way;
strong opinions are held on both sides.  In addition, concerns have
been raised that deciding that ULAs with the l bit set to 0 are
globally assigned is not justified before an allocation mechanism is
designed.  We get little in the way of value by making that decision
now and limit our future flexibility.

I had assumed we would want to confirm that there is a consensus to
publish this document even if we believe that some ULAs may end up
being globally routed.  If there is such a consensus our path is easy;
if not then we need to carefully consider the process to use.  I had
originally thought that polling the working group on this issue would
be the best way forward.  Margaret didn't think it would be possible
to poll the working group; instead she proposed that we come up with
text to present to the working group; if there are problems with
consensus within the working group on the issue of publishing the
document even if some addresses will be globally routed, these
problems will show up as objections to the text.  I'm OK with that approach or with discussing the issue with the working group.

Here is a proposed path forward; other paths may be possible provided
they also address both concerns.  First, the document needs to be
modified to leave any claims about semantics of l = 0 ULAs
unspecified.  This specification should define l = 1 ULAs and say
nothing about l = 0 ULAs other than that they are reserved.

Next, the document needs to reflect the fact that there is a concern
that the routing advice will not be followed.  The document must take
no position on how reasonable this concern is; there is not a
consensus for any such position within the IETF community even though
there may be such a consensus in the IPV6 working group.  The document
should discuss reasons why the routing requirements should be followed
both from the standpoint of the global Internet community and from the
standpoint of someone who wishes their ULA routed.  The document
should also discuss potential problems that may result if ULAs do tend
to become globally routed, although I think this discussion is implied
by a discussion of why the global Internet community wants the routing
requirements followed.

[Ballot discuss]
In the interests of moving forward on this document, I'm picking up
many of Ted's concerns.  They are restated in my own words, and I will
work with the authors, WG and ADs to resolve them.

It is clear that there is a rough consensus in the IPV6 working group
to advance this document as is.  However the IESG has an important
duty to judge the rough consensus of the entire IETF, particularly
focusing on cross-area/cross-constituency issues and issues a working
group might weight differently than other parts of the IETF.  There is
not rough consensus within the IETF to support one of the assumptions
of this document.  In particular, many have argued that the
operational requirements that ULAs not be routed globally will not be
followed.  There is no rough consensus on this issue either way;
strong opinions are held on both sides.  In addition, concerns have
been raised that deciding that ULAs with the l bit set to 0 are
globally assigned is not justified before an allocation mechanism is
designed.  We get little in the way of value by making that decision
now and limit our future flexibility.

Here is a proposed path forward; other paths may be possible provided
they also address both concerns.  First we should confirm that there
is a consensus to publish this document even if we believe that some
ULAs may end up being globally routed.  If there is such a consensus
our path is easy; if not then we need to carefully consider the
process to use.  Second, the document needs to be modified to leave
any claims about semantics of l = 0 ULAs unspecified.  This
specification should define l = 1 ULAs and say nothing about l = 0
ULAs other than that they are reserved.

Next, the document needs to reflect the fact that there is a concern
that the routing advice will not be followed.  The document must take
no position on how reasonable this concern is; there is not a
consensus for any such position within the IETF community even though
there may be such a consensus in the IPV6 working group.  The document
should discuss reasons why the routing requirements should be followed
both from the standpoint of the global Internet community and from the
standpoint of someone who wishes their ULA routed.  The document
should also discuss potential problems that may result if ULAs do tend
to become globally routed.

[Ballot discuss]
It is clear that there is a rough consensus in the IPV6 working group
to advance this document as is.  However the IESG has an important
duty to judge the rough consensus of the entire IETF, particularly
focusing on cross-area/cross-constituency issues and issues a working
group might weight differently than other parts of the IETF.  There is
not rough consensus within the IETF to support one of the assumptions
of this document.  In particular, many have argued that the
operational requirements that ULAs not be routed globally will not be
followed.  There is no rough consensus on this issue either way;
strong opinions are held on both sides.  In addition, concerns have
been raised that deciding that ULAs with the l bit set to 0 are
globally assigned is not justified before an allocation mechanism is
designed.  We get little in the way of value by making that decision
now and limit our future flexibility.

Here is a proposed path forward; other paths may be possible provided
they also address both concerns.  First we should confirm that there
is a consensus to publish this document even if we believe that some
ULAs may end up being globally routed.  If there is such a consensus
our path is easy; if not then we need to carefully consider the
process to use.  Second, the document needs to be modified to leave
any claims about semantics of l = 0 ULAs unspecified.  This
specification should define l = 1 ULAs and say nothing about l = 0
ULAs other than that they are reserved.

Next, the document needs to reflect the fact that there is a concern
that the routing advice will not be followed.  The document must take
no position on how reasonable this concern is; there is not a
consensus for any such position within the IETF community even though
there may be such a consensus in the IPV6 working group.  The document
should discuss reasons why the routing requirements should be followed
both from the standpoint of the global Internet community and from the
standpoint of someone who wishes their ULA routed.  The document
should also discuss potential problems that may result if ULAs do tend
to become globally routed.

[Ballot discuss]
Since writing the initial DISCUSS on this there has been an extensive
discussion of the issue on ARIN's PPML list, on NANOG's discussion
list, and within the IESG.  ARIN's chair declined a request by a
member for ARIN to issue a message on behalf of its membership to the
IESG, asking instead that the IESG take the individual messages sent
into account.  My thinking on this has certainly changed in response
to those public discussions and I have quoted several messages from
there which had particular force for me.  I have not, however, tried
to summarize the whole discussion set and encourage the IESG, the
authors, and working group to read the threads for themselves.  The
salient NANOG archives start at
http://www.merit.edu/mail.archives/nanog/2004-11/ and the PPML
archives are at http://www.arin.net/mailing_lists/ppml/.  Note that
there has been a specific proposal for ARIN to allocate PI space in
the context of this discussion.  I do not know if other RIRs have had
similar discussions or whether similar proposals have been floated to
them.

My original DISCUSS raised three main issues: the reservation of two
/8s where the mechanism for assignment in one was postponed; the
ambiguity presented by the document's focus on "site" (using a term it
chose not to define); and the problems posed by discussing something
as "local" while providing for inter-site routing of these prefixes.
During the course of the original write-up, I said: "If these are
mostly-bogons, but might be valid based on inter-provider agreement,
then this is really a small bit of provider-neutral space with a
mechanism for self-assignment within it.  That's a valuable thing,
maybe a more valuable thing, than what this document says it is
doing".

During the course of discussions, Paul Vixie and Owen DeLong have
argued along the same lines and have argued that the routing
policy presumed by this document will not remain in force.

The document puts forward the routing policy as "They are not expected
to be routable on the global Internet" in the Introduction and goes on
in section 4.1 to say: "The default behavior of exterior routing
protocol sessions between administrative routing regions must be to
ignore receipt of and not advertise prefixes in the FC00::/7 block.  A
network operator may specifically configure prefixes longer than
FC00::/7 for inter-site communication."

Paul Vixie commented on this point on the PPML list, saying

++++

i don't think it'll work like you're saying.  let's say ULA goes into
general use and that a number of enterprises who are all customers of
a set of ISP's decide that rather than tunnelling, they'd like their
shared set of ISP's to "just route the ULA prefixes please."  by
enterprise i'm talking Ford and GM and Daimler and their rust-belt
supply network, or perhaps Wal-Mart and its offshore vendor network.
we know what the ISP's will say: "yes, ma'am, and would you like fries
with that?" 

now let's assume that someone wants to enter one of these enterprise
frays and their ISP is not "part of the collective".  the ISP in
question will not want to allow sheer force to be applied to this
customer, so they'll join the collective either by direct peering or
by tunnels. 

lather, rinse, repeat. 

human action (per von mises and others) automatically turns ULA into
PI over time, with increasing horizons and therefore decreasing
margins between what it means to be "unique" and what it means to be
"global". you cannot legislate human nature, but you can make it take
perverse turns to get where it's going, and make it take longer to get
there, if you want.  i don't want us to do that or even try to do
that.  instead, let's just recognize that a far larger segment of the
enterprise community needs PI than was previously believed, and
transform all ULA arguments to date into "PI reform" arguments,



++++++

Owen's point was similar:

++++

Market forces aren't driving a desire for ULA.  They are driving a
desire for cost effective globally unique addresses.  A good part of
the market does not care about routability or not of those addresses.
A meaningful part of the market does.  ULA will meet the needs of the
former, but, not the latter.

Globally unique address assignments to end users with a rational
policy (the v6 equivalent of 2002-3 at say the /48 or /56 level) would
meet the needs being addressed by ULA and needs not being met by the
ULA proposal.

(Unattributed quote in Owen's original)
>As for the ingress filtering issue, education and contract terms are
>two good answers. I'd like to see network operators considering
>ingress as part of their aggregation router buying decisions, of
>course.

Contract terms are a negotiation.  As soon as dollars are available
for the sake of abandoning an entirely artificial limitation on the
use of addresses, guess which way that negotiation will go.  We'd all
love to see that, but, regardless of the capabilities of the router,
the reality is that when a customer dangles enough dollars in front of
an ISP for advertising their non-routable space that will do no harm
by being advertised to the rest of the internet, they're going to do
the following:

      1.      Warn the customer this may not work out so well for them.
      2.      Do everything they can to get the route accepted.
              (If you think this will actually be hard, think again)
      3.      Take the money.

As to why 2 won't be hard: Think of it this way... Each provider is
going to be faced with such customers fairly quickly.  They're not
going to come to the techies and ask why not and go gently into that
good night.  The sales people are going to see $$ for doing this at
each and every ISP and they're going to drive negotiations between
management at the providers to trade these "harmless" routes.  This
decision will not be made by the operational community, but, inflicted
on it by management seeing $$ for doing so.

Owen noted in a different message:

As I see it, the only effective way to prevent the issue is to change
the general allocation policy to meet all needs and recognize that
globally unique space is globally unique space from a technology
perspective.  From a social engineering perspective, any such
distinctions are purely artificial, and, will be recognized as such
and removed by market economics.  (Or, to put it in terms IETF may
better understand: In the long run, such limitations will be viewed as
damage and simply routed around.)

++++++++++++++++

I actually believe the document is clear that it is describing
provider independent space, but that Paul and Owen mean "PI space" to
include the right of its holder to determine the routing policy in the
normal way, which includes negotiations with peers and upstream
providers on what will be carried.  My interpretation of their
argument is, in other words, that the routing policy set out by this
document will not remain in force. I am, frankly, convinced by their
arguments that the association of this routing policy with these
prefixes is not permanent.

There are several routes forward from that conclusion.  The first
would be to change the specification such that there was a serious
technical impediment to this space being routed on the Internet.  The
most obvious such impediment would be lack of uniqueness, and the
problems with that are well known.  I cannot personally think of other
changes which would imply such an impediment and which would not have
similar problems.  I suspect, in other words, that this way forward is
closed to us.

A second route forward is to assume that the rate of movement away
from this routing policy can be managed such that the appearance of
this PI space in the global V6 routing table will be slow enough not
to cause problems.  A corollary to that is probably that the document
should have stronger language describing the problems unrestrained
growth would cause, as at least some actors will be moved to protect
the commons.  Given that the focus of the document is unmanaged
assignment, relying on those arguments alone to manage growth seems
somewhat problematic, though some would argue that the maximum number
of additional entries is limited because the size of the initial
allocation avoids announcement of multiple prefixes.

The first route forward attempts to keep ULAs local; the second allows
them to drift from local to PI over time.  A third route forward would
be to start from the idea that the real need is for "PI space" as Owen
and Paul have described it--allocation of prefixes which are provider
independent and whose routing policies are determined in the normal
way.  If we are convinced that the routing table can handle the
introduction of the prefixes which will not remain local (and many,
obviously, would), this seems personally to me the best way forward,
and the question then becomes whether this allocation mechanism is
adequate given the *likelihood* of global announcement rather than the
presumption of locality.  If we are not convinced that the routing
table can handle it, then we need to ask ourselves whether it will be
possible for it to handle it within the time scale implied by the
drift in the second route and, if not, what we can do to make them
match.

I recognize that I am, at this point, attempting to convince the
authors and working group to take this document back to a question of
assumptions, and that, as with site local, this is painful.  I hope,
however, that the views of the operational community expressed in the
lists mentioned above are sufficiently strong that the working group
will agree.  I know Stephen Sprunk has followed those discussions in
some detail and others may have as well; in other words, I hope the
conversation has already started.

Whether or not the assumptions are questioned, the issue I raised
related to the allocation of a /7 here remains.  Though the document
has now changed to use a /7 and an "L" bit rather than two /8s, the
fundamental issue is still in play.  The original reserved a /8 for a
purpose (central assignment for ULAs) for which community consensus
has not yet been judged.  This document reserves one of the states of
L for a purpose for which community consensus has not yet been judged.
If the L bit is retained, I strongly recommend defining only the "0"
state, and leaving the "1" state to be defined when community
consensus on the later mechanism has been attained.  One might
imagine, for example, that the decision to assume that these would hit
the routing table might make folks nervous enough of collision that
the extra trillion derived from using both 0 and 1 for self-assignment
would seem wise :).

[Note]: 'Ted, Bill and Alex, could you please check if your concerns have been addressed?  If not, please let me know what issues remain.  Thanks. Question for all:  What should we do regarding possible ARIN issues with this document?' added by Amy Vezza

[Ballot comment]
Reviewed by Michael Patton, Gen-ART

His review of -08:

OK.  I have enough other work that I'm not going to do a full
re-review, but I went through my earlier review and checked all of the
items I found then and they all seem to have been adequately addressed.

[Note]: 'Ted, Bill and Alex, could you please check if your concerns have been addressed?  If not, please let me know what issues remain.  Thanks.

Question for all:  What should we do regarding possible ARIN issues with this document?' added by Margaret Wasserman

[Note]: 'The -08 version has been submitted that should address most (or all?) of the outstanding discusses, but hasn''t been posted yet.  In the meantime, see:
http://people.nokia.net/~hinden/ULA/draft-ietf-ipv6-unique-local-addr-08.txt
Ted, Bill and Alex, could you please check if your concerns have been addressed?  If not, please let me know what issues remain.  Thanks.

Question for all:  What should we do regarding possible ARIN issues with this document?


' added by Margaret Wasserman

[Ballot discuss]
Section 3.1 says that the global ID is 41 bits.

Section 3.2.2 says to use the lower 40 bits of an MD5 calculation as the global ID.  There is an implicit "and set the high bit to 1".

I'd suggest either calling the 8th bit of the address the "global/local" bit and calling the global ID 40 bits, or explicitly stating that the high bit is set in local assignments - otherwise you'll get an implementor who puts 3.2.2 together with 3.1, missing the implicit statement in 3.2, and gets a locally generated local address that's in fc00::/8.

[Ballot discuss]
1. It would be useful to give a definition of a "site", keeping the routing
  aspects in mind.

2. Section 4 "Routing"

>    Any router that is used between sites must be configured to filter
>    out any incoming or outgoing Local IPv6 unicast routes.  The
>    exception to this is if specific /48 or longer IPv6 local unicast
>    routes have been configured to allow for inter-site communication.

>    If BGP is being used at the site border with an ISP, the default BGP
>    configuration must be set to to keep any Local IPv6 address prefixes
>    from being advertised outside of the site or for these prefixes to be
>    learned from another site.  The exception to this is if there are
>    specific /48 or longer routes created for one or more Local IPv6
>    prefixes.

In the above statement, is it assumed that BGP has visibility to site
boundaries, or that it is always used for inter-site connectivity and never for
intra-site? The reason for the question is that requiring default BGP behavior
to be as described above calls for site awareness and implementation change. If
the real intention is that BGP should be _manually_ _configured_ to filter out
local prefixes, the text needs to be changed.

It should be noted that if an link state IGP (OSPF/IS-IS) is used for routing
between sites, which is a possibility in enterprise networks, a single site
should be contained within a single IGP domain or area, as prefix distribution
within a link-state area cannot be controlled.

Section 6.0

>    Site border routers should install a "reject" route for the Local
>    IPv6 prefix FC00::/7.  This will ensure that packets with Local IPv6
>    destination addresses will not be forwarded outside of the site via a
>    default route.  Site border routers should respond with the
>    appropriate ICMPv6 Destination Unreachable message to inform the
>    source that the packet was not forwarded [ICMPV6].  This feedback is
>    important to avoid transport protocol timeouts.
>
>    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
>    specific /48 or longer Local IPv6 prefixes.  The default behavior of
>    these devices should be to install a "reject" route for these
>    prefixes.  Site border routers should respond with the appropriate
>    ICMPv6 Destination Unreachable message to inform the source that the
>    packet was not forwarded.

There's an overlap between the two paras above. The first para covers the
destination address check. The second tries to cover both destination and
source.

First, I'd like to understand exactly what "outside of the site" means in this
section. Does it mean a non-FC00::/7 IPv6 dst address, or a FC00::/7 address
with another global-ID, or both?

Second, do you realize that checking the source address will require changes to
the router's forwarding algorithm compared to how global addresses are handled?

Third, it is a current operational practice to disable ICMP unreachables for
reject routes to avoid ICMP storms cause by infected machines' scanning the
network. I suggest we change it to something like "MAY send, MUST be
configurable, and MUST be off by default".

From rtg-dir (Radia):

The document should be more clear about what the desired behavior is for the
case where two or more sites are connected together.

[Ballot discuss]
1. It would be useful to give a definition of a "site", keeping the routing
  aspects in mind.

2. Section 4 "Routing"

>    Any router that is used between sites must be configured to filter
>    out any incoming or outgoing Local IPv6 unicast routes.  The
>    exception to this is if specific /48 or longer IPv6 local unicast
>    routes have been configured to allow for inter-site communication.

>    If BGP is being used at the site border with an ISP, the default BGP
>    configuration must be set to to keep any Local IPv6 address prefixes
>    from being advertised outside of the site or for these prefixes to be
>    learned from another site.  The exception to this is if there are
>    specific /48 or longer routes created for one or more Local IPv6
>    prefixes.

In the above statement, is it assumed that BGP has visibility to site
boundaries, or that it is always used for inter-site connectivity and never for
intra-site? The reason for the question is that requiring default BGP behavior
to be as described above calls for site awareness and implementation change. If
the real intention is that BGP should be _manually_ _configured_ to filter out
local prefixes, the text needs to be changed.

It should be noted that if an link state IGP (OSPF/IS-IS) is used for routing
between sites, which is a possibility in enterprise networks, a single site
should be contained within a single IGP domain or area, as prefix distribution
within a link-state area cannot be controlled.

Section 6.0

>    Site border routers should install a "reject" route for the Local
>    IPv6 prefix FC00::/7.  This will ensure that packets with Local IPv6
>    destination addresses will not be forwarded outside of the site via a
>    default route.  Site border routers should respond with the
>    appropriate ICMPv6 Destination Unreachable message to inform the
>    source that the packet was not forwarded [ICMPV6].  This feedback is
>    important to avoid transport protocol timeouts.
>
>    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
>    specific /48 or longer Local IPv6 prefixes.  The default behavior of
>    these devices should be to install a "reject" route for these
>    prefixes.  Site border routers should respond with the appropriate
>    ICMPv6 Destination Unreachable message to inform the source that the
>    packet was not forwarded.

There's an overlap between the two paras above. The first para covers the
destination address check. The second tries to cover both destination and
source.

First, I'd like to understand exactly what "outside of the site" means in this
section. Does it mean a non-FC00::/7 IPv6 dst address, or a FC00::/7 address
with another global-ID, or both?

Second, do you realize that checking the source address will require changes to
the router's forwarding algorithm compared to how global addresses are handled?

Third, it is a current operational practice to disable ICMP unreachables for
reject routes to avoid ICMP storms cause by infected machines' scanning the
network. I suggest we change it to something like "MAY send, MUST be
configurable, and MUST be off by default".

[Ballot comment]
Reviewed by Michael Patton, Gen-ART

Things that should get fixed, from his review:

The last paragraph of Section 3.2 is self-contradictory.  It says this
document only defines the centrally assigned addresses and that the
centrally assigned addresses are defined in another document.  I
believe it meant to say that this document only defines the locally
assigned addresses.



Minor comments, not enough to require a rev of the document...but since
the preceding does, these could be considered as well.

In section 3,2 where it describes the "Two assignment methods", I
would suggest use of the terms "guaranteed unique" and
"probabilistically unique" to describe their properties.  I could
offer specific wording, if desired.

This document references RFC1750 (as [RANDOM]).  A new version (which
I understand to be greatly improved) is in development (currently it's
draft-eastlake-randomness2-08.txt).  If that's almost ready to go, I'd
suggest making this draft reference that.  But, it's a normative
reference, so I don't recommend holding this document up very long
waiting for it.  Perhaps if draft-eastlake-randomness2 makes it into
the front of the RFC Editor queue before this one comes out the end
an RFC number can be assigned and used in the RFC version of this
draft.

In section 3.2.3 second paragraph.  To be pedantic it's not the fact
that the IDs are chosen randomly that makes collisions possible, but
rather the fact that they are chosen independently.  I'm sure that
this difference probably won't matter to most readers, but the lead in
on that paragraph could be changed to "Since global IDs are chosen
independently, ..." to make it slightly more rigorously correct.

In the fourth paragraph of Section 4.0, the grouping on the long
sentence is ambiguous and can result in two distinct meanings being
deduced (and the several typos don't help).  One of those meanings is
clearly nonsense to anyone with routing clue, but just to be sure
nobody uses that meaning, I suggest this rewording:

  If BGP is being used at the site border with an ISP, the default
  BGP configuration must filter out any Local IPv6 address prefixes,
  both incoming and outgoing.  It must be set both to keep any Local
  IPv6 address prefixes from being advertised outside of the site as
  well as to keep these prefixes from being learned from another
  site.  The exception to this is if there are specific /48 or longer
  routes created for one or more Local IPv6 prefixes.

I don't actually think that [POPUL] is a Normative reference, since
it's only used in "why we think this is sufficient" contexts.  The
reference isn't used in "how to implement" contexts.

[Ballot comment]
Section 3.2.2 makes use of MD5.  While MD5 is probably fine for this
  application, I strongly prefer SHA-1.  I propose the replacement
  of steps 4) and 5) with the following:
 
    4) Compute an SHA-1 digest on the key as specified in [FIPS, SHA1];
        the resulting value is 160 bits.
    5) Use the least significant 40 bits as the Global ID.

    [FIPS]  Federal Information Processing Standards Publication
              (FIPS PUB) 180-1, Secure Hash Standard, 17 April 1995.
    [SHA1]  D. Eastlake 3rd and P. Jones,  US Secure Hash Algorithm 1
              (SHA1), RFC 3174, September 2001.

  Section 3.2.2 provides an algorithm, but not source code.  I think
  the title of the section should be changed.

  Global change: s/IPSEC/IPsec/

[Ballot comment]
Section 3.2.2 makes use of MD5.  While MD5 is probably fine for this
  application, I strongly prefer SHA-1.  I propose the replacement
  of steps 4) and 5) with the following:
 
    4) Compute an SHA-1 digest on the key as specified in [FIPS, SHA1];
        the resulting value is 160 bits.
    5) Use the least significant 40 bits as the Global ID.

    [FIPS]  Federal Information Processing Standards Publication
              (FIPS PUB) 180-1, Secure Hash Standard, 17 April 1995.
    [SHA1]  D. Eastlake 3rd and P. Jones,  US Secure Hash Algorithm 1
              (SHA1), RFC 3174, September 2001.

  Section 3.2.2 provides an algorithm, but not source code.  I think
  the title of the section should be changed.

  Global change: s/IPSEC/IPsec/

[Ballot discuss]
There's a lot to this, but one of the biggest issues is that the document
reserves for FC00::/8 for central assignment, but says:

  This document only allocates the prefix (FC00::/8) for centrally
  assigned local IPv6 addresses.  The characteristics and technical
  allocation requirements for centrally assigned Local IPv6 addresses
  will be defined in a separate document.

This strikes me as extraordinarily unwise.  Once allocated, this prefix
is gone into the equivalent of RFC 1918 space, and no matter what
wisdom we provide on how to global allocate addresses, people are
free to be as stupid about this as they were about net 10.  We can't
stop people shooting themselves, but handing them a gun and saying
"safety manual to come" seems a bit much.  What actual harm is there
in waiting on this assignment until the documents are written?

The next big issue with this is that it never defines what it means by
"site".  The text about looks like this text could be inferred as "a site for the
purposes of this identifier is the set of interconnected networks which
agree to route these local addresses."  Yeah, it's circular, but it makes
clear that it is the agreement to route them that defines a site for the
purpose of a particular local address.  There are, of course, other
potential definitions of site (some implied by the 3.2 discussion of the split
between those who might use the two different /8s, for example), but they
are not explored.  An explicit definition of the term looks like an awfully good
idea to me, if only to prevent later exploration of that space.

I'm also concerned about this issue in the context of the "inter-site"
routing discussion, for example, here:

  Any router that is used between sites must be configured to filter
  out any incoming or outgoing Local IPv6 unicast routes.  The
  exception to this is if specific /48 or longer IPv6 local unicast
  routes have been configured to allow for inter-site communication.

This gets complicated quickly.  If these are bogons, it is hard enough
to get them well filtered.  If these are mostly-bogons, but might be
valid based on inter-provider agreement, then this is really an allocation
of a small bit of provider-neutral space with a mechanism for self-assignment
within it.  That's a valuable thing, maybe a more valuable thing, than what
this document says its doing.  But I don't think you can conceive of them
as "local", then talk about inter-site passage of routing data without
using an overlay network construct to define the "site" as crossing what
might be some other boundary.

In the context of 6.0, the authors might want to review the recent
posting by Sean Donelan on NANOG found here:

http://www.merit.edu/mail.archives/nanog/msg01741.html

The line "too many boxes still crumble" makes me wonder who will
be able to do a real job of this.  After all, a "reject" route can still
leave packets using these as source addresses being sent out into
the wild.  They may not come back, but that doesn't help the global
Internet quite as much as the operators might like.

The advice in paragraph 2 of Section 8 seems like it is totally contrary
to the advice in the paragraph before it, possibly because they mean
"use split DNS" but don't say it.  Getting this clear might also
help clarify the advice in 9.0.

Speaking of which, let me channel Randy Bush a moment as I read this:


      - Nodes that are to be limited to only communicate with other
        nodes in the site:  These nodes should be set to only
        autoconfigure Local IPv6 addresses via [ADDAUTO] or to only
        receive Local IPv6 addresses via [DHCP6].  Note: For the case
        where both global and Local IPv6 prefixes are being advertised
        on a subnet, this will require a switch in the devices to only
        autoconfigure Local IPv6 addresses.

"Oh!  I thought we were talking about the *Internet*"

I have no idea what the "Note:" section is supposed to mean, and
I'm not sure I care.  The idea that this set of steps will prevent
confusion between differently scoped addresses seems, at best,
a fond hope.  And this statement in the "Reasons" section:

    - Applications can treat these addresses in an identical manner as
        any other type of global IPv6 unicast addresses.

seems contradictory.  If an application can expect to find, store, and cache these
addresses in a consistent DNS in case one and not in case two, the two cases
are not identical.

Or so it seems to me.

[Ballot comment]
Section 3.2.2 provides an algorithm, but not source code.  I think
  the title of the section should be changed.

  Global change: s/IPSEC/IPsec/

[Ballot discuss]
Section 3.2.2 makes use of MD5.  While MD5 is probably fine for this
  application, I strongly prefer SHA-1.  I propose the replacement
  of steps 4) and 5) with the following:
 
    4) Compute an SHA-1 digest on the key as specified in [FIPS, SHA1];
        the resulting value is 160 bits.
    5) Use the least significant 40 bits as the Global ID.

    [FIPS]  Federal Information Processing Standards Publication
              (FIPS PUB) 180-1, Secure Hash Standard, 17 April 1995.
    [SHA1]  D. Eastlake 3rd and P. Jones,  US Secure Hash Algorithm 1
              (SHA1), RFC 3174, September 2001.

[Ballot discuss]
Section 3.2.3 is confusing.  It presents an analysis of the probability of a collision in terms of the number of "connections" between the networks.  You don't define networks, and you don't define what the probability means.  You need to state it this way:  "for a given network with one or more random global ID that has interconnections to other such networks, having in aggregate a total of N such IDs, the probability that that two or more of these N IDs will collide is ..."  As written, the text can be interpreted to be talking about TCP connections or the probability of a collision anywhere in the Internet.  (My wording takes into account the possiblity of more than one prefix per network, per 3.3)

Please justify the ban on AAAA records for such addresses.  In most cases, it's desirable to have all non-link-local addresses for a host in the DNS, because it lets applications use a uniform mechanism for finding a host.  The alternative would seem to be two-faced DNS servers, a concept that has never worked that well.  (Do the appropriate DNS WGs concur with this recommendation?)  By contrast, I agree that PTR records should not be used, since it would create a large number of  non-aggregatable delegations in the inverse map tree.  But that should be explained, too.

[Ballot comment]
Section 7 says that "AAAA and PTR records for locally assigned local IPv6 addresses are not recommended to be installed in the global DNS."  Some text to explain why would be helpful.

[Note]: 'Draft will be split into two separate drafts -- one with the randomly allocated addresses, and one with the registered addresses.' added by Margaret Wasserman

Submission Questionnaire:

1) Have the chairs personally reviewed this version of the ID and do
  they believe this ID is sufficiently baked to forward to the IESG
  for publication?

Yes.

2) Has the document had adequate review from both key WG members and
  key non-WG members? Do you have any concerns about the depth or
  breadth of the reviews that have been performed?

Review has been from many people in the IETF community, including Geoff
Huston for the RIR community.  We have no concerns about the reviews performed.

3) Do you have concerns that the document needs more review from a
  particular (broader) perspective (e.g., security, operational
  complexity, someone familiar with AAA, etc.)?

We would expect more detailed discussion regarding the IANA
considerations  section instructing the IANA to set up an allocation
authority for Unique Local IPv6 addresses.  This shouldn't be a show
stopper for advancing the document as the document carefully sets
requirements and the IANA can setup the allocation authority as it sees
fit.  Note, that it is important to advance the document prior to this
being settled as the document also allows for local assignment
independent of a central assignment authority.

4) Do you have any specific concerns/issues with this document that
  you believe the ADs and/or IESG should be aware of? For example,
  perhaps you are uncomfortable with certain parts of the document,
  or whether there really is a need for it, etc., but at the same
  time these issues have been discussed in the WG and the WG has
  indicated it wishes to advance the document anyway.

This document captures the consensus of the WG.

5) How solid is the WG consensus behind this document?  Does it
  represent the strong concurrence of a few individuals, with others
  being silent, or does the WG as a whole understand and agree with
  it?

The general topic area has been contentious for quite some time. However, we believe that this document does represent the consensus of
the many and vocal members of the working group.  It fills a need that
many people have articulated on the mailing list and in working group
meetings.

6) Has anyone threatened an appeal or otherwise indicated extreme
  discontent?  If so, please summarize what are they upset about.

This has been a contentious topic, but we are unaware of any planned
appeal.

7) Have the chairs verified that the document adheres to _all_ of the
  ID nits?  (see http://www.ietf.org/ID-nits.html).

Yes.

- Technical Summary

This document defines an IPv6 unicast address format, called Unique
Local IPv6 Unicast Addresses, that is globally unique and is intended
for local communications.  There are two ways to allocate these
prefixes.  These are centrally by a allocation authority and locally by
the site.

These addresses are intended to be the replacement for the Site-Local
IPv6 addresses that are being deprecated.  The ULA addresses offer a
similar facility without the drawbacks associated with Site-Local
unicast addresses.

- Working Group Summary

The IPv6 working group has done extensive review of this document and
this document reflects the consensus of the group.

- Protocol Quality

This document has been reviewed by members of the ipv6@ietf.org
mailing list and by the working group chairs.

Sent AD evaluation comments to IPv6 WG:

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.