Subject: RFC 3484 section 6 rule 9 causing more operational problems

From: Tony Finch <[email-masked]>
Date: Wed, 4 Mar 2009 14:09:22 +0000

It seems that Vista implements RFC 3484 address selection, including the
requirement to sort IP addresses. This breaks a great deal of operational
dependence on DNS-based load balancing, as well as being based on an
incorrect understanding of how IP addresses are allocated.

RFC 3484 needs to be updated to delete this rule, so that the order
returned from the DNS is honoured when the client has no better knowledge
about which address is appropriate.

See
http://drplokta.livejournal.com/109267.html
http://www.ietf.org/mail-archive/web/ietf/current/msg51874.html
http://www.ietf.org/mail-archive/web/discuss/current/msg01035.html
http://www.ietf.org/mail-archive/web/dnsop/current/msg05847.html
http://lists.debian.org/debian-ctte/2007/11/msg00029.html

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 4 Mar 2009 09:59:02 -0500

[It seems to me that this discussion needs to happen in dnsext, so
I've added a Reply-To header to that effect.]

On Wed, Mar 04, 2009 at 02:09:22PM +0000, Tony Finch wrote:
> 
> RFC 3484 needs to be updated to delete this rule

May I assume that we'll see your I-D specifying the change as soon as
possible, then?  (I appreciate that it's a little late for a -00, but
maybe after the queue re-opens?)

Best regards,

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Tony Finch <[email-masked]>
Date: Wed, 4 Mar 2009 15:11:58 +0000

> maybe after the queue re-opens?)

I'm happy to say that Arifumi's I-D that Tim linked to already addresses
this problem, and seems to make a sensible recommendation. I'm upset that
it's too late to avoid serious operational pain.

http://www.watersprings.org/pub/id/draft-arifumi-6man-rfc3484-revise-00.txt

2.5.  To disable or restrict RFC 3484 Section 6 Rule 9

   Possible changes to RFC 3484 are as follows:

   1.  To delete Rule 9 completely.

   3.  To apply Rule 9 for IPv6 conditionally and not for IPv4.  When
       the length of matching bits of the destination address and the
       source address is longer than N, the rule 9 is applied.
       Otherwise, the order of the destination addresses do not change.
       The N should be configurable and it should be 32 by default.
       This is simply because the two sites whose matching bit length is
       longer than 32 are probably adjacent.

   Now that IPv6 PI address is admitted in some RIRs, hierachical
   address assignment is not maintained anymore.  It seems that the
   longest matching algorithm is not worth the adverse effect of
   disalbing the DNS based load balance technique.  Therefore, the
   proposal 1 or 3 seems to be preferable.

Tony.

---

From: Tony Finch <[email-masked]>
Date: Wed, 4 Mar 2009 15:30:39 +0000

On Wed, 4 Mar 2009, Florian Weimer wrote:
>
> I assume you are referring to IPv4 address sorting.

It's also wrong to sort IPv6 addresses by longest matching prefix (unless
the match is very long) because IPv6 addresses are also not allocated
according to network topology.

Tony.

---

From: Tony Finch <[email-masked]>
Date: Wed, 4 Mar 2009 15:37:24 +0000

On Wed, 4 Mar 2009, Paul Vixie wrote:

> i disagree.  dns-based load balancing is an unfortunate overloading and
> should never be done.  RFC 3484 is correct as it is.

Why is it right for topology-ignorant clients to override topology-aware
DNS servers based on wishful thinking about RIR address allocation
policies?

Tony.

---

From: Tony Finch <[email-masked]>
Date: Wed, 4 Mar 2009 17:06:24 +0000

On Wed, 4 Mar 2009, Paul Vixie wrote:
>
> you'll see roundrobin and lifo, among others, in many caches including
> stub caches.

Large numbers of sites have been depending on this behaviour for over 15
years, so it was wrong of RFC 3484 to break it.

Tony.

---

From: Tony Finch <[email-masked]>
Date: Wed, 4 Mar 2009 17:13:57 +0000

On Wed, 4 Mar 2009, Paul Vixie wrote:
>
> neither a client or a server can be guaranteed topology-aware.  dns leaves
> ordering deliberately undefined and encourages applications to use their
> own best judgement.

