Subject: RE: RFC3484 problem: scoping with site-locals/ULAs

From: "Durand, Alain" <[email-masked]>
Date: Wed, 10 May 2006 11:49:03 -0400

In my previous live, we were all using a large server for many things.
That server had 17 physical interfaces. Each interface had one IPv4
address
and 2 IPv6 addressses. Each client had also one IPv4 address and two
IPv6 addresses.

That makes the total combination: 17*2*2 for IPv6 plus 17*1*1 for IPv4,
that is 85.

Trying them all at the same time for potentially hundreds of clients,
many of them on different subnets than any of the 17 interfaces, is
overkill.

   - Alain.

> -----Original Message-----
> From: Fred Baker [mailto:[email-masked]] 
> Sent: Wednesday, May 10, 2006 11:31 AM
> To: Pekka Savola
> Cc: [email-masked]; David Woodhouse; [email-masked]
> Subject: Re: RFC3484 problem: scoping with site-locals/ULAs
> 
> 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
> [email-masked]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 

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

---

From: Fred Baker <[email-masked]>
Date: Wed, 10 May 2006 09:03:58 -0700

On May 10, 2006, at 8:49 AM, Durand, Alain wrote:
> Trying them all at the same time for potentially hundreds of  
> clients, many of them on different subnets than any of the 17  
> interfaces, is overkill.

Of course it is. But the discussion here is of the fact that we are  
trying very hard to pick one, and the one doesn't work.

I'm thinking that there must be a way to pick enough of them that one  
of the ones picked in fact works. And starting out by getting both  
the IPv4 and IPv6 addresses in the same step seems like a rational  
starting place.

---

From: David Woodhouse <[email-masked]>
Date: Wed, 10 May 2006 17:13:10 +0100

> trying very hard to pick one, and the one doesn't work. 

Actually, it _isn't_ that hard just to pick the right one, in the
general case. We used to do it on Linux purely by coincidence, and it's
not hard to restore that behaviour.

What do other systems do in the situation I described, btw?

-- 
dwmw2

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 11 May 2006 09:53:09 +0300

> many of them on different subnets than any of the 17 interfaces, is

right, but i guess it should be possible to define some heuristics to 
reduce the number of attempts since it is likely that several of those 
addresses have the same reacahbility status. I mean, i guess that the 
option would be to put an upper limit to the number of simultaneous 
packets that are issued to different destinations, and try to select 
the selected addresses smartly enough to achieve the biggest 
probability to get at least one working. Criteria like using different 
prefixes, using different next hops using different address families 
and so on should help here imho

regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 11 May 2006 13:02:25 +0300

El 11/05/2006, a las 12:10, David Woodhouse escribió:

> On Thu, 2006-05-11 at 09:53 +0300, marcelo bagnulo braun wrote:
>> addresses have the same reacahbility status.
>
> RFC3484 is a defined set of heuristics which reduces the number of
> initial attempts... to one.
>
> It _works_, in general -- it just needs fixing for the corner case 
> Pekka
> and I described. That fix is as simple as an extra line in the default
> label/precedence table.
>

but my point is that there is a scenario that may be quite common where 
similar problems occur, the case of multihomed hosts that have multiple 
gloabl addresses. This scenario includes both the case of a host with 
multiple interfaces and the case of a host with a single interface 
within a multihomed site which obtains multiple PA prefixes from its 
providers. In this case, the problems are very similar and they are no 
so easily fixed (because you need also to retry with different source 
addresses in some cases)

so an approach as the one suggested by Fred would address all this 
family of cases that imho would be relevant in many cases

(of course alternative approaches could be defined also, but my goal at 
this stage is to acknowledge that this is an issue)

regards, marcelo

> It was (is) hard and slow enough getting applications to adapt to
> getaddrinfo() and RFC3484. I don't think it buys us much to talk of
> another change now... especially one which involves multiple
> simultaneous attempts to connect, then just discarding the connections
> which are slower to respond.
>
> In today's world of tunnels, that solution would share the problem that
> glibc's existing 'favour IPv4 unconditionally' solution has -- you'll
> end up using IPv4 instead of IPv6 a _lot_ of the time, and IPv6 will 
> get
> very little use or testing. My ISP may offer native IPv6-in-PPP on my
> DSL line, but that's unfortunately the exception rather than the norm,
> and the IPv4 connection is usually going to win the race against an 
> IPv6
> connection which goes through tunnels.
>
> -- 
> dwmw2
>

---

From: David Woodhouse <[email-masked]>
Date: Thu, 11 May 2006 10:10:00 +0100

It _works_, in general -- it just needs fixing for the corner case Pekka
and I described. That fix is as simple as an extra line in the default
label/precedence table.

In today's world of tunnels, that solution would share the problem that
glibc's existing 'favour IPv4 unconditionally' solution has -- you'll
end up using IPv4 instead of IPv6 a _lot_ of the time, and IPv6 will get
very little use or testing. My ISP may offer native IPv6-in-PPP on my
DSL line, but that's unfortunately the exception rather than the norm,
and the IPv4 connection is usually going to win the race against an IPv6
connection which goes through tunnels. 

-- 
dwmw2