RFC3484 problem: scoping with site-locals/ULAs

[Pekka Savola <pekkas@netcore.fi>]

Hi,

I was alerted to a practical deployment problem. As a result Linux 
glibc has started prefering IPv4 by default... so, I believe we need 
to find a better solution.

1) v6 site-local address selection problems

A site has deployed IPv6 site-local addresses (alongside with NATed 
v4).  They do not have global IPv6 reachability yet, but want to test 
IPv6 alongside IPv4 internally.

As a result, RFC 3484 address selection breaks: when trying to connect 
to a hostname with a public IPv4 and IPv6 address, the host will first 
try v6 fails (incurring about 3 min TCP timeout if ICMP error is not 
sent), and after that connects to the v4 address.

I.e., 'prefer matching scope' has v6 globals and site-locals, while v4 
has globals and private v4 addresses, and v6 wins, with bad results.

An easy fix could be that v4 is preferable to v6 if both have 
mismatching scope as v4 is likely to be NATed while v6 isn't.

Has anyone else run into this problem?  Is there something I'm 
missing?  What has been the implementation (or deployment) approach 
here?

(I don't believe using RFC 4191 to advertise only the site-local 
prefix instead of a default route is a feasible solution here. 
Likewise, requiring that routers will always send back an ICMP error 
and the host gets it and honors it seems unfeasible in general.)

2) v6 ULA address selection problems

Deploying ULAs doesn't help here, it just makes the problem worse as 
you couldn't even use the 'matching scope' tweak.

Do we need to specify that v6 ULAs should be treated as "site scope" 
for the purposes of default address selection, or something else?

Note that I do not believe it's sufficient to require that each site 
(and each host within the site) deploys non-default RFC3484 policies.

--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings