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

From: Pekka Savola <[email-masked]>
Date: Tue, 9 May 2006 17:27:16 +0300 (EEST)

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
--------------------------------------------------------------------

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 9 May 2006 18:32:15 +0300

> 1) v6 site-local address selection problems

I assume you refer to the deprecated but Linux kernel-supported 
site-local fec0::/12 address space (not sure if it is /12 - but 
anyway).

> 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 am pretty sure it used to work “properly”... when trying to connect() 
to some public IPv6 address while the host only had link-local and 
site-local addresses, the stack would immediatly (non-blocking) address 
unreachable. Then software using the getaddrinfo() paradigm would 
fallback to IPv4 without the user noticing any delay. But then indeed, 
it seems to be now broken.

> you couldn't even use the 'matching scope' tweak.

Yes, I definitely have had these issues. Since ULA have global scope, 
there is no way to detect the issue there.

Another (Linux-specific) issue is that source address selection is 
completely broken, so if you have both public addresses and ULAs on the 
host, the stack might be an ULA (non-routable!) address as source when 
sending packets toward a public address. But that, I guess, it because 
Linux does not implement source address selection properly.

That said I don't think defaulting to IPv4 in libc is wise, and it will 
actually break in other case. Linux users should probably rather 
refrain from using ULAs until their OS supports them properly.
I'm actually pretty sure some apps rely on getaddrinfo() returning 
AF_INET6 entries before AF_INET. Inverting the ordering might cause 
serious troubles there.
This is ***definitely*** going to break listening TCP socket 
applications that relied on IPv6-mapped IPv4 addresses to catch both IP 
protocol versions with a single socket. This includes noteworthy Apache 
httpd 2 and OpenSSH, and probably a bunch of other server apps. This 
could, to a lesser extent also affect the UDP and “outgoing” TCP 
cases... in fact, whenever one uses IPv6-mapped IPv4 addresses.

-- 
Rémi Denis-Courmont
http://www.simphalempin.com/home/
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Eliot Lear <[email-masked]>
Date: Tue, 09 May 2006 17:49:48 +0200

Pekka,

Where is DNS in this picture?  How did you get the v6 address that
didn't work?

Eliot

---

From: David Woodhouse <[email-masked]>
Date: Tue, 09 May 2006 15:58:26 +0100

> and the host gets it and honors it seems unfeasible in general.)

That's the ideal case, of course -- but there is unfortunately still
software out there (and, more to the point, in _here_) which will just
use the first result from getaddrinfo() and not fall back to the others
even if it does get an immediate failure.

This _used_ to work on Linux systems until recently. This is because
glibc will use UDP connect() and getsockname() to determine (src, dest)
address pairs, and in the past the connect() would fail if the host had
only site-local addresses and was asked to connect to a global IPv6
address. That behaviour of the kernel has now changed, and the dummy
connect() succeeds.

Glibc's RFC3484 support is described at
http://people.redhat.com/drepper/linux-rfc3484.html

I think it would suffice to add a label for fec0::/16 in the default
table, so that in the case where we choose between RFC1918->Global IPv4
and Site-local->Global IPv6, the former is ordered first by virtue of
Rule 5 -- because the labels match on the IPv4, but not on the IPv6.

That's the behaviour we always _did_ have under Linux, although
seemingly by coincidence.

-- 
dwmw2

---

From: David Woodhouse <[email-masked]>
Date: Tue, 09 May 2006 17:00:27 +0100

> Where is DNS in this picture?  How did you get the v6 address that

Public DNS for hosts which have both AAAA and A records. www.kame.net,
for example.

>From an internal network as described (RFC1918 IPv4 addresses with
global connectivity through NAT, site-local IPv6), this is what I used
to get for such hosts:

In Fedora Core 4, glibc would always return the IPv4 address first.

In Fedora Core 5, glibc would return the unreachable IPv6 address first.

In the pending update to FC5's glibc, the precedence table has been
changed so that IPv4 addresses are _always_ favoured over IPv6.

That means that even on hosts which _do_ have a global IPv6 address,
it's going to give me the IPv4 address first and IPv6 is never going to
get tested.

