Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-unique-local-addr-02.txt

From: Bob Hinden <[email-masked]>
Date: Tue, 03 Feb 2004 11:27:54 -0800

Pekka,

Thanks for the comments.  I will respond to the substantial issues and 
semi-editorial in your email.  The editorial ones look fine and should be 
to include them in the next version of the draft.

>substantial
>-----------
>
>1) specifying just one allocator to the end-sites; this is always bad
>and prone to create monsters such as ICANN.

I don't see how the current text would "create monsters such as 
ICANN".  All we are talking about is assignment of local 
prefixes.  Somewhat more limited scope than what ICANN has.

>It seems like that the model should be provided to support
>enough registries (e.g. 2 bit = 4 or 3 bits = 8).  Just to make sure that
>the customers can pick someone else's service unless they aren't satisfied
>with an organization, so that there is some incentive not to have too high
>charges, to avoid the claims of building monopolies who get free money for
>numbers, etc.etc.
>Unless you have instructions in mind for IANA who should have this registry
>monopoly, there should probably be multiple registries in the only one of
>them screws up in a major way (e.g., compare to the mess with .com zone by
>verisign).

The text in the IANA considerations section calls for the IANA to set up a 
"allocation authority" for the centrally assigned ULA prefixes.  The exact 
details of how to do this (i.e., one or many organizations doing the 
assignments, who it is, etc., etc.) are left to the IANA as long as they 
meet the requirements stated in the document.

I am comfortable with the IANA doing this in a manner that will be 
beneficial from the community.  It is also, of course, out of scope for the 
IETF to specify more than the allocation requirements, which this document 
does do.
We have learned from past experience it's not wise to over specify when 
asking the IANA to do address allocation.  I think the current text is 
about right in this regard.

Also, if the resulting allocation authority becomes too onerous for some 
people, they can use the locally assigned prefixes.  No one is forced to 
use the central allocations.

>2) The specification requires that routing protocols special-case these
>prefixes by MUST filtering them.  This is unacceptable, and should be
>removed.  Any filtering should be done by the sites themselves.  Note that
>running any other protocol than BGP is not feasible anyway to be run over
>administrative domains (exclusing provider-provisioned VPNs, maybe, but
>those are special case anyway), so we can pretty much limit the discussion
>to BGP.  Which is pretty trivial, because 1) why would the ISP advertise
>such prefixes, and 2) why would the site not filter out stuff it doesn't
>want.
>
>    Any routing protocol that is used between sites MUST filter out any
>    incoming or outgoing Local IPv6 unicast routes.  The exception to
>    this is if specific /48 IPv6 local unicast routes have been
>    configured to allow for inter-site communication.

I agree this could be stated better.  I think it would be good to change it 
to "Any router that is used between sites....", as it is not the routing 
protocols doing the filtering, but the router based on it's 
configuration.  The requirement is that the FC00::/7 is filtered by default 
by routers at the site boundary.  As Brian Carpenter pointed out if there 
is a filter for this prefix configured by default in all routers, it does 
no harm as sites that wish to use these addresses would add more specific 
routes that would override the default filters for these more specific 
prefixes.

>    If BGP is being used at the site border with an ISP, filters MUST be
>    installed by default in the BGP configuration 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 routes created for one or more
>    Local IPv6 prefixes.
>
>3) Similar to the above, there are some particularly inpractical issues with
>site-border security:
>
>    Site border routers SHOULD install a black hole route for the Local
>    IPv6 prefix FC00::/7.  This will insure 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
>    other Local IPv6 prefixes.  The default behavior of these devices
>    SHOULD be to filter them.  Site border routers SHOULD respond with
>    the appropriate ICMPv6 Destination Unreachable message to inform the
>    source that the packet was not forwarded.
>
>.. this is inpractical, and should be reworded.  The site border routers
>cannot know that they are site-border routers, so these checks cannot be
>implemented.  What you can do is state that a toggle SHOULD be implemented
>and when enabled on an interface, it would apply these kind of restrictions
>to it.  But the point is that you WILL need administrator action.  "Deny by
>default" just is not practical approach here, because you don't know that
>you should be denying these by default.

I don't agree. As stated above if the /7 prefix is filtered by default, it 
does no harm.  But I think changing the text to make it clearer that these 
routers should be configured to do this filtering would make the text clearer.

>    Additionally, domain border routers connecting autonomous systems
>    throughout the Internet SHOULD obey these recommendations for site
>    border routers.
>
>==> as for this, I have no idea what this even tries to say, so it requires
>rewording.