Rule 9 kicks in when the client has no topology information, which is why
it is broken.

Tony.

---

From: Christian Huitema <[email-masked]>
Date: Wed, 4 Mar 2009 09:21:46 -0800

> DNS servers based on wishful thinking about RIR address allocation

The order of records in a DNS response is, at best, a hint. Relying on it as if it were a mandate to clients is a gamble. It is quite legitimate for clients to consider the entire list of addresses and try to pick the best ones, based on their knowledge of topology. We may argue whether the specific algorithm in RFC 3484 is the correct one, and I hope that future clients will implement something smarter than prefix matching. But if service operators want to balance load on their servers, they need to consider something a bit more sophisticated than merely reordering the records in the DNS response...

-- Christian Huitema

---

From: Florian Weimer <[email-masked]>
Date: Wed, 04 Mar 2009 15:44:19 +0100

This has previously been discussed on DNS-related IETF WGs.  The
general belief is that this is not a DNS issue.  I find this a rather
strange conclusion, but we have to live with it.

RFC 3484 is being revised in one or more of the IPv6-related WGs.  I
don't know how far this effort has evolved.  There does not seem to be
a way to address the IPv4 part of the issue indepedently.

So right now it seems that the IETF is structurally incapable of
correcting this badly engineered specification.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 4 Mar 2009 08:31:04 -0800

I've added the ALTO mailing list to this discussion:

What it comes down to is you want "localization", not RFC 3484.

On Mar 4, 2009, at 8:05 AM, Ondřej Surý wrote:

>
>
> On Wed, Mar 4, 2009 at 4:17 PM, Paul Vixie <[email-masked]> wrote:
>> dns-based load balancing is an unfortunate overloading and
>> should never be done.
>
> Here I agree.

>
>> RFC 3484 is correct as it is.
>
> Here I don't. The idea behind is good, the implementation is not.
> Client would have to know BGP path to DA + DB and decide on
> basis of routing protocol. Selection based on longest matching
> prefix will work in only very small percent of case, all other cases
> are based on pure luck.

If a localization service is available, querying it to get the "Best  
match" would be most appropriate.  the ALTO group in the IETF is  
looking at such issues, primarily with respect to P2P, but elsewhere  
as well [1].

In the absence of localization, probably the best is "If prefix is  
almost identical, use it, otherwise select random", because address is  
almost irelevent for localization beyond the current network these  
days, but having the standard specify "select randomly" has some  
general benefits when localization is not available.

[1] In retrospect, I take back my comment about "should focus on P2P",  
localization may very well indeed be a more generic primitive.

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 4 Mar 2009 17:05:29 +0100

Here I agree.

Ondrej.

> > to unsubscribe send a message to [email-masked] with
> > the word 'unsubscribe' in a single line as the message text body.
> > archive: <http://ops.ietf.org/lists/namedroppers/>
>
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>
>

-- 
Ondrej Sury
technicky reditel/Chief Technical Officer
-----------------------------------------
CZ.NIC, z.s.p.o.  --  .cz domain registry
Americka 23,120 00 Praha 2,Czech Republic
mailto:[email-masked]  http://nic.cz/
sip:[email-masked] <[email-masked]> tel:+420.222745110
mob:+420.739013699     fax:+420.222745112
-----------------------------------------

---

From: Paul Vixie <[email-masked]>
Date: Wed, 04 Mar 2009 15:17:12 +0000

---

From: Tony Finch <[email-masked]>
Date: Wed, 4 Mar 2009 20:54:47 +0000

On Wed, 4 Mar 2009, Paul Vixie wrote:
>
> we've been lifo'ing and round robin'ing dns data in caches and stubs for a
> lot longer than 15 years,

This is the key feature than RFC 3484 breaks.

(I wasn't sure of the history - it was very murky when I tried to find the
origin of round-robin DNS.)

Tony.

---

From: Tony Finch <[email-masked]>
Date: Wed, 4 Mar 2009 20:55:13 +0000

On Wed, 4 Mar 2009, Paul Vixie wrote:
>
> "in my same /24" or "in my same /16" is a pretty good indicator, though.

Pity that ain't what the spec says.