I think that a better solution to 'fix' the current kernel+glibc would
be for glibc's default RFC3484 table to contain a separate label for
fec0::/16, so that in the above situation, the IPv4 destination address
gets chosen by Rule 5.

-- 
dwmw2

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 10 May 2006 10:35:15 +0300

> (and each host within the site) deploys non-default RFC3484 policies.

but this seems a reasonable option...
I mean, only the end user (or the end site admin) knows if they 
actually have a nat and the domain where the ulas are routable.

I may agree that today it is likely that if the host needs to choose 
between a private v4 address and a ULA (wihtout any additional 
information) the defaul behaviour should be to preffer the v4 private 
to communicate with a global destiantion address, since it is likely 
that the v4 private address is natted, while the destiantion is outside 
the domain of routability of the ula

bottom line is:

ulas and private address can be used to reach a global destiantion 
address heavily depending on the local setup, hence local configuration 
per case is needed in the general case...

OTOH, the default settings should work for the more general case, so, i 
guess that in general it is more likely to be able to reach a global 
dst with a v4 private than with a ula...

regards, marcelo

---

From: Eliot Lear <[email-masked]>
Date: Wed, 10 May 2006 13:52:27 +0200

David & others,

If I understand the problem correctly, no matter whether you prefer IPv4
or IPv6 the presumption that is failing us is that if the interface has
an A or AAAA record associated with it then it is reachable on that
address.  And yet DNS has no real understanding of reachability except
in the crude case of split DNS.  Would this be a reasonable assessment
or did I blow it?

Eliot

---

From: Fred Baker <[email-masked]>
Date: Wed, 10 May 2006 08:30:41 -0700

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:

> glibc has started prefering IPv4 by default... so, I believe we  
> need to find a better solution.
>
> v4).  They do not have global IPv6 reachability yet, but want to  
> test IPv6 alongside IPv4 internally.
>
> 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.
>
> Likewise, requiring that routers will always send back an ICMP  
> error and the host gets it and honors it seems unfeasible in general.)
>
> 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.
>
> --

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 10 May 2006 18:45:38 +0300

Le Mercredi 10 Mai 2006 10:35, marcelo bagnulo braun a écrit :
> address heavily depending on the local setup, hence local
> configuration per case is needed in the general case...

This assumes that one may use an ULA (IPv6) to reach a globally routable 
(IPv6) address. In other words, that someone has introduced some kind 
of NAT or transparent proxy in the middle. I'm not so gullible as to 
believe that nobody will ever try to implement this, but... if some 
network administrator really wants to provide “transparent” IP-layer 
access to the globally routable IPv6 Internet, shouldn't (s)he hands 
out public IPv6 addresses/prefix(es) to his/her users, possibly in 
addition to ULAs?

What would be wrong with the IPv6 stack throwing an unreachable error 
whenever an application tries to send a packet/connect to a global IPv6 
address while its socket is bound to an ULA or while the host has no 
global (or at least has no non-ULA-nor-link-local) addresses?

---

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

On Wed, 2006-05-10 at 13:52 +0200, Eliot Lear wrote:
> address.

Er, no. Unless I misunderstand what you're saying, it had nothing to do
with the problem at all. :)

You seem to be talking about whether there's an A or AAAA record
referring to the _local_ address? Without doing reverse and then forward
DNS lookups, I don't even see how we could establish such a thing. It
wasn't what I meant.

While I quite like the idea that one's networking should completely fail
unless one has valid reverse and forward DNS, it's not really relevant
to what I was talking about :)

The problem is this:

I have a local host with IPv4 address 192.168.x.x and IPv6 address
fec0::YYYY. IPv4 is routed to the outside world via NAT, as you would
expect. IPv6 from that site-local address is not routed to the outside
world -- as you would also expect.

I use glibc's getaddrinfo() to fetch addresses for an external host, for
example olpc1.infradead.org (2001:8b0:10b:1:2e0:4cff:fe03:3d7a,
81.187.226.98).

Glibc's implementation of RFC3484 is described at
http://people.redhat.com/drepper/linux-rfc3484.html -- it uses
SOCK_DGRAM connect() and then getsockname() to determine the local
address which would be used for any given remote address.

On older Linux kernels, glibc's connect() from fec0::YYYY to
2001:8b0:10b:1:2e0:4cff:fe03:3d7a would fail. Thus, glibc would return
the IPv4 address 81.187.226.98 first. And all would be well.

