El 10/05/2006, a las 18:49, Durand, Alain escribió:

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.


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



   - Alain.



-----Original Message-----
From: Fred Baker [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 10, 2006 11:31 AM
To: Pekka Savola
Cc: v6ops@ops.ietf.org; David Woodhouse; ipv6@ietf.org
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
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------



--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to