Subject: DNS query over anycast

From: [email-masked]
Date: Sat, 02 Jun 2001 02:59:26 +0900

there was a question regarding to DNS response against this kind of
	query:
		(src=x dst=anycast)
	needs to have anycast source address or not.

	from RFC2181, it is legal to use non-anycast address for response.

	and for the resolver side (implementation issue):
	- BIND8 resolver checks source address match by default, but can easily
	  turned off by RES_INSECURE2 flag bit on res.options.
	- MS windows DNS resolver does not (correct me if I'm wrong about this).

itojun

---
4.1. UDP Source Address Selection

   To avoid these problems, servers when responding to queries using UDP
   must cause the reply to be sent with the source address field in the
   IP header set to the address that was in the destination address
   field of the IP header of the packet containing the query causing the
   response.  If this would cause the response to be sent from an IP	 <-
   address that is not permitted for this purpose, then the response may <-
   be sent from any legal IP address allocated to the server.  That	 <-
   address should be chosen to maximise the possibility that the client
   will be able to use it for further queries.  Servers configured in
   such a way that not all their addresses are equally reachable from
   all potential clients need take particular care when responding to
   queries sent to anycast, multicast, or similar, addresses.

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: [email-masked]
Date: Sun, 03 Jun 2001 17:19:36 +1000

> 	needs to have anycast source address or not.

	I would be setting the anycast address as the source address of the
	reply.

> 	from RFC2181, it is legal to use non-anycast address for response.

	This part was written for broadcast and multicast addresses.

--
Mark Andrews, Nominum Inc.
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: [email-masked]
Date: Sun, 03 Jun 2001 16:24:16 +0900

>	I would be setting the anycast address as the source address of the

	under limitation declared in RFC2373, we cannot.

itojun

---

From: Robert Elz <[email-masked]>
Date: Sun, 03 Jun 2001 17:04:44 +0700

Date:        Sun, 03 Jun 2001 17:19:36 +1000
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | 	This part was written for broadcast and multicast addresses.

It was written for any address from which it was not legal to send
a reply (including 0.0.0.0 etc).   If that includes anycast addresses,
then it includes anycast addresses...

It is simply pointless to have a spec requiring something to be
done which some other spec says one must not do - all that leads to
is duelling RFCs.

So, when it is legal DNS servers must respond from the address to which
the packet was sent - any other time, they have to use some address that
is in fact legal to use.

And I know, that since an anycast address looks syntactically just like
a unicast address, this can be tricky at times...

kre

---

From: [email-masked]
Date: Mon, 04 Jun 2001 10:47:04 +1000

> 	under limitation declared in RFC2373, we cannot.

	Well this is all moot as anycast addresses are not allowed to
	be assigned to hosts and DNS service is host functionality.

   "There is little experience with widespread, arbitrary use of internet
   anycast addresses, and some known complications and hazards when
   using them in their full generality [ANYCST].  Until more experience
   has been gained and solutions agreed upon for those problems, the
   following restrictions are imposed on IPv6 anycast addresses:

      o An anycast address must not be used as the source address of an
        IPv6 packet.

      o An anycast address must not be assigned to an IPv6 host, that
        is, it may be assigned to an IPv6 router only."

	In the IPv4 world we are expecting the source address of
	the DNS reply to match the destination address in the
	anycast case.

	The restiction on source address is primarily driven by
	TCP and load balancing causing multiple anycast hosts to
	receive one TCP stream. 

	Also how do you get experience that would break the above
	restiction without breaking the above restiction.  Classic
	catch 22.

	To get around the truncation and tcp fallback we could have
	a EDNS option that specified a unicast address to use that
	is sent back with the truncated response.  Or do we just send
	this EDNS response and force a switch to unicast regardless of
	TC.

	Mark

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Mon, 04 Jun 2001 10:10:54 +0900

>	be assigned to hosts and DNS service is host functionality.

	the condition "host cannot have anycast address" was introduced
	because, when RFC2373 was written, there seem to be no way for
	hosts to inject /128 routes to the site routing system.  actually it is
	very easy to solve:
	- hosts with anycast address speak RIPng, OSPFv3 or whatever, and
	  inject /128 route to the site routing system.
	- extension to MLD, draft-haberman-ipngwg-host-anycast-00.txt
	- configure a static route for anycast address (/128) onto the router
	  adjacent to the anycast host.
	- run DNS server on a router (you can make a UNIX box a router,
	  you know)
	the first bullet is very easy and can be tested with no protocol change.
	we have been using it quite a while.

	the condition "don't put anycast into source" was introduced because
	of tcp issues, as you've described.

	draft-ietf-ipngwg-ipv6-anycast-analysis-00.txt describes it in full.

>	this EDNS response and force a switch to unicast regardless of

	yes, truncation and the fallback to TCP is a problem.
	here are a list of solutions i can think of on truncation/fallback
	issue:
	- clients should use EDNS0 and avoid most of the truncation cases.
	- TCP query should pick the destination address from the UDP reply.
	  (possibility of hijack, of course)

itojun

---

From: Randy Bush <[email-masked]>
Date: Sun, 03 Jun 2001 18:47:04 -0700

>    anycast addresses

actually, there is a fair bit of experience with it.

as far as i can tell, the base problem here is that folk who have had no
experience with v4 anycast service deployment know in theory or in vitro
that there can be problems in some circumstances, namely non-ephemeral tcp
sessions finding themselves connected to the wrong host due to routing
changes [0].  

unfortunately, the result has been outlawing a whole bunch of stuff which
can not exhibit this kind of problem, namely udp based anycast services,
and outlawing tcp services which may not be as susceptable to the problem
about which they seem to be worried.

this is unfortunate as we have real services widely deployed in v4 anycast
which will now be a pain in v6.  yet another thorn we ourselves place in
the side of real v6 deployment.

randy

---

[0] - in fact, in real deployment, long lived tcp to a v4 anycast seems
      more stable than even optimism would seem to warrant.  research
      continues.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: "JIM FLEMING" <[email-masked]>
Date: Sun, 3 Jun 2001 20:54:50 -0500

What is "real v6 deployment" ?

Jim Fleming
http://www.unir.com/images/architech.gif
http://www.unir.com/images/address.gif
http://www.unir.com/images/headers.gif
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt
http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/start.asp

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Randy Bush
Sent: Sunday, June 03, 2001 8:47 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: DNS query over anycast 

randy

---

---

From: [email-masked]
Date: Mon, 04 Jun 2001 12:16:10 +1000

> 	  (possibility of hijack, of course)
	
	I stand by my original answer as to the source address is
	the anycast address for DNS.

	RFC 2373 clearly expects this section to be potentially
	overridden.  You don't get dueling RFCs when the overriding
	RFC acknowledges the one being overridden.

	Mark

---

From: Steve Deering <[email-masked]>
Date: Sun, 3 Jun 2001 19:29:28 -0700

>	of tcp issues, as you've described.

Itojun,

TCP is not the only reason for the restriction against using an anycast
address as a source address.  I can think of at least two other reasons,
and there may well be more:

  (1) This restriction avoids the hazard of an ICMP error message
      being sent, regarding an erroneous packet, to a node that
      did not originate that packet.

  (2) For a packet whose destination is a multicast address, this
      restriction ensures that those multicast routing algorithms
      that use reverse-path forwarding will continue to work correctly.

Basically, there are a number of places in the current architecture
that assume that the source address of an IP packet identifies a single
node; the restriction against using an anycast address as a source
address ensures that we don't break anything that makes that assumption.

The resulting requirement -- that request-response-style applications
not simply swap the two addresses when sending a response message --
is needed anyway for responding to multicast requests, and has been
satisfied long ago in most implementations of common UDP-based or
ICMP based applications (such as ping), so ought not to be that hard
to comply with.

Steve

---

From: Steve Deering <[email-masked]>
Date: Sun, 3 Jun 2001 19:38:46 -0700

>a unicast address, this can be tricky at times...

Part of the job of assigning an anycast address to a node is informing
that node that that address is an anycast address, i.e., an address
that is potentially shared with other nodes.  That ensures that the
node responsible for choosing the source address has the info needed
to distinguish its own unicast addresses from its own anycast addresses,
despite the lack of any syntactic indication in the addresses themselves.

Steve

---

From: Steve Deering <[email-masked]>
Date: Sun, 3 Jun 2001 19:56:17 -0700

>actually, there is a fair bit of experience with it.

Randy,

There wasn't when that sentence was written.  (That's the hazard of
including such sentences in a long-lived document -- another thing
for the RFC editor to watch for?)