On current Linux kernels, the connect() succeeds. Glibc now returns the
IPv6 address 2001:8b0:10b:1:2e0:4cff:fe03:3d7a first in its results, and
the connection does not succeed. This causes problems:

1. Because some software is _still_ buggy and gives up after the first
   address doesn't work, without falling back to the next.
2. Because sometimes the routers don't respond with an unreachable ICMP
   so we end up with a three-minute timeout before it connects.
3. Because sometimes the routers _do_ respond with an unreachable ICMP
   and this causes the kernel to drop its default route entirely rather
   than just learning that it can't reach _that_ host. So all internal
   IPv6 further than the local network also breaks.

OK, all these three are bugs which need to get fixed. And I haven't
investigated #2 and #3 very hard yet but I've seen them both.

Nevertheless, the upshot of this is that I cannot run radvd on these
networks -- I would get lynched.

It's arguably correct that the connect() succeeds on the newer kernels.
It might not often make much sense to connect() from site-local to
global addresses, but if the user explicitly tries that then the kernel
shouldn't reject the attempt out of hand. 

So glibc was behaving optimally in this case purely be coincidence, in
the past.

The best fix for this, IMHO, is to change the default label/precedence
table in glibc's RFC3484 implementation so that it includes a separate
label for site-local addresses. That will mean that in the above
situation, glibc favours the IPv4 address by virtue of RFC3484 Rule 5
(where before it was favouring it by Rule 1).

In the meantime, it's been "fixed" in glibc simply by changing the
default precedence for ::ffff:0:0/96 to '100' -- thus favouring IPv4
over IPv6 in _all_ cases. I think it's best to avoid that situation,
because it means that IPv6 is never going to get tested in Linux on
dual-stack hosts; they'd always use IPv4 instead.

-- 
dwmw2

---

From: Perry Lorier <[email-masked]>
Date: Thu, 11 May 2006 10:21:17 +1200

> out public IPv6 addresses/prefix(es) to his/her users, possibly in 

A more probable solution is to have all the client PC's on ULA, and all
the servers have a globally routeable IPs.  clients should still be able
to reach the servers, and visa versa, they just can't reach other hosts
out on the internet.

> global (or at least has no non-ULA-nor-link-local) addresses?

The Correct Solution(tm) for this entire problem (IMHO) is for Pekka to
make sure that the gateway box for the client PC's throws an unreachable
error back to the hosts when it realises it can't forward it out to the
Internet.  The client boxes should detect the unreachable and give up
immediately and fall back to IPv4.

Also, Pekka should use /etc/gai.conf to modify glibc's preferences as to
which one it prefers.  I however can't find this documented anywhere,
however it does seem to be available in the most recent fedora packages.

---

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

El 10/05/2006, a las 18:45, Rémi Denis-Courmont escribió:

> (IPv6) address.

yes

>  In other words, that someone has introduced some kind
> of NAT or transparent proxy in the middle.

no
it assumes that the routability domain of a ULA may be defined by the 
site and extended to other sites using agreements. I mean, it is 
possible for two different sites to agree that their ULAs will be 
routable among them. As i understand it, the ULAs are not by default 
routable globally but their routability domain can be extended beyond 
the local site through agreements with other sites.

i hope it is clearer now.

> I'm not so gullible as to

agree than if you want a gloablly routable address this is the case 
indeed

> address while its sockFrom [email-masked] Thu May 11 02:34:25 2006
From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 11 May 2006 09:30:31 +0300
To: =?ISO-8859-1?Q?Rémi_Denis-Courmont?= <[email-masked]>
Cc: [email-masked]
Subject: Re: RFC3484 problem: scoping with site-locals/ULAs

El 10/05/2006, a las 18:45, Rémi Denis-Courmont escribió:

> (IPv6) address.

yes

>  In other words, that someone has introduced some kind
> of NAT or transparent proxy in the middle.

no
it assumes that the routability domain of a ULA may be defined by the 
site and extended to other sites using agreements. I mean, it is 
possible for two different sites to agree that their ULAs will be 
routable among them. As i understand it, the ULAs are not by default 
routable globally but their routability domain can be extended beyond 
the local site through agreements with other sites.

