Subject: Fwd: Responses to IESG Comments on ULA Draft

From: Alex Zinin <[email-masked]>
Date: Fri, 22 Oct 2004 16:34:51 -0700

FYI, to set the context for my follow-up message.
Guys, you should really pay attention to this one.
It seems quite twisted, and I'd like to know your
opinions on this doc.
-- 
Alex
http://www.psg.com/~zinin

This is a forwarded message
From: Bob Hinden <[email-masked]>
To: Harald Tveit Alvestrand <[email-masked]>, [email-masked],   [email-masked], Alex Zinin <[email-masked]>, [email-masked],   [email-masked], [email-masked]
Cc: Bob Hinden <[email-masked]>,   Brian Haberman <[email-masked]>,   Margaret Wasserman <[email-masked]>,   Thomas Narten <[email-masked]>
Date: Wednesday, October 20, 2004, 5:14:44 PM
Subject: Responses to IESG Comments on ULA Draft

===8<==============Original message text===============
Harald, Steve, Bill, Alex, Scott, Russ, Ted,

Thanks for your comments on this document.

We would like to say that we think approving this document is an important 
step in replacing IPv6 site-local addresses.  The ULA addresses provide an 
improved alternative to site-local and having that alternative will give 
people who are currently using site-local something to replace it with.  We 
think it is very important for the IESG to approve this promptly.

Detailed responses and proposed changes to your comments are inline 
below.  We hope we can come to agreement on these changes in the next few 
days so a new draft can be submitted before the ID deadline and in time for 
the next IESG meeting.

An updated draft with the changes proposed below can be found at:

   http://people.nokia.net/~hinden/draft-ietf-ipv6-unique-local-addr-07.txt

along with an diffed version at:

   http://people.nokia.net/~hinden/draft-ietf-ipv6-unique-local-addr-07.html

Thanks,

Bob Hinden & Brian Haberman

>DISCUSSES AND COMMENTS:
>======================
>Harald Alvestrand:
>
>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.

Actually, the text is correct.  It 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.

We are open to suggestions as to how to say this clearer.  Is the following 
better?

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

>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.

Assuming <draft-eastlake-randomness2-08.txt> will replace RFC1750 and they 
are equivalent we could likely make this change during the RFC-Editor 48 
hours if the new draft is in the RFC editor queue by then.  We don't think 
it is worthwhile to delay this to wait for the new draft to be approved.

>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.

Good point.  We can update the text to make this clearer.

>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.

We agree this is an improvement.  Thanks.

>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.

OK

>Steve Bellovin:
>
>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)

We propose the following text for paragraph 2 of section 3.2.3:

Since global IDs are chosen randomly (and independently), it is
possible that separate networks have chosen the same global ID.
For any given network with one or more random global IDs that has
inter-connections to other such networks, having a total of N such IDs,
the probability of that two or more of these IDs will collide can be
approximated using the formula:

>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.

ARRRGHHHH!!!!!  There is considerable disagreement on what to say about 
adding these addresses to the DNS or not adding them.  The current text 
results from comments from Geoff Huston during the IETF last call and 
considerable discussion on the working group mailing list.  We see the 
choices as:

A) Current text (i.e., don't recommend adding the global DNS).

B) Allow AAAA in global DNS but disallow PTR records.

C) Allow AAAA and PTR in global DNS.

What we suggest is sending the issue to the DNSOPS working group to develop 
operational guidance (after this is published) and change the text here as 
follows:

    7.0 DNS Issues

    At the present time AAAA and PTR records for locally assigned local
    IPv6 addresses are not recommended to be installed in the global DNS.
    The operational issues relating to this are beyond the scope of this
    document.

>Bill Fenner:
>
>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.

Good point.  We propose to change the text in 3.2.2 "Sample Code for 
Pseudo-Random Global ID Algorithm" to add the following step that should 
clarify the issue:

      6) Concatenate FD00::/8 and the 40 bit Global ID to produce a
         48 bit locally assigned IPv6 local address prefix.

>Ted Hardie:
>
>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?

We disagree with the above characterization (i.e., reserving the FC00::/8 
prefix will create the equivalent of RFC1918 space).  This reservation is 
no different from any of the other IPv6 addresses space that is 
reserved.  We don't see any reason to justify the above claim.  If people 
want something like net 10, then they will just continue to use site-local 
addresses.

The technical justification for reserving this space now it to allow 
filters to be created that will handle both the locally and centrally 
assigned ULAs.  Not reserving them now might well result in two different 
filters to have to be installed.

>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.

The issue of defining a site has been discussed extensively within the
IPv6 community.  The consensus has been that a formal definition of
site will be of little benefit.  A loose definition of site provides network
operators the ability to define sites in a manner most useful for their
situation.  All IPv6 w.g. documents that deal with sites have taken this
approach (IPv6 Address Architecture, Scoped Address Architecture, etc.).
Given this consensus, the authors do not see strong justification to
change this document.

>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.

See response to Alex Zinin below.  We think it clarifies the issue raised.

>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.