Tony.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 05 Mar 2009 08:02:24 +1100

For this section to be useful you needs to be done at break
	points.  LAN  /64, SITE /56 or /48 and ISP /??.  Doing it
	on every bit boundary is just plain wrong.  The intent was
	good.  The specification was wrong.  To make this useful
	you need a protocol to distribute those break points.

	This is a little like a automated sortlist built into modern
	resolvers.

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Jari Arkko <[email-masked]>
Date: Thu, 05 Mar 2009 12:31:27 +0100

6MAN WG is working on this.

Jari

---

From: Tim Chown <[email-masked]>
Date: Wed, 4 Mar 2009 14:33:26 +0000

> http://lists.debian.org/debian-ctte/2007/11/msg00029.html

The issue is mentioned in:

"2.5.  To disable or restrict RFC 3484 Section 6 Rule 9

   There was a discussion at v6ops and [email-masked] mailing lists that
   the rule 9 of the destination address selection has a serious adverse
   effect on the round robin DNS technique...."

However the above has expired.  Perhaps Arifumi will issue a new version
before the upcoming cutoff.

-- 
Tim

---

From: Tony Finch <[email-masked]>
Date: Thu, 5 Mar 2009 13:34:37 +0000

On Wed, 4 Mar 2009, Paul Vixie wrote:

> only in the case where the server is depending on rr ordering within
> rrsets, which dns has never guaranteed and which many caches (both rdns
> and stubs) randomize or reorder anyway, and where the server's
> imputation of topology knows about every private interconnect that may
> affect client performance, would RFC 3484 do harm.

No, it does harm when the servers are depending on RRsets being DISordered.

Tony.

---

From: [email-masked]
Date: Wed, 4 Mar 2009 20:04:24 +0000

my error here - Paul said DNS does no ordering... he did not specify 
ordering of what.  we now return you to your rant.

--bill

On Wed, Mar 04, 2009 at 07:54:37PM +0000, Chris Thompson wrote:
> On Mar 4 2009, OndEej SurC= wrote:
> 
> >On Wed, Mar 4, 2009 at 6:57 PM, <[email-masked]> wrote:
> [...]
> >>        DNSSEC does reorder RRSets within a zone.  Which is a new feature.
> >
> >When we started talking about order of RRSets?  This is purely discussion
> >about order of RRs in RRSet. Order of RRSets in zone is irrelevant before
> >DNSSEC and also after DNSSEC. Nothing depends on order of RRSets
> >at least in my best knowledge.
> 
> I took Bill to mean "DNSSEC does reorder RRs within an RRset" anyway, as
> I don't know in what other sense DNSSEC is relevant at all.
> 
> But the canonical ordering of RRs within an RRset for signing purposes
> says nothing about the presentation order in the answers to DNS queries.
> And in fact a certain well-known nameserver implementation not unassociated
> with Paul still supports all the rrset-order and sortlist controls, which
> work for secured zones as well as unsecured ones.
> 
> -- 
> Chris Thompson
> Email: [email-masked]
>

---

From: Chris Thompson <[email-masked]>
Date: 04 Mar 2009 19:54:37 +0000

[...]

-- 
Chris Thompson
Email: [email-masked]

---

From: Florian Weimer <[email-masked]>
Date: Wed, 04 Mar 2009 18:51:45 +0100

> ordering deliberately undefined and encourages applications to use their

The "leaves undefined" part is at odds with your previous statement
that RFC 3484 is correct.  It is compliant with the rest of the
protocol zoo, but the order of records, as seen by applications, is
no longer undefined.

---

From: Florian Weimer <[email-masked]>
Date: Wed, 04 Mar 2009 19:01:20 +0100

* Christian Huitema:

> The order of5C records in a DNS response is, at best, a
> hint. Relying on it as if it were a mandate to clients is a gamble.

When you run RRset-based load balancing, you don't rely on servers
preserving order, or reordering responses.  It is completely
sufficient that there is a certain amount of variation among resolver
and application address selection.  It has been repeatedly and
independently observed that Rule 9 does not provide sufficient
variance, in contrast to previous behavior.

Rule 9 is also unfortunate because it means that after renumbering,
server loads change in ways the operator cannot influence (except by
requesting addresses with certain bit patterns, but I don't think
anybody wants vanity IP addresses).

