Subject: RE: Proposed IPv6 DNS Discovery Requirements

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Mon, 29 Apr 2002 19:45:51 +0200

> > 1. The DNS can inject a route. Do you see problems
  > >    with this?
  > 
  > Well, "the DNS" doesn't do routes, but I assume you meant the DNS
  > server.  Yes, there are issues:
  > 
  > a) DNS server now has to implement one or more routing protocols,
  >    which is a lot more code than, say, a stub DHCP server.
  > 
  > b) What's the security model by which the router decides whether to
  >    accept routing updates from the DNS server?

=> The same model that is used between routers
in the network. 
I was only listing them in point form here, but 
the details are already in the draft. 

  > 
  > > 2. Using Neighbour discovery and periodic solicitations.
  > >    Most people in the DT didn't like this option.
  > >
  > > 3. The cleanest way: extensions to MLD to allow a node
  > >    to join an anycast group.
  > 
  > These are both polling approaches, right?  

=> Yes.

Exactly the same 
  > issues Bob
  > suggested apply to the co-resident DHCP approach apply here: how
  > tightly coupled does the thing you're polling have to be to the
  > service you're providing in order for the poll to tell you 
  > whether the
  > service itself is available?

=> That's up to your implementation. 
The DNS is the only server using this address, 
so you can tie them together.

Hesham
--------------------------------------------------------------------
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: Rob Austein <[email-masked]>
Date: Mon, 29 Apr 2002 14:27:15 -0400

At Mon, 29 Apr 2002 19:45:51 +0200, Hesham Soliman wrote:
> The same model that is used between routers in the network.

Right, so this approach adds a whole new set of boxes that can mess up
your routing system.  This does not strike me as a good thing.

> I was only listing them in point form here, but the details are
> already in the draft.

I read the draft (again).  I agree that it goes into more detail on
these points, I just disagree with its conclusions.

> That's up to your implementation.  The DNS is the only server using
> this address, so you can tie them together.

Sure.  One can do the same kind of thing with the DHCP approach (use
SO_REUSEPORT or whatever and tie the DHCP mini server to the DNS
server).

The point was just that exactly the same considerations apply to the
anycast proposal as apply to other proposals.

I have to admit that I also find it kind of amusing that this of all
WGs seems to be proposing to move service location functionality out
of the edge systems and into the network core.
--------------------------------------------------------------------
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: Steve Deering <[email-masked]>
Date: Mon, 29 Apr 2002 12:54:51 -0700

>of the edge systems and into the network core.

No more so than the use of DHCP relays does.  We're talking about the
IGP within a site, and taking advantage of what it already can do.

(Now that I mention it, perhaps DHCP relays ought also to be replaced
by the use of a well-known, site-local anycast address.)

Steve

---

From: Ralph Droms <[email-masked]>
Date: Mon, 29 Apr 2002 16:10:02 -0400

We've made a proposal in the latest rev of the DHCPv6 draft to use a 
well-known, site-local anycast address.

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Mon, 29 Apr 2002 16:11:46 -0400

>IGP within a site, and taking advantage of what it already can do.

So, the DNS Discovery proposals do no better than DHCP in the
area of distributing function out to the edge and away from
the network core?

---

From: Steve Deering <[email-masked]>
Date: Mon, 29 Apr 2002 13:47:48 -0700

>area of distributing function out to the edge and away from

That depends on which functions (DHCP? DNS?) are "in the core".
What the DNS Discovery proposal does is eliminate an unnecessary
intermediary.

Steve

---

From: Rob Austein <[email-masked]>
Date: Mon, 29 Apr 2002 23:28:32 -0400

> IGP within a site, and taking advantage of what it already can do.

Nope, you're storing new information in the IGP that wasn't there
before.  But back up and take it one step at a time.

In the abstract, DHCP is a multicast query, unicast response protocol.
A client yells "yo, anybody got a foo server?" and gets back zero or
more responses, from which it picks whichever response(s) it likes
(yes, I'm oversimplifying slightly, and am completely skipping over
stateful address assignment, which isn't relevant here, but in
principle that's how post-address-config works using DHCP).  Relay
agents (again ignoring stateful address assignment) are basicly a tool
for getting DHCP to work in environments that (for whatever reason)
don't suport multicast in its fully glory.

The key difference between the DHCP model and the anycast model is
that in the case of the DHCP model it's at least possible to set
things up so that the entity that's telling you where the DNS server
is actually -is- the same entity as the DNS server.  Thus, if the DNS
servers you're using have stopped responding, you can re-ask "where's
there a DNS server?"  and find out who's available now.  Similarly,
you can keep track of which addresses you've been talking to and how
well they worked (a DNS server can be up and running and still be
useless due to misconfiguration, bugs, system load, network load,
acts of malice, ...).

In the anycast model, you're at the mercy of the system that's
maintaining the anycast route: you can't query directly to find out
where the DNS server is, you have to wait for the routing system to
figure it out, and the routing system doesn't tell you when it change
the binding between a particular anycast address and the server behind
it, so you can't usefully keep track of which DNS servers have been
misbehaving recently.

So I stand by my previous statement that the anycast proposal moves
data and functionality from the edge into the core of the network.

I suspect that further discussion on this particular point would be
more suitable for a beer BOF in Yokohama than for this mailing list.

> by the use of a well-known, site-local anycast address.)