>that there can be problems in some circumstances

This is a case where we don't need to run the program to demonstrate that
there's a bug in it.

>... 

The restriction doesn't outlaw such services; it just requires that
those services satisfy the restriction, which may require a simple
change to the service in some cases (those that weren't fixed years
ago to accommodate multicast queries).

>      more stable than even optimism would seem to warrant.

So the bug doesn't show up often in practice.  That doesn't mean the bug
doesn't exist and won't have harmful consequences in those rare occasions
when it is triggered.

>research continues.

Research in finding and understanding the corner cases?

Steve

---

From: Randy Bush <[email-masked]>
Date: Sun, 03 Jun 2001 20:01:48 -0700

> that is potentially shared with other nodes.

then the mis-behavior is a configuration option operators can ignore?

randy

---

From: Randy Bush <[email-masked]>
Date: Sun, 03 Jun 2001 20:04:27 -0700

> Research in finding and understanding the corner cases?

to try to explain why bumblebees fly, despite that their inability to do
so is "a case where we don't need to run the program to demonstrate that
there's a bug in it."

randy

---

From: Steve Deering <[email-masked]>
Date: Sun, 3 Jun 2001 20:10:15 -0700

>then the mis-behavior is a configuration option operators can ignore?

Yes, there are many ways for operators to misconfigure their nodes and
networks, and this offers one more.