---

From: Florian Weimer <[email-masked]>
Date: Thu, 05 Mar 2009 10:54:43 +0100

* Paul Vixie:

> some number of vendors have depended on revenue from selling this feature
> but i'd say that only a small number of sites ever saw any benefit from it.

pool.ntp.org, security.debian.org, rsync.gentoo.org,
[a-o].ns.spamhaus.org, [a-n].surbl.org.  In general the "large RRset"
approach is used by those who do not buy special DNS appliance to
serve their zones, I think.

Many CDNs also serve multiple addresses selected from a larger pool,
probably based on network topology and server load/availability.
Those folks can mitigate Rule 9 impact by carefully tuning the address
set in each response.  But those who rely on IETF protocols to
distribute and publish their DNS data are out of luck.

(Another approach to deal with the Rule 9 fallout is to put all your
servers into a dedicated prefix, but I don't think this is a good idea
in general.)

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 4 Mar 2009 19:20:02 +0100

On Wed, Mar 4, 2009 at 6:57 PM, <[email-masked]> wrote:

> On Wed, Mar 04, 2009 at 05:11:47PM +0000, Paul Vixie wrote:

Ondrej.

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 4 Mar 2009 21:33:00 +0100

On Wed, Mar 4, 2009 at 9:04 PM, <[email-masked]> wrote:

> we now return you to your rant.

Sorry, if I sounded too harsh.

> ordering of what.

Order of RRs in zone file is not relevant for the order "on the wire".
DNS (as in DNS protocol) does no ordering.

Ondrej.

> > On Mar 4 2009, OndE ej SurC= wrote:
> >

---

From: Paul Vixie <[email-masked]>
Date: Wed, 04 Mar 2009 20:24:33 +0000

>    Client would have to know BGP path to DA + DB and decide on basis of
>    routing protocol. Selection based on longest matching prefix will work
>    in only very small percent of case, all other cases are based on pure
>    luck.

random tends to be best, honestly.  but if there's an alternative that's
in the same /24 or /16 with you then this will be a useful optimization.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 04 Mar 2009 20:43:23 +0000

some number of vendors have depended on revenue from selling this feature
but i'd say that only a small number of sites ever saw any benefit from it.
we've been lifo'ing and round robin'ing dns data in caches and stubs for a
lot longer than 15 years, and the original dns rfc's said specifically that
rrset ordering was not guaranteed in the protocol, so anyone who depended
on it was getting screwed a long time before RFC 3484 came around.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 04 Mar 2009 22:01:29 +0000

>    /24 - could be, but is it worth?
>    /16 - not a chance; there are a lot of LIRs with /20 in RIPE region, so
>    /16 is way too
>    much (and you can have quicker connection to U.S. than to some parts of
>    Europe).

there are three modes here.

first, you can do some good.
second, you can do some harm.
third, you can have no effect.

RFC 3484 as it is can sometimes do some good.  and if it ends up using
address similarity as an indicator of probable proximity and it's wrong,
then it'll be the same as random.  only in the case where the server is
depending on rr ordering within rrsets, which dns has never guaranteed
and which many caches (both rdns and stubs) randomize or reorder anyway,
and where the server's imputation of topology knows about every private
interconnect that may affect client performance, would RFC 3484 do harm.

---

From: Tony Finch <[email-masked]>
Date: Thu, 5 Mar 2009 18:07:35 +0000

On Thu, 5 Mar 2009, Paul Vixie wrote:
>
> so the policy you're arguing for is that clients should always randomize?

When the client has topology information it should follow that (i.e. rules
1 - 8). When it doesn't have topology information it should use the order
it gets from the DNS (i.e. rule 10, and historical practice). This lets
the client's recursive server do whatever it thinks is sensible with the
RRset, which is usually round-robin balancing.

Tony.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 05 Mar 2009 18:01:50 +0000

---

From: Paul Vixie <[email-masked]>
Date: Thu, 05 Mar 2009 19:03:17 +0000

> RRset, which is usually round-robin balancing.

i can live with that.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 09 Mar 2009 15:55:29 +0000

