Re: getaddrinfo() behaviour
Anthony Towns writes ("Re: getaddrinfo() behaviour"):
> The only reason suitability for release is relevant is in overriding the
> directive that we'll "not make a technical decision until efforts to
> resolve it via consensus have been tried and failed". We haven't made
> efforts to get a consensus with the IETF working group and change the
> standard that all this stems from, so making a decision before that's
> happened requires further justification in my view.
That refers to efforts within Debian, not to efforts in standards
bodies.
Standards bodies generally make and implement decisions on a timescale
that makes Technical Committee decisions look frenetic and rushed.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: getaddrinfo() behaviour
On Tue, Oct 02, 2007 at 10:37:42AM +0200, Florian Weimer wrote: > * Anthony Towns: > > Updating the proposed standard has not been tried. > Just to give you an idea of the time scale involved: moving RFC 3484 > to HISTORIC (which is the most likely result, at least for the Rule 9 > part) will take at least a year. Likewise, updating stable for a non-RC issue takes a similar amount of time... Cheers, aj signature.asc Description: Digital signature
Re: getaddrinfo() behaviour
On Tue, Oct 02, 2007 at 08:37:42AM +, Florian Weimer wrote: > * Anthony Towns: > > > Updating the proposed standard has not been tried. > > Just to give you an idea of the time scale involved: moving RFC 3484 > to HISTORIC (which is the most likely result, at least for the Rule 9 > part) will take at least a year. So let's try early ? -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpbPzq87cLLL.pgp Description: PGP signature
Re: getaddrinfo() behaviour
* Anthony Towns: > Updating the proposed standard has not been tried. Just to give you an idea of the time scale involved: moving RFC 3484 to HISTORIC (which is the most likely result, at least for the Rule 9 part) will take at least a year. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: getaddrinfo() behaviour
Anthony Towns wrote:
On Mon, Oct 01, 2007 at 04:30:17PM +0100, Ian Jackson wrote:
Ian Jackson writes ("Re: getaddrinfo() behaviour"):
Limiting the TC's power to overrule a technical decision to only cases
where the TC believes that the wrong behaviour makes the package
unsuitable for release would eviscerate the only mechanism we have for
dealing with errors by maintainers.
I should have said, for dealing with errors by maintainers which
persist after persuasion has been tried.
Updating the proposed standard has not been tried. If it had, and failed,
and did so without addressing the concerns we've had with the current rfc,
it'd be appropriate for the tech ctte to rule -- we would have exhausted
all other means of obtaining a consensus, and it would be the last resort.
No! There is one or two updates for the proposed standard.
IIRC one is in the last phase, before to be published.
[But anyway they are about IPv6, and not rules 9]
To check: http://www.ietf.org/ put in the search 3484 and you see
a lot of discussions about updates
So it seems (IMHO) that RFC3484 is not mature to be (and become) a
Internet standard.
ciao
cate
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: getaddrinfo() behaviour
On Mon, Oct 01, 2007 at 04:30:17PM +0100, Ian Jackson wrote:
> Ian Jackson writes ("Re: getaddrinfo() behaviour"):
> > Limiting the TC's power to overrule a technical decision to only cases
> > where the TC believes that the wrong behaviour makes the package
> > unsuitable for release would eviscerate the only mechanism we have for
> > dealing with errors by maintainers.
> I should have said, for dealing with errors by maintainers which
> persist after persuasion has been tried.
Updating the proposed standard has not been tried. If it had, and failed,
and did so without addressing the concerns we've had with the current rfc,
it'd be appropriate for the tech ctte to rule -- we would have exhausted
all other means of obtaining a consensus, and it would be the last resort.
If there hadn't been a proposed standard in the first place documenting
the existing behaviour, I doubt we'd have a problem in the first place,
and there certainly wouldn't be an issue with us overruling the maintainer
if there somehow was.
The only reason suitability for release is relevant is in overriding the
directive that we'll "not make a technical decision until efforts to
resolve it via consensus have been tried and failed". We haven't made
efforts to get a consensus with the IETF working group and change the
standard that all this stems from, so making a decision before that's
happened requires further justification in my view.
I can't say I'd noticed much effort from the ctte to persuade the glibc
maintainers of anything, to be honest.
Cheers,
aj
signature.asc
Description: Digital signature
Re: getaddrinfo() behaviour
Ian Jackson writes ("Re: getaddrinfo() behaviour"):
> Limiting the TC's power to overrule a technical decision to only cases
> where the TC believes that the wrong behaviour makes the package
> unsuitable for release would eviscerate the only mechanism we have for
> dealing with errors by maintainers.
I should have said, for dealing with errors by maintainers which
persist after persuasion has been tried.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: getaddrinfo() behaviour
Anthony Towns writes ("Re: getaddrinfo() behaviour"):
> In my opinion, if this isn't an RC issue, there's no urgency to having
> glibc changed prior to the standards changing, and as such, this isn't
> the "last resort" so the tech ctte shouldn't be deciding the issue, let
> alone overruling the maintainer.
You are assuming that the documented standard[1] will change, and that
it will change in a timely manner. As I have said before, it is not
the job of the TC (or of Debian!) to slavishly follow standards.
[1] I'll go along for the sake of argument with the proposition that
the documented standard is rule 9 for IPv4, even though that
propositionis actually false.
Standards like those in the IETF and elsewhere often allege that they
document existing practice, and when we follow some incorrect
documentation we are in fact undermining the quality of the
standards-setting process.
It is wrong of Debian to follow incorrect standards. We should fix
brokenness straight away, not wait for a glacial standards body to
react.
Also, you suggest that it would be wrong of the TC to overrule a
maintainer for a non-RC reason. I think that is absurd. The TC
should overrule a maintainer whenever it is sufficiently clear that
the maintainer is wrong, and the supermajority requirement
specifically serves to ensure that the TC will only overrule in that
case.
Limiting the TC's power to overrule a technical decision to only cases
where the TC believes that the wrong behaviour makes the package
unsuitable for release would eviscerate the only mechanism we have for
dealing with errors by maintainers.
Ian.
(Added CC to glibc)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: getaddrinfo() behaviour
Anthony Towns wrote: On Mon, Oct 01, 2007 at 10:44:48AM +0200, Andreas Barth wrote: * Anthony Towns ([EMAIL PROTECTED]) [071001 03:46]: One of the rules for RCness is "in the package maintainer's opinion, makes the package unsuitable for release". Not quite the same, but not very different is "in the technical committee's opinion, makes the package unsuitable for release" -- is that what we think of this issue? I don't see which advantage we will get from introducing the concept "RC ness" into this decision. AFAICS, we can perfectly well make a decision only about the topic in question. In my opinion, if this isn't an RC issue, there's no urgency to having glibc changed prior to the standards changing, and as such, this isn't the "last resort" so the tech ctte shouldn't be deciding the issue, let alone overruling the maintainer. In my opinion, if this issue isn't severe enough to warrant a change to stable, it's also not severe enough to warrant overruling the maintainer wrt unstable -- if we're trying to stop Debian machines behaving badly on the Internet, that applies to stable at least as much as unstable. I don't see why stable would be changed for a non-RC issue in this case, nor why this being RC wouldn't warrant stable being changed, so I consider those to be equivalent. OTOH, if we're not that worried about Debian machines behaving badly, but we're trying to influence the future of the Internet, changing the RFC is the way to go, and there's no need to overrule our glibc maintainers or keep more patches from glibc until our concerns have been passed on to the IETF. If the decision is right, why should we wait for a new document? Because the maintainers, upstream and IETF all currently agree that the other way of approaching things is right. Especially as the current document isn't a standard either, but the old behaviour is. I don't believe "the old behaviour" has even reached the level of "proposed standard" in the IETF nomenclature -- certainly I haven't seen any evidence of it up 'til now. If you're claiming it's a de facto standard, well, this is how de facto standards change -- with upstream implemented preferred behaviours, and us releasing them as part of stable. And I realise dismissing RFC3484 as "not a standard" is all the rage, but personally I still give quite a bit of weight to IETF proposed standards. The "Default Address Selection for Internet Protocol version 6 (IPv6)", aka as RFC3484 is a paper for IPv6, not a proposed standard for IPv4 : All IPv6 nodes, including both hosts and routers, must implement : default address selection as defined in this specification. IPv4 can be implemented in the same way, but it is not a MUST and AFAIK also not a SHOULD. ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: getaddrinfo() behaviour
On Mon, Oct 01, 2007 at 10:44:48AM +0200, Andreas Barth wrote: > * Anthony Towns ([EMAIL PROTECTED]) [071001 03:46]: > > One of the rules for RCness is "in the package maintainer's opinion, > > makes the package unsuitable for release". Not quite the same, but > > not very different is "in the technical committee's opinion, makes the > > package unsuitable for release" -- is that what we think of this issue? > I don't see which advantage we will get from introducing the concept "RC > ness" into this decision. AFAICS, we can perfectly well make a decision > only about the topic in question. In my opinion, if this isn't an RC issue, there's no urgency to having glibc changed prior to the standards changing, and as such, this isn't the "last resort" so the tech ctte shouldn't be deciding the issue, let alone overruling the maintainer. In my opinion, if this issue isn't severe enough to warrant a change to stable, it's also not severe enough to warrant overruling the maintainer wrt unstable -- if we're trying to stop Debian machines behaving badly on the Internet, that applies to stable at least as much as unstable. I don't see why stable would be changed for a non-RC issue in this case, nor why this being RC wouldn't warrant stable being changed, so I consider those to be equivalent. OTOH, if we're not that worried about Debian machines behaving badly, but we're trying to influence the future of the Internet, changing the RFC is the way to go, and there's no need to overrule our glibc maintainers or keep more patches from glibc until our concerns have been passed on to the IETF. > If the decision is right, why should we wait for a new document? Because the maintainers, upstream and IETF all currently agree that the other way of approaching things is right. > Especially as the current document isn't a standard either, but the old > behaviour is. I don't believe "the old behaviour" has even reached the level of "proposed standard" in the IETF nomenclature -- certainly I haven't seen any evidence of it up 'til now. If you're claiming it's a de facto standard, well, this is how de facto standards change -- with upstream implemented preferred behaviours, and us releasing them as part of stable. And I realise dismissing RFC3484 as "not a standard" is all the rage, but personally I still give quite a bit of weight to IETF proposed standards. It's possible we've reached the end of the discussion; if other members of the TC don't consider this severe enough to make glibc unsuitable for release and all that entails, then I don't see any way to support overruling the maintainers on the issue -- but that doesn't mean we can't decide to overrule the maintainers anyway: it just means three people need to vote for it, and no one else can vote against it. I have absolutely no qualms putting my name to something saying "RFC3484 is lame", just the bit that says "and it doesn't matter what the glibc maintainers think, this is the way it should be done in Debian". Cheers, aj signature.asc Description: Digital signature
Re: getaddrinfo() behaviour
* Anthony Towns ([EMAIL PROTECTED]) [071001 03:46]: > One of the rules for RCness is "in the package maintainer's opinion, > makes the package unsuitable for release". Not quite the same, but > not very different is "in the technical committee's opinion, makes the > package unsuitable for release" -- is that what we think of this issue? I don't see which advantage we will get from introducing the concept "RC ness" into this decision. AFAICS, we can perfectly well make a decision only about the topic in question. > If it isn't, I'm not seeing why we need to overrule the maintainer instead > of waiting for an updated RFC to be issued with better guidelines that can > be adopted by upstream, and implemented in Debian with the maintainers' > consent. If we don't want to wait so long, afaics we should help get an > updated RFC out. If the decision is right, why should we wait for a new document? Especially as the current document isn't a standard either, but the old behaviour is. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: getaddrinfo() behaviour
On Fri, Sep 28, 2007 at 08:10:33PM +0200, Andreas Barth wrote:
> * Ian Jackson ([EMAIL PROTECTED]) [070928 17:48]:
> > Anthony Towns writes ("getaddrinfo() behaviour"):
> > > I'd be interested to see explanations of why this should be
> > > considered RC.
> > I think that it should be changed in etch.
> Frankly speaking, I don't think we should already jugde about that.
> > > (c) Using prefix matching to select IPv4 addresses is harmful
> > > enough to be an RC issue for Debian
> > I don't see why RCness is relevant for updating sid.
> I don't see how RCness is related to the question.
One of the rules for RCness is "in the package maintainer's opinion,
makes the package unsuitable for release". Not quite the same, but
not very different is "in the technical committee's opinion, makes the
package unsuitable for release" -- is that what we think of this issue?
If it is, then I think that means a fix is needed for etch, lenny and
sid fairly quickly, the same as for any other RC bug affecting stable.
If it isn't, I'm not seeing why we need to overrule the maintainer instead
of waiting for an updated RFC to be issued with better guidelines that can
be adopted by upstream, and implemented in Debian with the maintainers'
consent. If we don't want to wait so long, afaics we should help get an
updated RFC out.
Cheers,
aj
signature.asc
Description: Digital signature
Re: getaddrinfo() behaviour
On Fri, Sep 28, 2007 at 04:47:34PM +0100, Ian Jackson wrote: > Since I did the backport for Ubuntu I'm probably the right person to > prepare the update for etch (not that it's very hard). For concreteness, thanks to Aurelien's original addition to gai.conf before this was brought to the ctte, the patch is as simple as: diff -urb glibc-2.6.1-5/debian/patches/any/submitted-rfc3484-sortv4.diff glibc-2.6.1/debian/patches/any/submitted-rfc3484-sortv4.diff --- glibc-2.6.1-5/debian/patches/any/submitted-rfc3484-sortv4.diff 2007-09-29 12:36:14.0 +1000 +++ glibc-2.6.1/debian/patches/any/submitted-rfc3484-sortv4.diff 2007-09-29 12:38:50.0 +1000 @@ -18,9 +18,9 @@ #used. There are possible runtime problems. The default is no. # +# sortv4 -+#If set to no, getaddrinfo(3) will ignore IPv4 adresses in rule 9. See -+#section 6 in RFC 3484. The default is yes. Setting this option to -+#no breaks conformance to RFC 3484. ++#If set to yes, getaddrinfo(3) will sort IPv4 adresses in rule 9. See ++#section 6 in RFC 3484. The default is no. Setting this option to ++#yes enables stricter conformance to RFC 3484. +# # label #Add another rule to the RFC 3484 label table. See section 2.1 in @@ -36,7 +36,7 @@ +static int gaiconf_reload_flag; + +/* Zero if we are supposed to ignore rule 9 for IPv4 addresses */ -+static int gaiconf_sortv4_flag = 1; ++static int gaiconf_sortv4_flag = 0; + +/* Last modification time. */ +static struct timespec gaiconf_mtime; @@ -73,7 +73,7 @@ if (strcmp (cmd, "reload") == 0) gaiconf_reload_flag = strcmp (val1, "yes") == 0; +else if (strcmp (cmd, "sortv4") == 0) -+ gaiconf_sortv4_flag = strcmp (val1, "no") != 0; ++ gaiconf_sortv4_flag = strcmp (val1, "yes") == 0; break; case 10: I still can't see any reason why "the right person" to apply the patch is anyone other than the maintainer. > > If so, conclusions that could potentially be drawn: > > (a) Using prefix matching to select IPv4 addresses isn't useful > > (b) Using prefix matching to select IPv4 addresses is harmful > > (c) Using prefix matching to select IPv4 addresses is harmful enough to > > be an RC issue for Debian > > If so, declaring this to be an RC issue justifies both an update to > > etch and (if necessary, which I don't expect) an NMU for sid/lenny, > > which seems all that's needed. > I don't see why RCness is relevant for updating sid. > Surely the TC should ensure that its decisions are implemented even if > we consider the issue non-RC ? If it's not an RC issue -- thus qualifying for a stable update as well -- I don't see why it's important enough to overrule the maintainer for sid, rather than simply leaving it as is while we provide the IETF with comments on why the RFC's recommendations need changing. The TC should only make decisions as a last resort; if this isn't an RC issue, I just don't think we're at that point: we haven't contacted either upstream or the IETF for example, and living with non-RC bugs, including this one, isn't difficult. > > I'm not sure if any or all of (d)-(f) would be sufficient recommendations > > to close the issue for IPv6 as well, or if there's something else that > > would make sense. > I think we should avoid getting too bogged down with IPv6. We can > safely leave that to the IETF to reconsider since we're evidently not > going to overrule the libc maintainer on that point. If, as an implementor, the Debian technical committee has a problem with the IETF's proposed standard, it's our job to fully explain what the problem is and suggest ways of avoiding the problem. If we're going to shirk that task, I don't believe we should be overruling the maintainer or upstream on the issue of complying with the proposed standard. Cheers, aj signature.asc Description: Digital signature
Re: getaddrinfo() behaviour
* Ian Jackson ([EMAIL PROTECTED]) [070928 17:48]:
> Anthony Towns writes ("getaddrinfo() behaviour"):
> > Conversely, if we don't consider this an RC issue, changing it for etch
> > doesn't seem appropriate, and at that point I don't see why we'd change
> > it for sid either (at least absent an update via the IETF standards track
> > process). I'd be interested to see explanations of why this should be
> > considered RC.
>
> I think that it should be changed in etch. If we change it in etch it
> will make our ftp admins' lives a lot easier, if nothing else, because
> they'll go back to being able to publish DNS round robin.
Frankly speaking, I don't think we should already jugde about that.
IMHO, the tech ctte should make minimal decisions (as appropriate of
course). The large decision at our hands is "how should the long-term
strategy look like" - after that decision is done, I think we (as tech
ctte) could let take the maintainers plus stable release managers
decide how to continue for etch (and if someone is unhappy enough to
call the tech ctte again, we could decide on that).
> Since I did the backport for Ubuntu I'm probably the right person to
> prepare the update for etch (not that it's very hard).
That's something I didn't like to have as part of the decisions as well,
but I didn't mind enough - we should first say "yes, *that* is the right
decision". I always consider the usual rules for RC bug fixes apply as
well to "implement decisions of the tech ctte", but I don't think we
should especially assign someone to the solution.
(Of course, in case the implementation goes wrong, we might decide "oh,
that is exactly the patch we would like to see implemented", but I don't
see a reasons for that in this case.)
> > If so, conclusions that could potentially be drawn:
> >
> > (a) Using prefix matching to select IPv4 addresses isn't useful
> > (b) Using prefix matching to select IPv4 addresses is harmful
> > (c) Using prefix matching to select IPv4 addresses is harmful enough to
> > be an RC issue for Debian
> ...
>
> > If so, declaring this to be an RC issue justifies both an update to
> > etch and (if necessary, which I don't expect) an NMU for sid/lenny,
> > which seems all that's needed.
>
> I don't see why RCness is relevant for updating sid.
I don't see how RCness is related to the question.
The maintainers did a certain decision. Now somebody didn't like it and
asked the tech ctte to overrule the maintainers. Now the tech ctte could
(a) decide to back up the maintainers, (b) decide to not like the
decision, but don't overrule the maintainers, (c) overrule the
maintainers.
I didn't read yet that the release managers made a decision that this
issue is RC or not, and I also cannot remember that someone asked the
tech ctte to overrule the release managers. So RCness is a question not
even asked here.
> Surely the TC should ensure that its decisions are implemented even if
> we consider the issue non-RC ?
Sure
> I think we should avoid getting too bogged down with IPv6. We can
> safely leave that to the IETF to reconsider since we're evidently not
> going to overrule the libc maintainer on that point. Hence my wording
> that we think rule 6 shouldn't apply to IPv6 and we recommend the IETF
> "probably" abolish it. Ie, they should think about it with the more
> information and expertise available to them.
Agreed. I think we should try to get a decision on what affects us and
where at least anyone inside the tech ctte is willing to override, i.e.
how to continue with IPv4. We seem to agree we don't overrule on ipv6,
and we also seem to agree in case we overrule on ipv4 that reconsidering
ipv6 is sound - so we shouldn't split hairs on the best wording there,
but try to get this issue off.
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: getaddrinfo() behaviour
Anthony Towns writes ("getaddrinfo() behaviour"):
> So here's my understanding of where we're at.
Thanks.
> First, fact finding. Everything here should be able to be agreed by
> everyone.
I'm afraid I don't agree with all of the things you claim as facts,
and I don't agree with the analytical approach you're using anyway.
But we've been over and over this and me repeating myself isn't going
to help.
So I'll skip straight to the meat. One thing you have pointed out is
that we hadn't finished discussing whether or not etch should be
fixed.
> Conversely, if we don't consider this an RC issue, changing it for etch
> doesn't seem appropriate, and at that point I don't see why we'd change
> it for sid either (at least absent an update via the IETF standards track
> process). I'd be interested to see explanations of why this should be
> considered RC.
I think that it should be changed in etch. If we change it in etch it
will make our ftp admins' lives a lot easier, if nothing else, because
they'll go back to being able to publish DNS round robin.
There are no anticipated downsides to changing it in etch except of
course the usual risk of a libc update. Ubuntu have backported the
gai.conf configuration option to their libc without difficulty,
although not in an update to an already released distribution.
I can see that the stable release managers might have another view.
We haven't really heard from them properly. My current feeling
therefore is that we should overrule the libc maintainer to
essentially propose this ourselves as an update for stable, which we
would recommend but not insist that the stable RM should accept.
Since I did the backport for Ubuntu I'm probably the right person to
prepare the update for etch (not that it's very hard).
> If so, conclusions that could potentially be drawn:
>
> (a) Using prefix matching to select IPv4 addresses isn't useful
> (b) Using prefix matching to select IPv4 addresses is harmful
> (c) Using prefix matching to select IPv4 addresses is harmful enough to
> be an RC issue for Debian
...
> If so, declaring this to be an RC issue justifies both an update to
> etch and (if necessary, which I don't expect) an NMU for sid/lenny,
> which seems all that's needed.
I don't see why RCness is relevant for updating sid.
Surely the TC should ensure that its decisions are implemented even if
we consider the issue non-RC ?
> I'm not sure if any or all of (d)-(f) would be sufficient recommendations
> to close the issue for IPv6 as well, or if there's something else that
> would make sense.
I think we should avoid getting too bogged down with IPv6. We can
safely leave that to the IETF to reconsider since we're evidently not
going to overrule the libc maintainer on that point. Hence my wording
that we think rule 6 shouldn't apply to IPv6 and we recommend the IETF
"probably" abolish it. Ie, they should think about it with the more
information and expertise available to them.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
getaddrinfo() behaviour
So here's my understanding of where we're at.
First, fact finding. Everything here should be able to be agreed by
everyone.
getaddrinfo() is a new interface that replaces gethostbyname(). It
hasn't different semantics that are intended to make it superior
to gethostbyname() and other functions, both in supporting IPv6 and
potentially other ways (such as resolving "foo.bar.com:http" differently
to "foo.bar.com:https").
The most authoritative document for how getaddrinfo() will order
its results is RFC3484, which is a Proposed Standard on the Internet
Standards Track and seems to be being implemented by the major vendors
including glibc and Windows.
The sorting behaviour of getaddrinfo() cannot be relied on in today's
Internet, and it behaves differently in different implementations --
particularly due to RFC3484 having been proposed only after getaddrinfo()
had already been in wide use. Further, RFC3484 specifically indicates
that the sorting behaviour may be overridden if a better order can be
determined locally (see the last paragraph of section 6). Beyond that,
determining optimal address selection appears to be an open area of
research, and modifications to RFC3484 are still being discussed and
proposed both within and outside of the RFC context [0].
Note that RFC4294 ("IPv6 Node Requirements") indicates RFC3484 "MUST be
implemented", at least in the context of dealing with multiple addresses.
The sorting behaviour specified in RFC3484 has not been in common
use within the IPv4-based Internet. Instead, by far the most common
behaviour has been to use the ordering presented by the DNS, usually
simply selecting the first returned result. This behaviour has allowed
client address selection to be influenced by the DNS system and thus the
provider of the service being addressed, as described in RFC 1794. This
has most commonly been implemented by having the DNS servers provide a
cyclic, round-robin selection of addresses, such that each address is
returned as the first result equally often.
This is not the only method for load balancing, though it is one of the
simplest and most easily deployed on today's Internet. Others include
giving entirely different results to different people doing DNS queries
such as described in the supersparrow architecture [1], or doing dynamic
load balancing of http queries via the 302 redirect response.
The primary expectations for load balancing are generally one or more of:
- that load be evenly distributed across hosts
- that load be biassed to the closest/cheapest host for the client
- that load distribution be controllable by the service provider
The prefix-matching procedure described in RFC3484 does not meet those
expectations in a number of cases.
First, responsibility for destination selection is assumed entirely by the
client, so that the only choice the service provider has is to list or
not list a host. As such the service provider is faced with a choice of
providing only the best servers to the client, and not giving the client
the possibility to failover to other servers that might be available;
or having the client select a server entirely on its own judgement.
Second, when NAT is in use, a relatively small range of prefixes (10/8,
192.168/16, 172.16/12 and potentially 169.254/16) will have a high
number of users, thus leading to a bias towards servers matching those
prefixes. Further, those prefixes by design do not bear any relationship
to their actual position in the network, removing the possibility of
the bias being towards close/cheap servers.
Third, when round-robin DNS is in use, the ordering procedure described
by RFC3484 will not ensure that all servers with the best matching
prefix are given equal time as the first address returned, but instead
may be biassed towards one address depending on the exact ordering of
the addresses presented by the server [2].
Each of these objections apply to the mechanism described in RFC3484
whether applied to IPv4 or IPv6 addresses.
In addition, with particular regard to IPv4 addresses, in the present
day Internet:
- round-robin DNS is normal
- NAT is extremely common
- the average prefix length in BGP tables is >22 [3], and
matches on shorter prefixes do not provide a strong correlation
with locality
...
Is the above all reasonable and uncontroversial?
If so, conclusions that could potentially be drawn:
(a) Using prefix matching to select IPv4 addresses isn't useful
(b) Using prefix matching to select IPv4 addresses is harmful
(c) Using prefix matching to select IPv4 addresses is harmful enough to
be an RC issue for Debian
(d) Prefix matching IPv4 addresses provided the match is at least 22 bits
(or similar) might be reasonable
(e) Choosing the best address isn't a job for the client, and is better
left to the service provider and DNS system
(f) Given the existance of round-robin DNS, if