It is trying to say that routers that connect autonomous systems also be 
configured to do this filtering.  Even if they are not at site 
boundaries.  How about:

      Routers that maintain peering arrangements between Autonomous
      Systems throughout the Internet SHOULD obey the recommendations for
      site border routers unless configured otherwise.

>semi-editorial
>--------------
>
>      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).
>
>==> hopefully the centrally assigned global IDs don't use their
>(single) computer's EUI-64 in the generation :-)

I don't think this is a problem.  Every time the algorithm is run the time 
would change resulting in a new distinct allocation.  The MD5 hash 
guarantees it.

>      4) Compute an MD5 digest on the key as specified in [MD5DIG].

>==> security folks have been pushed for the use of SHA-1 because it's more
>collision-proof.  It doesn't matter much in this specific context, but at
>least nobody would object if you changed this to using an SHA-1 digest.

As you said, "it doesn't matter...".

>    Site border routers SHOULD install a black hole route for the Local
>    IPv6 prefix FC00::/7.
>
>==> I think you mean "a reject route" ? (or a "discard" route might
>also work OK)

I agree this should be changed to a "reject route".  Mukesh Gupta also 
pointed this out during the discussion of the new ICMPv6 destination 
unreachable codes.

>    For future study names with Local IPv6 addresses may be resolved
>    inside of the site using dynamic naming systems such as Multicast
>    DNS.
>
>==> this seems irrelevant and should be removed; above, it already
>states someting general about local naming systems.

I don't see it doing any harm either.

>    Local IPv6 addresses, like global scope unicast addresses, are only
>    assigned to nodes if their use has been enabled (via IPv6 address
>    autoconfiguration [ADDAUTO], DHCPv6 [DHCP6], or manually) and
>    configured in the DNS.
>
>==> "and configured in the DNS" is not requirement and is irrelevant; should
>be removed?
>
>    assign them.  In order for a node to learn the Local IPv6 address of
>    another node, the Local IPv6 address must have been installed in the
>    DNS.
>
>==> s/DNS/DNS or another naming system/ ?

Thanks.  Both changes are fine.

>11.2 Disadvantages
>
>==> Add to disadvantages:
>
>    - Instead of using global unicast addresses inside the sites, the
>      sites may be tempted to start using Local IPv6 addresses excessively,
>      instead of using global unicast addresses and reachability restrictions
>      such as firewalls or access control lists

I think this is out of scope for this document.

Thanks again for your comments.

Bob

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Tue, 3 Feb 2004 22:13:48 +0200 (EET)

Inline..

> meet the requirements stated in the document.

I read "an allocation authority" as singular, just one organization.  
As the space is specified to be non-hierarchical and the randomizer 
algorithm is specified to use LSB 40 bits for centrally allocated 
prefixes, this does strongly imply a single organization (or 
organizations with a pretty well-synched up database :).

> beneficial from the community.  It is also, of course, out of scope
> for the IETF to specify more than the allocation requirements, which
> this document does do. We have learned from past experience it's not
> wise to over specify when asking the IANA to do address allocation.  
> I think the current text is about right in this regard.

If folks think this is OK, it's fine by me.  Clarification in IANA 
considerations like "If deemed appropriate, the authority may also 
consist of multiple organizations performing the authority duties" 
might be in order though.

> I agree this could be stated better.  I think it would be good to
> change it to "Any router that is used between sites....", as it is
> not the routing protocols doing the filtering, but the router based
> on it's configuration.  

But then it's an operational guidance, right?  Maybe not uppercase 
material?

> The requirement is that the FC00::/7 is
> filtered by default by routers at the site boundary.  As Brian
> Carpenter pointed out if there is a filter for this prefix
> configured by default in all routers, it does no harm as sites that
> wish to use these addresses would add more specific routes that
> would override the default filters for these more specific prefixes.

Please check my response to Brian.  There is a very specific
difference of "FC00::/7 reject route" and "FC00::/7" filter.  If you
mean the former -- fine, it works in most cases (except the stub
router and no IGP case I mentioned) -- if the latter, you're in for a
lot of trouble.  Something like this would be very difficult to
implement properly.

> routers should be configured to do this filtering would make the text clearer.

"Filtered" has entirely different implications whether it's "done"  
(inpartially) with a reject route, or done with access lists.  See my
note to Brian.  "access-lists by default" pretty much by definition
WILL block the more specifics, and are difficult to deploy or specify
here.

