Re: [Juliusz.Chroboczek@pps.jussieu.fr: Re: A comment about RFC 3484 address selection]
> Date: Mon, 24 Sep 2007 17:48:06 +0200
> From: Juliusz Chroboczek <Juliusz.Chroboczek@pps.jussieu.fr>
> To: Steve Langasek <vorlon@debian.org>
> Cc: 438179@bugs.debian.org, Clint Adams <schizo@debian.org>
> Subject: Re: A comment about RFC 3484 address selection
>
> > FWIW, I believe non-subscriber posts are accepted to the list if they're
> > sent by way of the BTS.
As far as I know, if you're not subscribed you should sign your message.
> Let's see how it goes.
>
> >> > RFC 3484 clarifies that the list of addresses returned by getaddrinfo
> >> > is in an order that takes into account both the server's and local
> >> > preferences.
>
> > no, the software authors cannot expect to rely on addresses to be
> > sorted in any particular order;
>
> Software authors can expect that the list is in an arbitrary order
> that reflects the local address selection policies.
There are 2 ways to look at this. One is from the point of people
writing an application that connects to some server. The other is from
people running the servers.
There are dns server implementations that rotates the list of A-records,
so that the load gets distributed over the servers. People setting up
that software know that, and rely on the behaviour. They expect
the client software to select a semi random IP address.
What client software might want to do is connect to the one that is
network-wise the closest. The RFC defines a few rules for that and basicly
suggest an order in which you should prefer one over the other. You
should be able to change the order of those rules based on local
policies.
And then says that if all those rules are applied, you shouldn't change
the order anymore. The reason it says it shouldn't sort anymore is
probably because of the behaviour of the rotating dns server. If you
don't know which to prefer, a semi random one is better then
everyone connecting to the same.
What rule 9 does is try to "guess" which of the destination addresses
might be closer network wise. And it's doing a very poor job in alot of
cases. What it does seem to be good at however is breaking the
expectations of the dns server administrators.
When implemented, the dns servers can even give a much better guess
on what might be network-wise closer based on the IP address of the
client sending the query.
> But that is not my point. If, like many people, you believe that
> another semantics is useful, please do not pull an OpenBSD. Stick to
> the standard semantics for the standard interface, and define a new
> interface for the semantics you find useful.
Someone still needs to explain me why rule 9 _might_ be useful in the
real world (for IPv4). The only argument I'm seeing is "that's what
the standard says". I don't find that a very good argument, specially
if that standard says that if you know better, you shouldn't implement
it.
What I really want to know is what do we break by not following it. Is
there any application that depends on this behaviour? Like you say
yourself, the order might be based on the local policies, so I think
anything that relies on this behaviour is broken.
> > RFC 3484 is not a standard.
>
> I'm not sure you are familiar with IETF terminology. 3484 is
> a Proposed Standard. So is 2464 (IPv6 over Ethernet).
Even if rfc 2464 isn't a standard yet, you can already consider it
a de facto standard, which you can't say about rfc 3484.
Kurt
Reply to: