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

From: Pekka Savola <[email-masked]>
Date: Mon, 2 Feb 2004 15:53:12 +0200 (EET)

On Mon, 26 Jan 2004, Brian Haberman wrote:
>       This is the start of an IPv6 working group last call on:
> 
> >         Title           : Unique Local IPv6 Unicast Addresses
> >         Author(s)       : R. Hinden, B. Haberman
> >         Filename        : draft-ietf-ipv6-unique-local-addr-02.txt
> >         Pages           : 16
> >         Date            : 2004-1-21

Below are my comments.  I don't think we really need this kind of 
stuff, but as local addressing seems to have been taken as granted 
already, I don't argue on those grounds. (However, at some point I 
believe someone will make you insert a better applicability statement 
on where to (not) use the local addressing.. you could very well try 
to do it now.)

As for the rest, I have a major concern on picking just one registrar 
for the central allocations.  I also have major deployment and 
implementation concerns with "default deny" policies; they seem to be 
unacceptable or unfeasible.  The security of local addressing must be 
based on the fact that the site administrator has toggled on a switch 
or configured the access-lists -- NOT on protocols having to filter 
out the addresses, or having some kind of default access-lists 
magically deny all the traffic at vague site borders.

Below..

substantial
-----------

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

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

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.

   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.

   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.

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

     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.

   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)

   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.

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

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.

editorial
---------

==> please include the IPR and copyright sections if possible..

INTERNET-DRAFT                                          R. Hinden, Nokia
January 20, 2004                                 Brian Haberman, Caspian
                                                                                                
==> s/Brian/B./ (same style :)

   This document defines an unicast address format that is globally
 
==> s/an/an IPv6/

      interface ID      64-bit IID as defined in [ADDARCH].

==> s/IID/interface ID/

   prefix and Global ID field length.  There is a direct tradeoff
 
==> s/Global ID/global ID/  -- or at least be consistent whether it starts
with the upper case in the middle of sentence or not (the same with a few
other places)

   needlessly.  A reasonable way of evaluating a specific field length
   is to compare it to a projected 2050 world population of 9.3 billion
   [POPUL] to compare the number of resulting /48 prefixes per person.
 
==> s/to compare/and/ (the latter "to compare")

      Prefix   Global ID      Number /48          Prefixes     % of IPv6
               Length         Prefixes            per Person   Address Space

==> s/Number/Number of/

==> IPv6 Address Space goes beyond 72 words/line, which is bad.

   A very high utilization ratio of these allocations can be assumed
   because no internal structure is required in the field nor is there
   any reason to be able to aggregate the prefixes.

==> sounds soooo awkward, maybe reword:

   A very high utilization ratio of these allocations can be assumed
   because the global ID field does not require internal structure,
   and there is no reason to be able to aggregate the prefixes.

...
   The authors believes that a /7 prefix resulting in a 41 bit Global ID
  
==> s/believes/believe/

   exhausted.  If more than this was needed, then additional IPv6
   address space could be allocated for this purpose.

==> s/was/were to be/ ?

   should not be assigned sequentially or with well known numbers.  This
   to ensure that there is not any relationship between allocations and
 
==> s/This/This is/

   duplicate assignments.  The local assignments are free and do not
   need any central coordination or assignment, but have a lower (but
 
==> remove "are free and" due to removing the 10 euro charge text?
(without coordination or assignment, there certainly can't be any
fee to them :)

   This is easiest to accomplish if there is a single source of the
   assignments.

==> sounds funny, maybe s/of/for/ ?

   addition to web based registration they should support some methods
   like telephone, postal mail, fax, telex, etc.  They should also

==> perhaps it has been long enough to be able to remove "telex" from the
list :-)

  It is escrowed to insure there are no duplicate allocations and in
 
==> s/insure/ensure/ (the same elsewhere)

   makes it easy to get a prefix with out the need to contact an

==> s/with out/without/

   is adequate for sites planning a small to moderate amount inter-site
   communication using locally generated global IDs.  Sites planning
 
==> s/amount/amount of/

   [ICMPV6]  Conta, A., S. Deering, "Internet Control Message Protocol
             (ICMPv6) for the Internet Protocol Version 6 (IPv6)
              Specification", RFC1885, December 1998.
==> old reference.

   [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
             3", RFC 2026, BCP00009, October 1996.

==> remove this, unused reference.

   [RTP]     Schulzrinne, H., S. Casner, R. Frederick, V. Jacobson,
             "RTP: A Transport Protocol for Real-Time Applications"
             RFC1889, January 1996.

==> use RFC3550 instead.

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

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 02 Feb 2004 15:50:58 +0100

Pekka,

As I am packing for a 3.5 week trip, I don't have time to go into full
detail. I mostly disagree with you on the big points (your smaller
points are fine), but these are not new arguments anyway.

> and prone to create monsters such as ICANN.  

That's unfair language. ICANN is not a monopolist.

> enough registries (e.g. 2 bit = 4 or 3 bits = 8).

It might indeed be wise for IANA to only hand out 1/8 of the space
to the first registry - that would leave flexibility to create
more if competition proved necessary.

>    configured to allow for inter-site communication.

I do agree this is badly phrased - it isn't the *protocol* that
does the filtering, it's the default router config. Just as NATs
are shipped with an effective "deny all" configured, IPv6 routers
should be shipped with "deny FC00::/7" configured.

And it's because so many corporate security solutions now depend
on that effective "deny all", much as you and I may hate it, that
we need this.

You can certainly deny by default. A site that wants to use FC00::/7
internally or on VPNs can enable it where needed.

   Brian

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 

*** I will be on vacation February 3-25, 2004 ***

---

From: Pekka Savola <[email-masked]>
Date: Mon, 2 Feb 2004 19:40:53 +0200 (EET)

> > and prone to create monsters such as ICANN.  
7> That's unfair language. ICANN is not a monopolist.
> more if competition proved necessary.

Well, I just feel quite uncertain of the current model -- we're 
basically telling IANA to find someone to build a monopoly by selling 
IP addresses.  Not so different from what RIRs do, of course, but at 
least they pretend the addresses don't cost anything.  Here we WANT 
them to cost money.  Monopolies and money for (pretty much) nothing 
seems like a bad idea.

The only thing that seems to cost a significant amount of money in the 
proposal is to have a possibility to get the addresses over phone, 
fax, or whatever -- so that they cannot be processed automatically.  

On further thought, requiring non-Internet -based mechanisms doesn't 
seem to be worth the trouble, because those can't be (semi)automated.  
Anyone requiring such addresses can find a place to surf to a website, 
or send an email.  If not, they have other things to worry about (or 
can use the locally generated ones if they really want).

> should be shipped with "deny FC00::/7" configured.

It would be trivial to say that the devices SHOULD (or MUST) be
shipped with a built-in reject route for FC00::/7 -- this is simple
and very easily implemented but then note that:

 - this only affects packets which are forwarded (destination address)
 - in source address, it would not be checked
 - the routers would have to know participate in the IGP, i.e., stub 
decide couldn't just point a default route towards the site's internal 
infrastructure (I'm not so sure how realistic this is).

On the other hand, making this a firewall / access-list policy is
pretty much unworkable because whether it would be activated or not
would depend on the existance of the more specific routes.  This would
be a very unwelcome connection between the filters and routing tables.

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