> The NTP issue is rather specific and affected ntpd when you had
> 
> server pool.ntp.org
> server pool.ntp.org
> server pool.ntp.org
> 
> in your configuration.
> 
> And some those mirrors I mentioned are affected by *deterministic*
> reordering.  They don't care if traffic hits the closest instance,
> they want to spread the load (security.debian.org, for instance, is
> difficult to serve from a single node from time to time).

thanks for explaining that.

> > and the nameserver examples you gave are all subject to rdns RTT
> > sorting.
> 
> If you follow Rule 9, you haven't got that many RTTs to sort by: Rule
> 10 ensures that there is a single IP address you should use as long as
> the service on it is reachable.  Unless you cheat, deviate from Rule
> 9, contact additional servers, and gather additional RTTs--but you
> have to cheat to get that data.

i don't know any recursive nameservers that follow RFC 3483 for authority
server selection?  (your example here was of authority nameservers.)

> > and they have to use drastically low TTL's to prevent mobility from
> > breaking their assumptions.  and they have no way to cope with opendns
> > or any other global or semi-coherent caching layer.  and even when they
> > use TTL=0 and happen to be talking to an rdns who shares topology with
> > the stub, they're making an educated guess without knowing what kinds
> > of wormholes the stub may have access to, whether VPN, private
> > interconnects that don't show up in global BGP, or whatever.
> 
> Well, if it's not a good idea, why are most large web sites served
> this way?

nobody ever got fired for buying $whatever.  so: great marketing trumps
any kind of engineering whether good or bad.

> I suspect there is currently no better way to distribute initial
> client requests than to play DNS tricks.

since the web protocols support both permanent and temporary redirects,
i've always preferred approaches like IBM's over approaches like akamai's.

---

From: Danny Mayer <[email-masked]>
Date: Mon, 09 Mar 2009 00:24:57 -0400

Paul Vixie wrote:
>>> some number of vendors have depended on revenue from selling this
>>> feature but i'd say that only a small number of sites ever saw any
>>> benefit from it.
>> approach is used by those who do not buy special DNS appliance to serve
>> their zones, I think.
> 
> i'm not sure we're in the same discussion.  pool.ntp.org is using short
> ttl and silent truncation and round robin.  there's no geo-ip stability
> that could be hurt by client-side reordering or rerandomizing.  and the
> nameserver examples you gave are all subject to rdns RTT sorting.  the
> "large RRset" approach works just fine, and is not related to Rule 9.
> 

pool.ntp.org divides itself up into subdomains (okay they are really
hostnames) for each country-code so that you get addresses in that
country code. NTP in the future will take advantage of the fact that it
gets back multiple addresses and will use more than just one of them to
find NTP servers. The order does not really matter and it's better that
there be no particular order so that we do not overload any one server.

Danny

---

From: Ask Bjørn Hansen <[email-masked]>
Date: Sun, 8 Mar 2009 23:38:41 -0700

> there be no particular order so that we do not overload any one  

Hi everyone,

Funny the NTP Pool was brought up as an example.  I'm looking after  
pool.ntp.org and I actually subscribed earlier in the week to comment  
on the round robin issue.  :-)

It's a little more complicated than what Paul described above  
(although it worked like that until ~2005 when I took over maintaining  
the system).

When you query pool.ntp.org (or 1.pool.ntp.org etc), the DNS server  
does the "IP to geo-location" thing to automatically select the "sub- 
zone".  You can also explicitly ask for the sub-zone with  
0.us.pool.ntp.org, 0.north-america.pool.ntp.org, etc.

Paul is right that there's no problems with geo-stability because the  
DNS server will generally just give you servers from one area anyway;  
but we can get hurt by dumb re-ordering.

For distributing the load[1] we depend on clients making mostly random  
picks when receiving multiple A records.

Within each "zone" we have anywhere from a dozen to 1000+  
servers[2].   The DNS server will return a list of A records weighted  
by the bandwidth the server administrator have told us they have.   
This is absolutely crucial.  Before I implemented the current system,  
we just used a frequently updated zone with rotating A records and  
once or twice a day server operators with a small pipe (say a T1) or a  
small scale "router" would get overloaded enough that they'd leave the  
pool.

