I am learning that policy based selection is not easy, and I'm only
responding to the 6man list because a reply was directly solicited.
The answer for policy based selection to me is probably to go for
further abstraction and have multiple classifiers and preference rules
combined in a meta language that relates directly to the classifications
and prioritization rules of 3484, rather than trying to stuff everything
into one single table that is based on pattern-matching against address
prefixes, and then hard coding preferences in a ruleset.
e.g. a match rule of what constitutes a global address or not? What
constitutes a deprecated address? What constitutes a public address or a
temporary address? What constitutes native transport or not? What
constitutes a preference?
These match rules are not at all trivial, and not all characteristics
and classifications used in RFC 3484 are suited to an approach based on
pattern-matching source and destination address-prefixes alone e.g.
protocol uses a tunnel rather than native transport, or protocol family
provides global connectivity, are very difficult to express purely in
terms of address prefixes. We can shoe-horn most current solutions in
there today, but there are cracks and there's no guarantee at all that
future transports or preference requirements will fit neatly into this
scheme. What about the dollar cost of radio links whilst roaming
internationally for example?
These classifiers could then be combined in a meta language something
akin to today's policy based routing and DSCP classification to generate
the ordered list of connections to try.
Downside is configuration flexibility leads to implementation
complexity. But it might be less obscure in the long run when trying to
predict results of table changes in advance.
On the other hand, we might be wise simply to advise network managers
not to override RFC3484 bis defaults. I readily admit that predicting
RFC3484 behavior in advance does my head in sometimes.
In a World of highly mobile devices with multiple interfaces, and bring
your own devices, it's going to be tough to get the right policy on an
end node that matches the network(s) it is currently connected to.
Pretend you've already got RFC3484 bis AND communication of the RFC 3484
policy table via DHCPv6 in place. What happens when your smart phone is
connected to 4G and Homenet? Whose RFC 3484 bis table do you believe? At
least in a meta language based approach, you might be able to set a high
preference for interfaces that cost less dollars (WiFi interfaces over
4g interfaces from your own provider over 4g interfaces from 3rd parties).
All of which in turn might mean that the true answer for providing good
connectivity to users might be to "try everything in parallel and see
what works best for this particular app based on executing my local
rules code" = Happy Eyeballs++
I don't think that I am expressing a concenus view, or giving you
constructive edits to RFC 3484 bis, so I'll shut up now.
Good luck and thanks for picking up this challenge.
Arifumi Matsumoto wrote:
Hi,
I'm catching up an old thread.
On 2011/08/13, at 21:48, Philip Homburg wrote:
In your letter dated Sat, 13 Aug 2011 12:17:29 +0200 you wrote:
I still think there's an issue with the suggested blanket global
treatment of IPv4 RFC1918 addresses.
Quote draft-ietf-6man-rfc3484-revise-04 "This issue can be fixed by changing t
he
address scope of private IPv4 addresses to global."
IMVHO I think it is highly likely that over time this assumption will not hold
true:
think end game when IPv6 native only networks are widely deployed and CGN is t
urned off.
At that time there's still probably going to be many (local) NAT boxes
that advertise an IPv4 default route and serve RFC1918 DHCP addresses to clien
ts,
but cannot provide global connectivity.
So whatever you assume about RFC1918 addresses has a good chance of being inco
rrect
unless you can truly detect/confirm presence of global IPv4 connectivity via N
AT.
Ah, tricky.
For destination addresses we have 3 possibilities: v4-only, v6-only, and
dual-stack.
Obviously, without global IPv4 connectivity, connecting to v4-only destinations
is not going to work, no matter what you put in the policy table. Connecting
to v6-only destinations doesn't involve v4, so that's not an issue either.
For dual stack, connecting over v6 is preferred unless one v6 address is
6to4 or teredo. Given that you are unlikely to have 6to4 or teredo in
that kind of environment, that's not going to be the local address.
So there is one remaining corner case. If the remote address is 6to4 or
teredo, then the policy table will prefer IPv4.
I'm not sure it's worth making thing more complex just o handle this corner
case.
Philip, thank you for great considerations.
I agree that the above corner case is the only situation where
the broken IPv4 connectivity does some harm.
I can imagine another case where IPv6 connection falling back to IPv4.
However, when a connection falls back, it takes tens of seconds,
so it is bad enough regardless of the existence of broken IPv4
connectivity. So, I think this is trivial.
Ray, do you think 3484-bis should treat this issue of RFC1918 address
scope ?
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