Steve

---

From: Randy Bush <[email-masked]>
Date: Sun, 03 Jun 2001 20:18:55 -0700

>>> that is pot>red with other nodes.

we poor stupid operators have to do something to overcome the mis-designs
of the oh so brilliant but reality-challenged.

while one can not measure all dns transactions, a significant number of
them use just such a 'misconfiguration'.  please excuse our stupidity in
wishing to continue to offer our customers better service.

randy

---

From: Robert Elz <[email-masked]>
Date: Mon, 04 Jun 2001 12:49:08 +0700

Date:        Sun, 03 Jun 2001 20:18:55 -0700
    From:        Randy Bush <[email-masked]>
    Message-ID:  <[email-masked]>

  | while one can not measure all dns transactions, a significant number of
  | them use just such a 'misconfiguration'.  please excuse our stupidity in
  | wishing to continue to offer our customers better service.

For v4 there is probably no other way.   For v6 we're still early enough
in the grand scheme of things that we could easily change the DNS
spec (actually just the DNS clarifications - 2181) and require that
v6 based resolvers ignore the source address of a reply, and match the
reply to the query using the query ID and question alone.

Using the IP address doesn't gain much really - it certainly doesn't
offer any protection against bogus replies - in reality it is little
more than one extra field to check.

The requirement in 2181 is there not because the DNS protocol requires
it, but because the vast majority of resolvers deployed happened to
be implemented to expect it - that is, servers must send their answers
that way, or they will be ignored.

For v6, there are essentially no deployed resolvers yet (almost all v6
name resolution that is currently done is done using the v4 DNS), so
changing the v6 resolvers to simply omit that check on the replies
they receive (via v6), and process anything would not be a very difficult
change to make.

Aside from allowing replies to anycast queries to be sent from a unicast
address (as could replies to multicast addresses, even broadcast) this would
also vastly simplify the average DNS server, which would no longer need to
care which particular address received the query, but could just send the
reply using any convenient source address.   For v6 nodes that are expected
to have more addresses than your average v4 node, this is probably a win
(even given the better v6 API that allows the dest addr of the query to
be determined without having to bind a socket to every possible address,
something that is a real challenge for v4 DNS servers in environments where
addresses come and go frequently - like a server on the "dialing" end of a
PPP connection, or anyone using v6 temporary addresses).

For v4 there's probably not a lot to be done now - and so simply sending the
reply from an anycast address is probably the only way that can work, there
are simply too many deployed resolvers for it to be changed.   Fortunately,
most of the bugs that can be caused by sending from an anycast (UDP)
address don't matter to the DNS (the only way to be sending to a multicast
address from an anycast would be if the query originated from a multicast
address - so that one we can ignore - and DNS servers typically get so many
meaningless ICMP reports anyway, and have absolutely no state to associate
them with anything at all, that getting a few erroneous ones isn't going to
bother them at all).   The problems that can happen when the node that
(without knowing it) sent to an anycast address, and then gets a truncated
reply, and tries again with TCP will just have to be suffered.

kre

---

From: Randy Bush <[email-masked]>
Date: Sun, 03 Jun 2001 22:55:07 -0700

> spec

there are other deployments which use anycast, not just dns.  dns is
just the one we can talk about in public and is most obvious.  anycast
is actually *seriously* deployed and used.

randy

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Mon, 04 Jun 2001 15:17:37 +0900