i hope it is clearer now.

> I'm not so gullible as to

agree than if you want a gloablly routable address this is the case 
indeed

> global (or at least has no non-ULA-nor-link-local) addresses?

that maybe the ULAs routability domain includes the location of the 
given destiantion address

regards, marcelo

---

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

El 11/05/2006, a las 1:21, Perry Lorier escribió:

>> access to tet is bound to an ULA or while the host has no

regards, marcelo

---

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

> immediately and fall back to IPv4.

as mentioned to Remi my understanding is that the routability of the 
ULAs can be extended beyond the local site using agreements, so 
probably this approach would not support this case (maybe it is not a 
big problem though...)

regards, marcelo

he globally routable IPv6 Internet, shouldn't (s)he hands
> immediately and fall back to IPv4.

as mentioned to Remi my understanding is that the routability of the 
ULAs can be extended beyond the local site using agreements, so 
probably this approach would not support this case (maybe it is not a 
big problem though...)

regards, marcelo

---

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

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

---

From: Perry Lorier <[email-masked]>
Date: Thu, 11 May 2006 19:59:43 +1200

> ULAs can be extended beyond the local site using agreements, so probably
> this approach would not support this case (maybe it is not a big problem
> though...)

Well, it should not allow forwarding a packet out an interface that
doesn't have a route back for that source, and should generate an
Destination Unreachable error.  I guess it's indeterminable by this host
that it's peer doesn't have a route for this packet, however a system
administrator should be able to do this on border routers where it applies.

---

From: Havard Eidnes <[email-masked]>
Date: Thu, 11 May 2006 10:17:42 +0200 (CEST)

