Subject: [Int-area] RFC 3484 address selection problem statement comments

From: Pekka Savola <[email-masked]>
Date: Sun, 9 Jul 2006 16:05:11 +0300 (EEST)

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

_______________________________________________
Int-area mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/int-area

---

From: Arifumi Matsumoto <[email-masked]>
Date: Fri, 28 Jul 2006 20:00:25 +0900

Pekka,
thank you for your comments.
I'm really sorry for very late reply.

Comments below.

Pekka Savola wrote:
> .. which I believe is a good start at gathering bits and pieces for RFC 
> 3484 update.
> 
> problem is (but this is to be expected in a -00 problem statement draft 
> :-):
> 
> substantial
> -----------
> 

Correct. Here, I just wanted to say this case doesn't demand two physical
network connections. As you mention it, this description may remind an
enterprise VPN, so it should be re-written "you don't need a physical 
network connection".

>    ULA addresses need to be filtered at Gateway.

Thank you. Let me use these phrases in the next rev.

> exact address selection problem here.   Make it clearer.

This is a implementation issue of lifetime. As Tim Chown reported
in the past IETF meeting, there are some OSes that doesn't handle
IPv6 address lifetime correctly. So you cannot achieve smooth
renumbering described in RFC4192.

Even if this problem is solved, a site administrator have to supply
two prefixes for a long time(2 hours or more) to renumber his site.
I suppose it is preferable if he can control when to finish renumbering.

These problems may not be solved by revising RFC3484, though.

> so much about specification but with implementation.

Yes, the first point(toggle) is already included and implemented in some OSes.
What I want to stress is the 2nd point, that is fine-grained control
of temporary address.

> that configuring the RFC 3484 preferences on each host separately is too

Please note that this document doesn't raise problems that should be
solved in the revised RFC3484. It just raises address selection related 
problems that probably happens when a site administrator doesn't take
a countermeasure.

About this section, the problem is a newly-IPv6-connected site easily 
experiences network degradation.

> probably meant an Enterprise instead of ISP.

Enterprise sounds reasonable.

> RFC4191 support isn't yet widely enough deployed?

RFC4191 is surely one of the solutions.
But it's not commonly used yet. Moreover I suppose it's not
common to think of using RFC4191 in network environment like this.

> priorization is not easy enough (in a host, or site-wide)?

Again, I don't try to propose one perfect solution.
I just raised a likely-to-happen problem.

What I wanted to say here is that access control cannot be easily
implemented mainly because of the scope of ULA. (Not like a site-local address.)

> factor when deciding which ones need to be addressed and how urgently.

OK.
I'll try in the next rev.

> document (e.g., instead of 6bone or v4 private addresses).

Well, I wanted to use two very separate prefixes like 2001: and 3ffe: to
make problems clearer. I'll re-write by using two doc prefixes.

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

OK.

> It's already a bit old :-)

I agree.

> is a potential for rat-holing discussions..

Of course, address-based auth isn't the only application.
As another example, site internal access shouldn't be from
temporary address for logging purpose.

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

OK.

I really appreciate your comments.