> Date: Mon, 24 Sep 2007 17:48:06 +0200 > From: Juliusz Chroboczek <[EMAIL PROTECTED]> > To: Steve Langasek <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED], Clint Adams <[EMAIL PROTECTED]> > 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
