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

[Arifumi Matsumoto <a@arifumi.net>]

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

Comments below.

Pekka Savola wrote:
> 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.

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

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

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

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

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.

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

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.


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

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.

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

Enterprise sounds reasonable.

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

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.

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

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

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

OK.
I'll try in the next rev.

> editorial
> ---------
>
> ==> the document should use the documentation prefix(es) throughout the
> 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.

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

OK.

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

I agree.

> ==> solely "address-based authentication" is typically discouraged, so this
> 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.


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

OK.

I really appreciate your comments.