There is other text in the draft that requires packets with ULA source 
addresses to be filtered.  The requirement to check source addresses 
already exists for other types of IPv6 addresses.  For example link-local 
addresses.  This is defined in the IPv6 address architecture.

>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.

The text in paragraph 2 and 3 is meant to put the onus on the address 
selection policy engine in a node if more sophisticated behavior is desired 
than just treating all global and local unicast addresses the same.

>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*"

Please note the title of the section that this text was included, namely 
"Use of Local IPv6 Addresses for Local Communications".  This section is 
discussing how to use these address inside of a site to limit some nodes to 
local communication.

>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.

The subparagraph cited is about how to control the configuration of ULA 
addresses.  Given the section in question deals with intra-site issues, the 
note is meant as guidance on the possible issues needed to be addressed 
operationally.

>Or so it seems to me.
>
>Scott Hollenbeck:
>
>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.

See response to Steve Bellovin above.

>Russ Housley:
>
>Discuss:
>
>   I changed my position to NO-OBJECTION, and moved the text of
>   my original position to a comment.

Thanks!

>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.

We will change the algorithm to use SHA-1.

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

We propose to change the title to: Sample Pseudo-Random Global ID Algorithm

>   Global change: s/IPSEC/IPsec/

Will do.  We note there was only one place to change :-)

>Alex Zinin:
>
>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.

We mean that BGP should be _manually_  _configured_.  It was not the intent 
to require the BGP protocol to change.  Does the revision of this paragraph 
earlier in the email resolve the issue?  If not, please suggest changes.

>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.

Good point.  We propose to add the following text:

For link-state IGPs, it is recommended that a site utilizing ULA
prefixes be contained either within one IGP domain or area.  By
containing a ULA prefix to a single link-state area or domain, the
distribution of prefixes can 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.

Yes, That is intentional.

>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?

It means 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?

There are various other places in IPv6 where routers are required to check 
source addresses.  Specifically for link-local addresses and for site-local 
(deprecated).

>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".

We believe that is it is very difficult (or perhaps impossible) to do the 
kind of address scanning with IPv6 that can easily be done with 
IPv4.  Since most nodes have addresses that are created with 64-bit 
interface identifiers that are derived from L2 MAC addresses, it is a very 
sparse space.  In other words it would take a very long time to scan 2^^64 
possible addresses in a specific /64 prefix.

In addition, ICMPv6 includes mechanisms to limit the sending of ICMP error 
messages.

The IPv6 scoped addressing architecture specifies the use of destination 
unreachable when addresses are out of scope.  We belive this is a useful 
hint to a nodes address selection algorithm.

> 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.

This is a reasonable idea, but we think it is outside of the scope of this 
document.  This might well be a good topic for V6OPS to take on.

===8<===========End of original message text===========

---

From: Alex Zinin <[email-masked]>
Date: Sat, 23 Oct 2004 22:10:49 -0700

[resending with correct rtg-dir alias]

Bob, et al-

Inline below.

> think it is very important for the IESG to approve this promptly.

I appreciate the sense of urgency. I think we should also agree that this
document is significant enough to make sure that it has been reviewed properly
by the relevant parts of the community (which is what I consider to be one of
the functions of the IESG). Depending on where our discussion goes, it may be
necessary to bring this document for further review in the RTG area. I'm cc'ing
RTG-DIR for that purpose too.

>>Alex Zinin:

I read through your answers below, and then reread routing-related parts of the
document. I think the source of possible confusion is the fact that
implementation requirements and operational guidelines are not properly
identified and are mixed together. This is why I'm having a problem
understanding whether you mean something should be done by the routers
automatically or you expect routers to be configured to do that. I think this
section needs to be rewritten with this distinction in mind, probably separating
the two aspects in subsections.

>    routes created for one or more Local IPv6 prefixes.

I don't think this change alone is enough. I would prefer to see operational
routing guidelines separated out and this part moved there.

I also would like to understand what the exception described in the last
sentence really means.

> distribution of prefixes can be controlled.

This would be good to put in the operational guidelines subsection.

> source addresses.  Specifically for link-local addresses and for site-local 

I would argue that the link-local case is quite different from what you describe
above, and the check for site-locals was one piece of complexity that we wanted
to avoid.

On the whole thing above though, you should be very specific on what you would
like to be implemented in the router code (i.e. done automatically) and what you
expect/recommend to be configured by default using e.g. static routes and ACLs.
Depending on the answer certain things may become [un]feasible and/or some
additional details will have to be specified.

> possible addresses in a specific /64 prefix.

This makes it harder (impossible) to find another host that can be infected,
but doesn't prevent using routers as "icmp generators", since one needs to
hit an address that does NOT exist for an unreachable to be sent.

> In addition, ICMPv6 includes mechanisms to limit the sending of ICMP error 

we have this in IPv4 implementations too, yet the problem is there

> hint to a nodes address selection algorithm.

I overlooked this in the arch draft, unfortunately--mere human :)

> document.  This might well be a good topic for V6OPS to take on.

Well, this does affect evaluation of the proposed mechanisms, though. In other
words, we can't assess whether proposed mechanism & operational practices are
correct or advisable unless we know what you're trying to achieve.

Alex