[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RFC 3484 address selection problem statement comments
(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
.. 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
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
==> 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
==> 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
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
==> 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.
==> 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
==> 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..
Matsumoto, A., "Practical Usages of Default Address
Selection Policy Distribution",
draft-arifumi-ipv6-policy-dist-00 (work in progress),
Fujisaki, T., "Distributing Default Address Selection
Policy using DHCPv6",
draft-fujisaki-dhc-addr-select-opt-01 (work in progress),
==> 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
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings