Re: RFC3484 problem: scoping with site-locals/ULAs

[marcelo bagnulo braun <[e-mail]>]

Hi Fred,

actually what you are suggesting could be very useful not only to  
support this case, but also other cases where the peers have multiple  
address with equal general characteristics but with different  
reachability status. In particular, consider the multihoming case,  
where two multihomed hosts want to establish a communication. In this  
case, each of the peers have multiple addresses, associated with  
different interfaces and/or different providers. In case that there is  
an outage, maybe some of the address pairs used for the communication  
are not working. In order to be able to establish a new communication  
the initiator needs to try with different address pairs and see if they  
are working. One of the options is what you mention below.
In the multihoming scenario we have identified that this is a problem  
that need to be fixed (though as you mention it is not trivial to  
solve). Actually, in the multihoming case, there is an additional  
difficulty that different source address may have different reverse  
path reachability status, so in order to actually establish the  
communication, a host may need to try with different _source_ address  
and different destiantion addresses.

Regards, marcelo

PS: in case that someone is interested, this problem is described in
ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-bagnulo-ipv6- 
rfc3484-update-00.txt


El 10/05/2006, a las 18:30, Fred Baker escribió:

> So I have a dumb question.
>
> Why not:
> 	- use a DNS lookup that asks for all records (including A, MX, and  
> AAAA)
> 	- open both a v4 and a v6 connection simultaneously
> 	- accept the first to successfully open and shut down all others
>
> Down sides: It gets all of the DNS data, which may be more than it  
> wanted to know, and it issues a second SYN-or-whatever, and in the  
> worst case one to each address. But it deterministically finds a  
> solution that works and gives the system the service it is looking  
> for.
>
> I the big picture, the problem with that behavior is what?
>
> On May 9, 2006, at 7:27 AM, Pekka Savola wrote:
>
>> 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
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>


--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------