Subject: Re: Moving to WGLC 3484-bis?

From: Arifumi Matsumoto <[email-masked]>
Date: Tue, 25 Oct 2011 20:24:58 +0900

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 ?

---

From: Ray Hunter <[email-masked]>
Date: Tue, 25 Oct 2011 14:58:01 +0200

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.