RFC 3484 address selection problem statement comments

[Pekka Savola <pekkas@netcore.fi>]

Hi,

(Crossposting as RFC 3484 update is being discussed on int-area..)

A few comments on:

     Problem Statement of Default Address Selection in Multi-prefix
        Environment: Operational Issues of RFC3484 Default Rules
               draft-arifumi-v6ops-addr-select-ps-00.txt

.. which I believe is a good start at gathering bits and pieces for 
RFC 3484 update.

Comments below, mostly relating to making it clearer what the actual 
problem is (but this is to be expected in a -00 problem statement 
draft :-):

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

Section 2.1.3. Half-Closed Network Problem
....
   This network environment is commonly used in practice because the
   access-line to the ISP2 might actually be a VPN tunnel over ISP1 and
   the Internet.

==> it's not clear what you're using as a justification in saying that the
network environment is commonly used in practice.  Typical enterprise VPN
deployments (so far as I've seen) often route all the traffic through them
(i.e., are connected to the Internet).  Are you referring to ones which only
route enterprise's IP traffic to the enterprise?  Or that because you don't
actually need a second physical network connection (you can use logical one
as well), connecting to a half-closed network is easy?  In any case, this
calls for a bit of rewording.

   In NAP [I-D.ietf-v6ops-nap], the use of ULA is recommended from a
   security point of view.  That document proposes the use of ULA for
   internal communication and filtering those packets with ULA address
   at Gateway.

==> I think this should be rephrased.  I don't think ULA is necessarily
"recommended" in general, but rather in those scenarios where you need
certain functionality.  Maybe say:

   As NAP [I-D.ietf-v6ops-nap] describes, using ULA may be beneficial in
   some scenarios.  If ULA is used for internal communication, packets with
   ULA addresses need to be filtered at Gateway.

2.1.5 Site Renumbering

==> you describe a site renumbering scenario, but it's not clear what's the
exact address selection problem here.   Make it clearer.

   It would be better if you could turn the temporary address on and
   off.  It would also be better if you could switch its usage per
   service(destination address).  The same situation can be found when
   using HA and CoA in MobileIP network.

==> as a matter of fact, RFC 3484 already includes a MUST that
implementations should provide similar kind of toggle.  I don't it has been
that widely implemented though... Maybe state clearer that the problem isn't
so much about specification but with implementation.

2.2.1. IPv4 or IPv6 prioritization

==> this section doesn't spell out the problem.  You probably meant to say
that configuring the RFC 3484 preferences on each host separately is too
cumbersome.

2.2.2.  ULA and IPv4 dual-stack environment

   This is a special form of IPv4 and IPv6 prioritization.  When an ISP
   has IPv4 Internet connectivity but does not yet have IPv6 Internet
   connectivity, and the ISP wants to provide site-local IPv6
   connectivity, ULA is the best choice for site-local IPv6
   connectivity.

==> I doubt there are "ISPs" as such which offer ULA addresses.  You
probably meant an Enterprise instead of ISP.

==> later on, you also don't describe the exact problem.  Given that we
already have RFC4191 which allows advertising more specific routes, that
would mitigate this problem.  I guess at least part of the issue is that
RFC4191 support isn't yet widely enough deployed?


2.2.3.  ULA or Global Prioritization

   It is very common to differentiate services by the client's source
   address.  IP-address-based authentication is an extreme example of
   this.  Another typical example is a web service that has pages for
   the public and internal pages for employees or involved parties.  Yet
   another example is DNS zone splitting.

   However, ULA and IPv6 global address both have global scope, and
   default rules do not specify which address should be given priority.
   This point makes IPv6 implementation of address-based service
   differentiation a bit harder.

==> the last paragraph should answer the question "given priority .. where?"
In applications?  Note that different deployments have very likely exactly
the opposite goals, so one-size-fits-all solution might be different to come
by (though I'm not sure if folks have tried).  You should maybe describe the
exact problem at a bit more length -- maybe configuration of this
priorization is not easy enough (in a host, or site-wide)?

4.  Security Considerations

   This is a problem statement draft.  Security considerations need to
   be identified for each solution.

==> I'm not sure if this is an appropriate short cut :-).  You should be
asking yourself, "does any of the problems mentioned have significant security
issues?".  If yes, those should be mentioned so that that could be used as a
factor when deciding which ones need to be addressed and how urgently.






editorial
---------

==> the document should use the documentation prefix(es) throughout the
document (e.g., instead of 6bone or v4 private addresses).

   Another approach is to configure the gateways but not the Host and
   make use of packet redirection between the gateways.

==> s/but not the Host and/to/ (seems redundant..)

   RFC 3041 [RFC3041] defines a Temporary Address, which is a cutting-
   edge technique.  The usage of Temporary Address has both pros and
   cons.  It is good for viewing web-pages or communicating with the
   general public, but it is bad for a service that uses address-based
   authentication.

==> I'm not sure if I'd call RFC 3041 "cutting-edge" technique anymore..
It's already a bit old :-)

==> solely "address-based authentication" is typically discouraged, so this
is a potential for rat-holing discussions..

   [I-D.arifumi-ipv6-policy-dist]
              Matsumoto, A., "Practical Usages of Default Address
              Selection Policy Distribution",
              draft-arifumi-ipv6-policy-dist-00 (work in progress),
              December 2005.

   [I-D.fujisaki-dhc-addr-select-opt]
              Fujisaki, T., "Distributing Default Address Selection
              Policy using DHCPv6",
              draft-fujisaki-dhc-addr-select-opt-01 (work in progress),
              December 2005.


==> these should likely be informative references, at least the latter one..

6.2.  Informative References

==> on the other hand, some of these (at least the ULA doc) should be
normative..

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