El 15/05/2006, a las 17:54, Rémi Denis-Courmont escribió:
Le Dimanche 14 Mai 2006 17:44, vous avez écrit :
El 13/05/2006, a las 12:14, Rémi Denis-Courmont escribió:
There are possibly more troublesome issues:
1/ how to handle UDP, which is also supported by getaddrinfo(), and
has more varied
Le Dimanche 14 Mai 2006 17:44, vous avez écrit :
El 13/05/2006, a las 12:14, Rémi Denis-Courmont escribió:
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())?
but this
Le Jeudi 11 Mai 2006 09:30, vous avez écrit :
This assumes that one may use an ULA (IPv6) to reach a globally
routable (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
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
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
El 10/05/2006, a las 18:45, Rémi Denis-Courmont escribió:
Le Mercredi 10 Mai 2006 10:35, marcelo bagnulo braun a écrit :
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
El 11/05/2006, a las 1:21, Perry Lorier escribió:
Rémi Denis-Courmont wrote:
Le Mercredi 10 Mai 2006 10:35, marcelo bagnulo braun a écrit :
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
[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
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
So I have a dumb question.
Why not:
- 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
El 11/05/2006, a las 12:10, David Woodhouse escribió:
On Thu, 2006-05-11 at 09:53 +0300, marcelo bagnulo braun wrote:
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
On Thu, 2006-05-11 at 09:53 +0300, marcelo bagnulo braun wrote:
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.
RFC3484 is a defined set of heuristics
Thus spake Rémi Denis-Courmont [EMAIL PROTECTED]
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
El 09/05/2006, a las 17:27, Pekka Savola escribió:
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
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 record associated with it then it is reachable on that
address. And yet DNS has no real understanding of reachability
So I have a dumb question.
Why not:
- use a DNS lookup that asks for all records (including A, MX, and
)
- 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
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
Le Mercredi 10 Mai 2006 10:35, marcelo bagnulo braun a écrit :
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...
This assumes that one may use an ULA (IPv6) to
On Wed, 2006-05-10 at 09:03 -0700, Fred Baker wrote:
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
On Wed, 2006-05-10 at 13:52 +0200, Eliot Lear wrote:
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 record associated with it then it is reachable on that
address.
Er, no. Unless I
Rémi Denis-Courmont wrote:
Le Mercredi 10 Mai 2006 10:35, marcelo bagnulo braun a écrit :
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...
This assumes that
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
Le Mardi 9 Mai 2006 17:27, Pekka Savola a écrit :
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).
A site has deployed IPv6 site-local addresses (alongside with
On Tue, 2006-05-09 at 17:27 +0300, Pekka Savola wrote:
Likewise, requiring that routers will always send back an ICMP error
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
On Tue, 2006-05-09 at 17:49 +0200, Eliot Lear wrote:
Where is DNS in this picture? How did you get the v6 address that
didn't work?
Public DNS for hosts which have both and A records. www.kame.net,
for example.
From an internal network as described (RFC1918 IPv4 addresses with
global
Eliot makes a good point about DNS. This sounds like a perfect case for
split DNS, to maintain isolation of both the (private) inside of the NAT
point and the site local addresses from the public Internet. What
people see on DNS inside should be reachable from the inside, but what
they see on
On Tue, 9 May 2006, Walt Lazear wrote:
It sounds like the site in question has a single DNS and it's
telling outsiders about private stuff that should not be allowed to
escape.
Exactly the opposite. To solve this problem using split DNS, the DNS
resolvers at the site would need to BLOCK any
27 matches
Mail list logo