> 	- use a DNS lookup that asks for all records (including A, MX, and  

Because you can't do this with a single DNS query.  The "ANY" query
type will return all the records/record types cached for a given name,
but there is no guarantee that the cache has been filled with all the
information available on the authoritative name servers for the given
name.  Individual RRsets (name+type) can have different TTLs, so even
if the cache was filled with all the information initially, a caching
name server can't guarantee that will always be the case at a later
time.

That's a minor detail, though -- one or two DNS queries doesn't make
much of a difference.

> 	- accept the first to successfully open and shut down all others

I think that the TCP connect operations are typically synchronous at
the user/kernel interface.  Doing several connection attempts in
parallel is therefore at best problematical.  Using pthreads could
possibly be a workaround, but mandating use of pthreads for all
applications for using the C library is, I think, not acceptable.

Regards,

- Håvard

---

From: "Stephen Sprunk" <[email-masked]>
Date: Thu, 11 May 2006 12:18:13 -0500

Thus spake "Rémi Denis-Courmont" <[email-masked]>
> This assumes that one may use an ULA (IPv6) to reach a globally
> routable (IPv6) address. In other words, that someone has introduced
> some kind of NAT or transparent proxy in the middle.

That's not the only case, and hopefully one that will never happen.

A site may number their hosts with both global addresses and ULAs.  Hosts 
intended to communicate with the internet would have both, whereas 
"internal" hosts like servers may have just ULAs.

I believe the intent when we developed ULAs was:

1. when contacting a global address, the preferred source is a global 
address
2. when contacting a ULA, the preferred source is a ULA from the same prefix

There was a bit of debate about the correct source address when contacting a 
ULA from a different prefix than the one used locally.  I don't think this 
was ever resolved.

For an explanation of this case, consider two companies that have a private 
interconnection.  If both have ULAs and globals assigned to hosts, should 
they communicate using the globals or the ULAs?  If only one has globals 
assigned, should the other site contact it using its globals or ULAs as the 
source address?

The rules on this were pretty clear for SLAs since one couldn't use them for 
inter-site communication even if one wanted to; however, ULAs can be used in 
this role similarly to globals depending on how routing and ACLs are set up. 
In some cases, they may even have greater reachability than globals...

S

Stephen Sprunk        "Stupid people surround themselves with smart
CCIE #3723           people.  Smart people surround themselves with
K5SSS         smart people who disagree with them."  --Aaron Sorkin

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 12 May 2006 13:50:50 -0700

Juergen Schoenwaelder wrote:

> So my preference would be to deprecate them since what we really would
> need is a n:m mapping table between process ids and transport endpoints.

Any other comments?

If not, how do we go about deprecating them?

    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 12 May 2006 13:50:50 -0700

Fred Baker wrote:
> 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.
> 

In the big picture, I think that's the direction we need to move.
But I don't think we want to have every application have that logic, 
since the logic might need to evolve over time (and needs to take into 
account Alain's example of umpteen different IP addresses - might want 
to stagger the attempts when there are lots of IP addresses to try.)

So instead I think we want to raise the abstraction layer for the 
applications by introducing a connect-by-name socket API so that the 
application just hands in the FQDN and the port number to which it wants 
to connect.

It isn't hard to come up with an initial cut of a connect-by-name 
implementation entirely as a library routine (using non-blocking sockets 
for the connect() system calls so that multiple can be outstanding and 
the same time.)

    Erik

 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Cc: [email-masked], [email-masked], David Woodhouse <[email-masked]>,
	Pekka Savola <[email-masked]>
Subject: Re: RFC3484 problem: scoping with site-locals/ULAs
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:[email-masked]?subject=unsubscribe>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:[email-masked]?subject=subscribe>
Errors-To: [email-masked]

Fred Baker wrote:
> 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.
> 

In the big picture, I think that's the direction we need to move.
But I don't think we want to have every application have that logic, 
since the logic might need to evolve over time (and needs to take into 
account Alain's example of umpteen different IP addresses - might want 
to stagger the attempts when there are lots of IP addresses to try.)

So instead I think we want to raise the abstraction layer for the 
applications by introducing a connect-by-name socket API so that the 
application just hands in the FQDN and the port number to which it wants 
to connect.

It isn't hard to come up with an initial cut of a connect-by-name 
implementation entirely as a library routine (using non-blocking sockets 
for the connect() system calls so that multiple can be outstanding and 
the same time.)

    Erik

---

From: Perry Lorier <[email-masked]>
Date: Sat, 13 May 2006 11:49:39 +1200

> for the connect() system calls so that multiple can be outstanding and

How would this work as a nonblocking connect?  A lot of network services
can't afford to block, they have other sockets to service.  Would it
return an fd_set? maybe a poll array?  Maybe it would integrate with
linux's epoll(), or freebsd's kqueue()?

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Sat, 13 May 2006 11:54:08 +0300

Le Jeudi 11 Mai 2006 09:30, vous avez écrit :
> > routable (IPv6) address.

> site and extended to other sites using agreements.
(...)
> i hope it is clearer now.

Well, it is now, thanks.

But I'm still very wary as to whether doing that (using ULAs to reach 
globally routable addresses) should be supported/allowed at all.

If there is one lesson that should be learned from the IPv4 and NATs 
mess, it would probably be: breaking the equivalence property of host 
reachability is VERY BAD. This includes the reflexive property (if A 
can reach B, B can reach A), which is not an issue. And it also 
includes the transitive property of reachability (if A can reach B and 
B can reach C, A can reach C).

There are so many IETF, not-IETF and proprietary protocols out there 
that are more elaborate than HTTP with regards to how they use the 
network. There's one thing I've learned one thing after porting quite a 
bunch of applications to dual-stack; getaddrinfo() is not the universal 
solution to all IPv6/IPv4 transition considerations within 
applications.

Lets say your company has desktop on ULAs space only, and globally 
routable addresses for servers. Some user wants to set up a media 
session with an external host (be it with SIP, RTSP, whatever). He'll 
happily connect to his whatever-proxy which is in public IPv6 address 
space. Then the proxy will connect with the remote peer and forward the 
setup infos, including the client ULA address as a return destination 
for media.

Conclusion: You need not setup actual NATs to be faced with the NAT-type 
issues.

Corollary: IMHO, ULAs should only be allowed to reach ULAs. In practice, 
one could use DNS views to advertise ULAs in one's internal DNS 
service, and advertise globally routable addresses to the outside to 
the host that are allowed to be contacted from the outside.

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Sat, 13 May 2006 12:14:41 +0300

Le Samedi 13 Mai 2006 02:49, Perry Lorier a écrit :
> How would this work as a nonblocking connect?  A lot of network
> services can't afford to block, they have other sockets to service. 
> Would it return an fd_set? maybe a poll array?  Maybe it would
> integrate with linux's epoll(), or freebsd's kqueue()?