That'd be another step towards centralization, since it assumes an
environment in which there's only one[*] DHCP server that your client
might want to talk to, and completely loses the capability to send the
same question to whatever DHCP servers are in range.

[*] Or two, or three, or whatever small fixed number of anycast
addresses you choose to allocate, and to date I haven't seen an
explanation of how servers anycast::1, anycast::2, and anycast::3
are supposed to sort out which one gets which anycast address without
some kind of coordination mechanism that either involves yet another
new protocol or something that quacks like manual configuration.
--------------------------------------------------------------------
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: Brian Haberman <[email-masked]>
Date: Tue, 30 Apr 2002 08:07:14 -0400

Rob,

> it, so you can't usefully keep track of which DNS servers have been

Actually that is an incorrect statement.  The IPv6 addressing
architecture forbids the use of an anycast address as the source
address.  So, the response back from the anycast member will have
one of its unicast addresses as the source address.  So, it is
similar to your multicast request/unicast response model.

Regards,
Brian

---

From: Rob Austein <[email-masked]>
Date: Tue, 30 Apr 2002 10:04:03 -0400

> similar to your multicast request/unicast response model.

Sorry, back up.  I assumed that this proposal intended to change that
restriction, since with that restriction in place the resolvers won't
be able to match up the responses they get with the queries they sent
and anycast DNS won't work at all.  Perhaps this week's version of the
proposed solution for this is something that walks and quacks like an
anycast route but is called something else so that you can use it as a
source address.  I don't really care either way, it's still an anycast
route in all but name.

Apologies in advance if this sounds grumpy, it's not intended that
way, I just haven't had enough coffee yet today. :)
--------------------------------------------------------------------
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: Tue, 30 Apr 2002 23:15:06 +0900

>similar to your multicast request/unicast response model.

	more on the "anycast" topic can be found in
	draft-ietf-ipngwg-resv-anycast-02.txt.

	i start feeling that ietf process is taking too much time for vendors.
	if we don't standardize DNS server discovery mechanism, some vendor
	will ship products with DNS server address preconfigured to some
	address the vendor has.  it is the easiest solution if we can assume
	that there's only one DNS infrastructure.
	(like MacOS X shipped with NTP server configured to "time.apple.com")

itojun

---

From: Randy Bush <[email-masked]>
Date: Tue, 30 Apr 2002 10:22:56 -0400

> and anycast DNS won't work at all.

as i have been saying for a year or two.  this bit of stupidity makes
anycast useless for the majority of uses to which it is put today [0].
i presume it will be ignored, and hence die when this stuff tries to
go for draft.  if not, a buch of v6 use will die [1].

randy

---

[0] - of course the wonderous new world of v6 will have giga-jillions
      of more wonderful uses for this pseudo anycast.

[1] - why is the v6 community so hell-bent on shooting itself in the
      foot?  <http://cs.ru.ac.za/homes/cspt/hoare.htm>

---

From: Brian Haberman <[email-masked]>
Date: Tue, 30 Apr 2002 10:47:51 -0400

Rob,

> source address.  I don't really care either way, it's still an anycast

Section 9.2 of draft-ietf-ipv6-dns-discovery-04.txt states:

Since the destination address may be an anycast address, the reply
will necessarily come from a different address.  The host must not
discard the reply simply because the source address is different.
A more detailed discussion of this issue can be found in
[ANYCAST].

So, in my reading it is not proposing to lift the restriction,
rather engineer around it.

Brian

---

From: Rob Austein <[email-masked]>
Date: Tue, 30 Apr 2002 12:11:07 -0400

So now we're back to changing the DNS protocol and every IPv6-capable
DNS client in the world to support triangular wheels.
--------------------------------------------------------------------
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: Randy Bush <[email-masked]>
Date: Tue, 30 Apr 2002 16:11:07 -0400

> DNS client in the world to support triangular wheels.

but it's different than v4, so it means we're smarter.

randy

---

From: Bob Hinden <[email-masked]>
Date: Tue, 30 Apr 2002 14:47:20 -0700

Rob,

>way, I just haven't had enough coffee yet today. :)

Coffee is a good thing!

To clarify  <draft-ietf-ipv6-dns-discovery-04.txt>

Sections 1 through 8 is the main body of the proposal (called level 1) and 
is what is being considered by the working group.  Section 9 is an appendix 
(called level 2) for future study.  The next version of the draft will 
likely move this to a separate draft.  The last paragraph of section 1 stated:

   Note: This document only includes in its body a solution for obtaining
   the address of Domain Name Service servers. Mechanisms for obtaining
   the other parameters listed above are included in an Appendix A for
   further study. These may be moved to a separate document in the future.