>       site border routers unless configured otherwise.

Ok, that's understandable.  But again, why use an uppercase SHOULD
keyword?  This is a requirement for operators, not a protocol
interoperability issue?

> would change resulting in a new distinct allocation.  The MD5 hash 

Sure, but the amount of entropy given as input to the has function is
significantly lower.  For central allocations this is probably not a
problem.

> As you said, "it doesn't matter...".

If you feel so.  This might come up at IESG review from security ADs 
though :).

> I don't see it doing any harm either.

This is an unnecessary plug for Multicast DNS.

(btw, if it stays, it should be reworded for better english..)

> I think this is out of scope for this document.

Applicability statements or reality checks are in scope for all kinds 
of documents. :)

I don't think this document has any chance of passing through the 
other reviews unless it spells out its usability (and especially 
nonusability!) better.

I'm not sure that adding a rather architectural disadvantage is enough 
but it could be a start.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Bob Hinden <[email-masked]>
Date: Wed, 04 Feb 2004 12:23:25 -0800

Pekka,

>Inline..

likewise...

>organizations with a pretty well-synched up database :).

That was certainly the original intent, but at the same time I don't think 
the current text limits it to a single organization as long as the 
allocations are made in a manner as if a single organization was doing 
it.  For example, if the IANA ran the algorithm a million times and then 
assigned a hundred thousand of the prefixes to ten organizations (and then 
repeated as required) that would be consistent with text and satisfy your 
concern about a single organization.

Note, I don't have the same issue you have with a single organization, so 
opinions vary on this.  I think the current text is a reasonable middle ground.

>might be in order though.

I will take a look at the IANA considerations text and see what can be done.

>But then it's an operational guidance, right?  Maybe not uppercase

I don't have any problem making this change, but I don't understand the 
difference between upper and lower case in these sections.

>lot of trouble.  Something like this would be very difficult to

The intent was "reject route".  I will clarify the text.

>WILL block the more specifics, and are difficult to deploy or specify

I will clarify that it should be a "reject route".  That also consistent 
with providing the ICMP feedback.

>keyword?  This is a requirement for operators, not a protocol

As above, please explain the difference?

>significantly lower.  For central allocations this is probably not a

Agreed.

>If you feel so.  This might come up at IESG review from security ADs

I am sure they will have something to say whatever is in the document :-)

>(btw, if it stays, it should be reworded for better english..)

OK.

>Applicability statements or reality checks are in scope for all kinds

But as can be seen from the volume of mail on the merits of appropriate use 
of local vs. global addresses, opinions do vary widely on this.  I don't 
think it would be very productive to repeat that discussion.

>I'm not sure that adding a rather architectural disadvantage is enough

I agree that as this document progresses through the process other changes 
will likely be required.  Has any document ever gone from a w.g. through 
the IESG without any changes :-)

Thanks,
Bob

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 5 Feb 2004 17:41:10 -0800 (PST)

Is it only I that find it odd that talking about Multicast DNS
is viewed to be in-scope for this document, while talking about the
applicability issues for the addresses *defined by this document*
is stated to be out of scope??

  Erik

---

From: Pekka Savola <[email-masked]>
Date: Fri, 6 Feb 2004 08:49:34 +0200 (EET)

On Wed, 4 Feb 2004, Bob Hinden wrote:
> I don't have any problem making this change, but I don't understand
> the difference between upper and lower case in these sections.

[and:]

> As above, please explain the difference?

As far as I can see, upper-case MUST/SHOULDs are something
implementations should do.  In addition to those, specifications often 
also include some language giving advice (or even stronger than that) 
to operators of the products based on those implementations what they 
should do.

IMHO, the document should be very clear which statements are  
"operator advice/requirements" which "implementation requirements".. 
because the implementors (from whom we'll be collecting implementation 
reports etc.) *cannot* ensure that such advice/ops-reqs are followed 
-- if they could, it would be an implementation requirement.

One way to achieve this would be to describe operational aspects in a 
separate section (e.g., "Operational Considerations and Requirements") 
which should make this clearer.  Another way could be avoiding 
upper-case keywords and stating clearly that these are requirements or 
advice placed on the operators of the specification, not the 
implementers.

Hope this clarified how I see the difference between an implementation 
requirement and operational advice.

---

From: Bob Hinden <[email-masked]>
Date: Fri, 06 Feb 2004 02:04:35 -0800

Erik,

>is stated to be out of scope??

Reasonable point.  I will remove the reference to Multicast DNS.

Bob