It's critical to the longevity and the geographic diversity of the  
pool that "small operators" are able to contribute; even if they  
handle much less traffic than others.

If "RFC 3484 section 6 rule 9" really is implemented with "matching"  
prefixes all the way up to /2, I'd worry that could mess up the  
weighting we do and cause operators on "unlucky" IP addresses to have  
to stop offering their service.

Since the DNS server does most of the weighting by giving just a few  
records from a usually much larger set, I could just return fewer A  
records to force "my choice".   But returning ~5 A records is valuable  
- some NTP servers knows how to use multiple A records from one lookup  
(ntpd in the future being one of them, as Danny pointed out).

Having the client be "smart" would be absolutely unhelpful.  Someone  
was arguing that the client might have useful network knowledge to  
apply.  I don't know of any actual implementations of that whereas  
there are lots of deployed implementations with the DNS server being  
smart and/or deliberate about the records returned.

   - ask

[1] The NTP Pool is used a lot.  You'd have an unlikely network to not  
have some local users.  It's the default in for example most Linux  
distributions and many consumer devices.  Practically none of the  
manufacturers contribute anything back; but the whole point of the NTP  
Pool is to preserve NTP as a useful public resource, so better us than  
some poor overloaded NIST server!

I don't know how many clients we have; but the name servers do about  
20m requests a day; and that's basically only counting "dumb" ntp  
clients because the long running daemons generally just do one set of  
lookups on startup.  It also, obviously, doesn't count the effects of  
local caches.  In any case: It's a lot of users.

[2] There are ~1743 active server in the pool right now distributed  
around the world: http://www.pool.ntp.org/zone - about 1000 in Europe  
and just under 600 in North America, http://www.pool.ntp.org/zone/ 
europe and http://www.pool.ntp.org/zone/north-america

-- 
http://develooper.com/ - http://askask.com/

---

From: Florian Weimer <[email-masked]>
Date: Mon, 09 Mar 2009 08:43:42 +0100

* Paul Vixie:

> that could be hurt by client-side reordering or rerandomizing.

server pool.ntp.org
server pool.ntp.org
server pool.ntp.org

in your configuration.

> breaking their assumptions.  and they have no way to cope with opendns or
> any other global or semi-coherent caching layer.  and even when they use
> TTL=0 and happen to be talking to an rdns who shares topology with the
> stub, they're making an educated guess without knowing what kinds of
> wormholes the stub may have access to, whether VPN, private interconnects
> that don't show up in global BGP, or whatever.

---

From: Danny Mayer <[email-masked]>
Date: Mon, 09 Mar 2009 13:10:28 -0400

> The NTP issue is rather specific and affected ntpd when you had

In your case it should read

server de.pool.ntp.org iburst
server de.pool.ntp.org iburst
server de.pool.ntp.org iburst

but that can result in your getting the same IP address for each of them
which is a problem particularly if you have remembered the last query.
Use of the new config option

pool de.pool.ntp.org iburst

would avoid that since it uses up to 10 IP addresses for NTP servers to
use from the list of IP addresses returned by the one getaddrinfo()
query. Here too you want to avoid any kind of preferred order. The use
of more than one returned address completely obviates the need for
RFC3484 which somehow assumes that you are only going to use one address.

Section 6 assumes prior knowledge of the addresses returned, either by
the O/S or the application. For example, Rule 1 talks about unreachable
addresses, but we won't know if they are unreachable unless we try that
address or have some OOB means of knowing and in any case are they
temporarily unreachable or permanently unreachable? Rule 3 talks about
deprecated addresses. What's that and how would anyone know if an
address is deprecated? Also if it is deprecated why is the DNS returning it?

Danny

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

---

From: Arifumi Matsumoto <[email-masked]>
Date: Mon, 16 Mar 2009 19:31:21 +0900

All,

I fail to submit a revision of my draft by cutoff, and
could not post it right now.
So I attached a draft to this e-mail.

I'm sorry that it does not reflect the discussion of this
thread greatly. I hope to have comments.

Kindest regards,

On 2009/03/04, at 23:33, Tim Chown wrote:

> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

--
Arifumi Matsumoto
   Secure Communication Project
   NTT Information Sharing Platform Laboratories
   E-mail: [email-masked]