The first set of sections (1-8) does not specify the use anycast or 
multicast, only unicast using three well know addresses.

Hope you enjoyed your coffee.

Bob

---

From: Bob Hinden <[email-masked]>
Date: Tue, 30 Apr 2002 16:36:11 -0700

Rob,

I think you mentioned in an earlier email about the need for NTP in order 
to use DNSSEC.

 From the discussion on the list it sounds like the timing requirement for 
DNSSEC is for the host to have a clock that is +/- 5 minutes.  This could 
be implemented with NTP or something else (e.g., accurate clock).

I read some of RFC2030 "Simple Network Time Protocol (SNTP) Version 4 for 
IPv4, IPv6 and OSI".  I think is what would be needed in most hosts.

RFC2030 has three mechanisms for a host to communicate with a SNTP server: 
Unicast, Multicast, and Anycast.  The Multicast and Anycast use well know 
IANA assigned multicast addresses and don't need any learned 
configuration.  The use of anycast is different than what we usually 
discuss as it also uses the well known multicast addresses but assumes some 
cooperation between the servers so only one responds.

I would think the unicast approach should work with well known unicast 
addresses (like the current DNS discovery proposal) at it uses UDP for a 
transport and consists of a single request with a single response.

I will add SNTP server addresses to the list of desirable features in the 
requirements text.

Bob

---

From: [email-masked]
Date: Wed, 01 May 2002 09:06:13 +0900

>go for draft.  if not, a buch of v6 use will die [1].

	regarding to anycast topic...

	currently-practiced IPv4 "anycast" is done via injecting the same
	address prefix by BGP from multiple locations - like the following
	documents.
	draft-ohta-root-servers-01.txt
	draft-ietf-dnsop-shared-root-server-01.txt

	the above approach assumes the following:
	- session lifetime is relatively short - like DNS and http
	- routing change is not frequent - at least, it won't happen
	  during session lifetime
	- content provided by anycast server is identical

	in the context of RFC2460, we cannot assume the above two - for
	example, people may try to establish long-lived TCP session to anycast
	address, and get RST suddenly due to routing changes.
	so i think it reasonable for RFC2460 to have limitation in source
	address selection, for general use anycast - it is a safety measure.
	if RFC2460 recommends something like "anycast address can be used
	only for short-lived sessions", it looks weird.

itojun

---

From: [email-masked]
Date: Wed, 01 May 2002 09:11:56 +0900

>DNS client in the world to support triangular wheels.

	not really.

	first, RFC2181 has particular care about anycast address - see
	the last line in section 4.1.

>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.		<---

	second, from implementation POV, microsoft resolvers does not check
	source (correct me if i'm wrong), and bind4/8 can change behavior
	by only a one-bit flag (RES_INSECURE1).  so it is not a big deal.

	third, i don't understand why the rule (source address of reply
	has to be equal to the destination of query) is enforced.  it may
	have been useful in the past, but with source address spoofing
	getting widely practiced, it provides no protection.  the only way
	we can be sure about data integrity is via DNSSEC (so unfortunately,
	we are using untrustable DNS responses every day at this moment).

itojun

---

From: [email-masked]
Date: Wed, 01 May 2002 10:27:22 +1000

> 	we are using untrustable DNS responses every day at this moment).

	On a busy caching server the number of outstanding queries can
	exceed the ID space.  Using a seperate ID space per IP address
	addresses this issue (except when using forwarders).

	Mark
--
Mark Andrews, Internet Software Consortium
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: Rob Austein <[email-masked]>
Date: Tue, 30 Apr 2002 23:04:20 -0400

> I think you mentioned in an earlier email about the need for NTP in order 

More precisely, in order to verify DNSSEC signatures, but yes.

> IPv4, IPv6 and OSI".  I think is what would be needed in most hosts.

I agree that SNTP's granularity would suffice for DNSSEC's purposes.
I'd add that one almost certainly wants to enable the NTP/SNTP
authentication stuff (yet another key management swamp, bletch).

SNTP is really just a lightweight version of NTP and operates on the
same ports (SNTP clients can and do use NTP servers, although the
other way around is a bad idea due to the precision downgrade), so the
distinction between NTP and SNTP may not really be relevant for
discovery purposes, but I have no problem with calling the service
"SNTP" for now.

> cooperation between the servers so only one responds.

Er, no.  "Anycast" (SNTP flavor) client sends out a multicast request,
gets back zero or more unicast responses, and "binds" to the server
that responds first.  The servers don't coordinate their responses.

> transport and consists of a single request with a single response.

Comments on "well known unicast address" model deferred to a later message.

> I will add SNTP server addresses to the list of desirable features in the 

Thanks.