>they receive (via v6), and process anything would not be a very difficult

	just FYI:

	NetBSD, FreeBSD and OpenBSD has been shipping with IPv6-ready
	client resolvers quite a while (more than a year).
	some of them supports EDNS0 (but not the fallback mechanism), some of
	them does not.  yes, you may be able to say that the install base
	is still small, but "essentially no deployed resolvers" sounds
	incorrect to me.

	also, older version of BIND9 responds to multicast/anycast query by
	mistake:-)  anycast responses depend on the OS you run named on.
	(don't remember the exact versions)

itojun

---

From: Steve Deering <[email-masked]>
Date: Sun, 3 Jun 2001 23:24:37 -0700

>wishing to continue to offer our customers better service.

Sigh.

This is the classic tradeoff between the expedient hack and an
alternative that accomplishes the same goal in a way that actually
fits with the way the system was designed to work, but takes some
more work to deploy.

If there is an urgent customer need to deploy IPv6 anycast DNS
transactions before the IPv6-capable DNS servers can be upgraded to
provide a unicast source address in response to an anycast query,
go ahead and (mis-)configure the servers to think an anycast address
is a unicast address.  Sure, this will work fine almost all of the time
(or else you wouldn't be advocating it).  And if all goes well, it won't
result in too many calls to your help desk, reporting unusual failures
that are difficult to diagnose because they are difficult to reproduce
(being the result of infrequent coincidences).  Also, be sure that your
support staff makes a note of the non-obvious topological limitations
that must be adhered to to make your approach work properly, such as
making sure that two such servers are never placed in the same subnet
(so that DAD won't prevent the use of the shared address).

But can we please also work towards deploying the simple fix in the
servers required to support an anycast service that is not susceptible
to known potential failure modes and that does not have unexpected
topological restrictions?  After all, this is the IPv6 effort, which
has the quixotic goal of trying to make the Internet less fragile,
rather than just not-too-much-more-fragile.

Steve

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 04 Jun 2001 15:40:12 +0900

>>>>> On Mon, 04 Jun 2001 15:17:37 +0900, 
>>>>> Jun-ichiro itojun Hagino <[email-masked]> said:

> 	(don't remember the exact versions)

(although this is probably an off-topic,) even the latest version of
BIND9 can respond to IPv4 multicasted queries and IPv6
multicasted/anycasted queries; it does not check the destination
address to prevent such queries.  Whether or not we see replies to
such queries does not depend on the version of bind9, but on the
implementation of the underling kernel.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 04 Jun 2001 18:03:11 +0900

>>>>> On Sun, 3 Jun 2001 19:38:46 -0700, 
>>>>> Steve Deering <[email-masked]> said:

> despite the lack of any syntactic indication in the addresses themselves.

That's correct, but from an implementor's point of view, anycast
addresses are more problematic than multicast, because there is no
standard API to see if a given address is an anycast address on the
node nor to see if a received packet is anycasted.  We may have to
define a standard (portable) way as a part of the advanced API (bis).

					JINMEI, Tatuya

---

From: "David R. Conrad" <[email-masked]>
Date: Mon, 04 Jun 2001 02:22:27 -0700

Kre,

At 12:49 PM 6/4/2001 +0700, Robert Elz wrote:
>name resolution that is currently done is done using the v4 DNS)

Just a data point: last time I checked (back in April), there were about 
100,000 unique sites downloading BIND version 9 which has a full IPv6 
supporting resolver.  How much that resolver is being used is, of course, a 
different question and one much harder to answer.

Rgds,
-drc

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 04 Jun 2001 18:28:00 +0900

>>>>> On Mon, 04 Jun 2001 02:22:27 -0700, 
>>>>> "David R. Conrad" <[email-masked]> said:

> different question and one much harder to answer.

Just checking, what do you mean by "resolver" here?  If you mean
lwresd in bind9 or the resolver routine in BIND9 named, it's okay.
However, as far as I know, all released BIND9 (except the very recent
one -9.2.0a1-) do not include the "traditional" style of local
resolver library, which can be linked with other application binaries.

					JINMEI, Tatuya

---

From: "David R. Conrad" <[email-masked]>
Date: Mon, 04 Jun 2001 02:36:37 -0700

lwresd (thus my comment about how much it being used :-))

At 06:28 PM 6/4/2001 +0900, JINMEI Tatuya /

---

From: Randy Bush <[email-masked]>
Date: Mon, 04 Jun 2001 04:15:57 -0700

the underlying mismatch is that anycast use should not require the
other end to know that it is dealing with a second class citizen.
folk deploying a service using anycast want it to look *exactly*
the same as a unicast service.  that's the whole point of it.

randy