Using three functions calls (non-blocking initiation, non-blocking 
status check and memory resource free) could easily allow for such a 
scheme to integrate within a (p)select(), epoll() or kqueue() loop.

Integrating with (p)poll() is more complicated because you have to know 
the exact number of entries in advance, but could probably be done as 
well.

There are possibly more troublesome issues:
1/ how to handle UDP, which is also supported by getaddrinfo(), and has 
more varied usages (not just socket() then connect())?

2/ how do you account for socket options, some of which MUST be defined 
before connect()/bind(), but obviously after socket()? it is my 
understanding that a wrapper as the one hereby suggested would hide 
socket() AND connect() within a single API call.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 14 May 2006 17:44:16 +0300

Hi Rémi,

> more varied usages (not just socket() then connect())?

but this seems to be the natural behaviour...

i mean TCP is a connection oriented service, so it is possible for TCP 
to determine if the connection is actually established and it is then 
possible for TCP to determine if the selected address pair is working 
and if not try with an alternative one.

In the case of UDP, it is a non connection oriented service, so it is 
not possible for UDP to determine if the address pair is working, hence 
it is up to the application that has selected the usage of UDP to 
handel failures by themselves, i.e. to determine if the current address 
pair is working and if not it is up to the app to try alternative ones.

so, as i see it, this result is completelly coherent with the type of 
service provided by each of the transport layers...

regards, marcelo

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 15 May 2006 17:54:55 +0300

Le Dimanche 14 Mai 2006 17:44, vous avez écrit :
> > 1/ how to handle UDP, which is also supported by getaddrinfo(), and
> > has more varied usages (not just socket() then connect())?

> not possible for UDP to determine if the address pair is working,
> hence it is up to the application that has selected the usage of UDP
> to handel failures by themselves, i.e. to determine if the current
> address pair is working and if not it is up to the app to try
> alternative ones.

That's true on the paper. But in practice, it is completely unmanageable 
for many UDP applications to keep a list of candidates (protocol 
family, destinations), and to handle failures asynchronously, 
particularly if there are several peers. ntpdate is a good example. You 
really don't want to pass several sockets, a whole addrinfo 
chained-list, and keep track of who's next in the list in case of ICMP 
failure.

Actually, this would not only be way too complex, this would be worst 
because they would be so many ways it could be coded wrong.

Dual-stack UDP applications do need to know immediatly via which 
protocol version any peer should be reached. That's as simple as that.

And flooding all alternatives destination addresses sounds highly 
suboptimal, as contrary to TCP, each of these packets will actually 
contain a payload, and likely be processed by the destination.

> service provided by each of the transport layers...

I'm not saying UDP should be considered reliable. I'm saying some 
applications should have a non-blocking way to know which destination 
(and source) address to use to try to reach a single peer via UDP. That 
doesn't mean failure should not be handled.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 16 May 2006 11:03:32 +0300

> because they would be so many ways it could be coded wrong.

i agree with your points there, but first of all, it should be noted 
that currently, as per RFC3484 application are the one responsible for 
retrying when there are multiple destiantion addresses available

However, there may be some strategies that would allow to the IP layer 
to keep track of the address that has been tried, (especially source 
address for a given destiantion address) and the app only needs to ask 
for a retrial

I mean, the problem with UDP is that only the app knows if the packet 
was succesfully transitted so only the app knows when there is the need 
for a retrial

so it may possible to think some approaches where the app only signals 
that the packet that it sent need to be retired and the lower layer 
take care of manaiging which addresses to use. For instance, there 
could be a cache about what addresses have been tried lately and for 
which ones the app have send a signal requiring a retrial (which is a 
strong indication that the last address pair tried is not working)

so perhpas it would be interesting to explore this type of hybrid 
alternatives, where the app detects non working address pairs (since it 
is the only one able to do that in the case of UDP) but the lower 
layers are the ones managing the address pairs and caching the 
knowledge about which address pairs are working and which ones are not

> contain a payload, and likely be processed by the destination.

yes, flooding is not nice, i would try other alternatives first indeed

regards, marcelo