Subject: Draft for RA-based DNS Discovery

From: "Jaehoon Paul Jeong" <[email-masked]>
Date: Wed, 12 Nov 2003 08:27:21 +0900

Hi all,

As I said at today's meeting, here is the merged draft for RA-based DNS Discovery;
http://www.ietf.org/internet-drafts/draft-jeong-dnsop-ipv6-dns-discovery-00.txt

For clarification, four authors in the above draft have reached consensus on merging three similar drafts into one.
Also, there are three drafts related to applicability of RA approach in mobile environments.

1. Application at NEMO
    http://www.ietf.org/internet-drafts/draft-jeong-nemo-ro-ndproxy-01.txt

2. Application at HMIPv6 
    http://www.ietf.org/internet-drafts/draft-jeong-hmipv6-dns-optimization-01.txt

3. Application at MANET connected to the Internet
   http://www.ietf.org/internet-drafts/draft-park-manet-dns-discovery-globalv6-00.txt

I really believe that RA-approach and DHCP-lite can coexit and that is necessary for
flexible DNS discovery in IPv6.
For implementation, the authors including me are ready to develop RA-based DNS Discovery in linux.
Actually, the implementation seems not to be so important in our discussion. :)
Thanks.

Jaehoon Paul Jeong

---

From: [email-masked]
Date: Wed, 12 Nov 2003 09:49:55 +0900

too bad we could not reach consensus on DNS dicovery.  i will do
	IPv6 tutorial at LACNIC next week, and again i will need to tell
	participants that there's no standard mechanism for DNS server
	configuration.

	(assuming that we're to pick one mechanism)

	one thing that is misunderstood in the meeting was, nothing prevents
	people from running mechanism that wasn't picked.  for instance, even
	if dhcpv6-lite is picked, 802.11-based SIP cellphone and its network
	can still run RA-based mechanism.  the SIP cellphone may need to
	implement dhcpv6-lite client as well so that it visits normal 802.11
	network (such as starbucks), but nothing prevents you from implementing
	such SIP cellphone.  i guess mobile-ip people (who favors RA-based
	approach) objected because they felt that they will be forced to run
	dhcpv6-lite.  that is not true.

	given that, my proposal is to pick dhcpv6-lite as the default mechanism
	to be used.  with reading the previous paragraph, could those who
	favors RA-based approach hum for dhcpv6-lite?

itojun
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Alain Durand <[email-masked]>
Date: Tue, 11 Nov 2003 21:03:11 -0800

> 	participants that there's no standard mechanism for DNS server

I'm not at IETF this week, but I'm following this from home.

Your last statement is not 100% true. We already have DHCPv6 as an RFC.
The DHCPv6-lite is fundamentally a collection of hints to create a 
simplified
implementation. So, there is already a standardized solution.

Now, the RA or well known address proponents claim this is not enough,
but apparently failed to gather momentum to demonstrate that a 2nd 
approach
is required.

IMHO the working group should then draw the conclusion that there is no 
consensus
to standardize neither the RA nor well known addresses solution and 
stick with
DHCPv6-lite as _the_ standardized solution, and I agree with you that 
anybody is free
to implement whatever ad-hoc solution he wants in his own backyard.

	- Alain.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 12 Nov 2003 16:55:06 +0900

Alain;

> to standardize neither the RA nor well known addresses solution and 

Standardize?

Apparently, you haven't read the well known address proposal.

						Masataka Ohta

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Wed, 12 Nov 2003 19:44:52 +0900 (JST)

> implementation. So, there is already a standardized solution.

	by "no standard mechanism" i meant the lack of consensus in DNS server
	configuration mechanism.  yes, you are right, dhcpv6 is already an RFC.

itojun

---

From: bill <[email-masked]>
Date: Wed, 12 Nov 2003 07:32:59 -0800 (PST)

> Apparently, you haven't read the well known address proposal.

	to reiterate my concerns expressed at the mic yesterday,
	
	Ohta-san, would you be comfortable with 200,000,000 devices
	being shipped with the IP address 131.112.32.188 (the address
	of one of your organizations nameservers) being burned into
	eeprom?

	disclaimers about restricting, by IETF fiat, well known addresses
	to special IP ranges will -NOT- work in the real world.

	If you are willing to commit your enterprise to absorb 0.1%
	of the total packets generated by 200,000,000 devices, then 
	perhaps I will be persuaded that use of well-known addresses
	is an operationally acceptable technique.  

	Yes, I know we do it now and it reduces the level of effort
	in getting new features deployed, but in -EVERY- case, the
	use of well known addresses has caused problems.

--bill

---

From: "Jaehoon Paul Jeong" <[email-masked]>
Date: Thu, 13 Nov 2003 00:49:40 +0900

----- Original Message ----- 
From: <[email-masked]>
> i guess mobile-ip people (who favors RA-based

As you saw at this meeting, lots of people really want RA-approach.
In the aspect of the number of messages exchanged, RA-approach is
superior to DHCP-lite, especially in mobile environment. 
Of course, I agree that DHCP-lite is useful in many cases.

My proposal is to adopt both RA-approach and DHCP-lite 
as in the case of Prefix Delegation.
Could those who insist only on DHCP-lite hum for the coexistence of these two mechanisms?

/Jaehoon

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Thu, 13 Nov 2003 00:52:02 +0900 (JST)

> Could those who insist only on DHCP-lite hum for the coexistence of these two mechanisms?

	if you propose coexistence you need to provide details on how to
	use those two, like:
	- try A then B
	- try A if condition X, try B if condition !X
	- whatever
	otherwise implementors will get highly confused.

itojun

---

From: Tim Chown <[email-masked]>
Date: Wed, 12 Nov 2003 16:06:16 +0000

> 	favors RA-based approach hum for dhcpv6-lite?

I think we had a 3:1 or better consensus that a single method should be 
agreed upon now.  But it was a lot less than 3:1 that that should be
DHCPv6-lite.

I feel the (multicast) RA-style method may have usage cases.  But we
don't have the operational experience yet to know what such cases may be
(in preference to DHCPv6-lite), and while RAs are well-defined, the
method to carry DNS info in the RA is not yet so (compared to DHCPv6-lite).

It seems the best way forward is to agree that DHCPv6-lite is the method
that implementors should proceed with now (some already have) and we
suck it and see.

That doesn't preclude:
a) people continuing to define RA method and implement/test it
b) future modification of dhcpv6-lite to multicast messages/responses
c) future studies of how dhcpv6-lite and RA method can co-exist
d) a future decision that RA method is the best (unlikely, but...)

Lets get the client support and dhcpv6 lite server and relay agents
implemented (Itojun said 13K lines of code for all?) and some experience
to base future work on.

Tim

---

From: bill <[email-masked]>
Date: Wed, 12 Nov 2003 07:50:03 -0800 (PST)

> 	configuration mechanism.  yes, you are right, dhcpv6 is already an RFC.

	other than the badness w/ wka, I fail to see the need to 
	continue w/ this "tempest in a teapot".  Both RA and DHCP
	will provide an IP address to a node that seeks for help.
	presume that both are implemented...

	in the case of one, the node gets one(or more) IP addreses
	and a DNS server list.  in the case of both, the node gets
	one or more IP addresses and a DNS server list.

	Thanks to Richard, source address selection is well understood.
	just merge the DNS list and we are done... yes?

--bill

---

From: Alain Durand <[email-masked]>
Date: Wed, 12 Nov 2003 08:58:28 -0800

> 	presume that both are implemented...

Are there any demonstrated benefits of having both?
I failed to see that. However there are obvious risk
anytime you have two mechanisms to achieve the same thing.

	- Alain.

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 13 Nov 2003 02:05:06 +0900

bill;

> 	to reiterate my concerns expressed at the mic yesterday,

Thank you very much.
	
> 	of one of your organizations nameservers) being burned into

I will be comfortable with 200,000,000 devices being shipped
with the IP address 127.0.0.1 (an anycast address) being burned
into eeprom, which was the point of my comment to you, yesterday.

I'll be fine if 127.0.0.1 is replaced by some anycast address,
as long as certain address range (say /24 in the C swamp or
/16 in class B) of the address is not used by anyone.

> 	to special IP ranges will -NOT- work in the real world.

I'm not sure what you mean.

Each well know addresses may have its own range to protect against
route filtering and there is no requirement of mine that
the addresses are restricted to special IP range.

> 	is an operationally acceptable technique.

200,000 devices are not for usual enterprises (or universities)
but for ISPs of medium scale.

But, I know an ISP, internal of which I know well, with >3,000,000
subscribers is operating DNS servers for all the subscribers.

So, what is the problem?

> 	use of well known addresses has caused problems.

I think I have shown a solution on the problem on root server
addresses with anycast addresses and AS numbers.

If there are other cases, let me know so that I can try to use
anycast approach for the problems.

						Masataka Ohta

---

From: "Jaehoon Paul Jeong" <[email-masked]>
Date: Thu, 13 Nov 2003 02:08:32 +0900

----- Original Message ----- 
From: "Jun-ichiro itojun Hagino" <[email-masked]>
Sent: Thursday, November 13, 2003 12:52 AM
> otherwise implementors will get highly confused.

Did you read my draft?
My draft describes the coexistence.
Please, look at Section 5 of my draft, Procedure of DNS Discovery;
 http://www.ietf.org/internet-drafts/draft-jeong-dnsop-ipv6-dns-discovery-00.txt
Of course, this is one of the possible alternatives for coexistence.
Therefore, we need to discuss the coexistence more.
Thanks.

Jaehoon

---

From: Jim Reid <[email-masked]>
Date: Wed, 12 Nov 2003 17:17:50 +0000

>>>>> "bill" == bill  <[email-masked]> writes:

    bill> 	Ohta-san, would you be comfortable with 200,000,000
    bill> devices being shipped with the IP address 131.112.32.188
    bill> (the address of one of your organizations nameservers) being
    bill> burned into eeprom?

    bill> 	Yes, I know we do it now and it reduces the level of
    bill> effort in getting new features deployed, but in -EVERY-
    bill> case, the use of well known addresses has caused problems.

Like Netgear hard-wiring the address of a University of Wisconsin NTP
server into the firmware of ther products. Every one of those boxes
sends an NTP request once a second to that UoW server. See
	http://www.cs.wisc.edu/~plonka/netgear-sntp
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Alain Durand <[email-masked]>
Date: Wed, 12 Nov 2003 09:14:23 -0800

> 	otherwise implementors will get highly confused.

And so will network admin that will now have potentially two places to 
look after
to maintain the correct information. This is bad.

	- Alain.

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Thu, 13 Nov 2003 03:09:38 +0900 (JST)

> implemented (Itojun said 13K lines of code for all?) and some experience

	correction: i said 13K in the session, but that number included
	yacc/lex output.  correct number is 11K line in total for server,
	relay agent and client (*.[ycl]).

itojun

---

From: Ted Lemon <[email-masked]>
Date: Wed, 12 Nov 2003 12:33:54 -0600

> 	just merge the DNS list and we are done... yes?

That would mean writing an additional standard and getting it through 
to RFC.   I don't think we want to do that.   Certainly an agreeable 
majority of the folks who ventured an opinion at the meeting yesterday 
did not want this.

My personal vote, for what it's worth, is to use DHCPv6-lite, because I 
don't like the idea of putting DNS info into a routing protocol.   It's 
the old camel's nose under the tent problem - what are you going to add 
next?   I don't mention this to start a debate - I know people who are 
pushing RA as the solution have good reasons - my point is merely that 
I also have good reasons, of which the one I've mentioned is actually 
only one of several.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 12 Nov 2003 12:58:39 -0600

>> 	otherwise implementors will get highly confused.

Reading RFC 2462 will clear that confusion right up. There is an 
explicit bit in router advertisements that tells hosts whether they 
should use a stateful mechanism (sorry, this is what it's called, 
replace with "DHCPv6lite" in the next version) to discover additional 
configuration information. If this bit is set then the only reason for 
the existence of DNS RA options would be for the benefit of hosts that 
don't implement DHCP, so it would make sense for hosts that do 
implement DHCP to ignore the option in this case.

Another approach would be to simply take all the DNS addresses that can 
be found and validate this list by doing a test query or use RTT 
measurements to select the best one.

(I have a box with a long since forgotten implementation of IP(v4) + 
PPP that allows the use of DHCP to gather additional configuration 
information. This implementation also allows DNS servers to be probed 
before they are installed in the list of resolvers. All of this works 
very well.)

> look after to maintain the correct information. This is bad.

This is exactly why requiring the use of some form of DHCP by making 
this the only way DNS addresses can be found is a bad idea. Hosts are 
already required to implement Stateless Autoconfiguration (again, I 
didn't come up with the name) so in this case there are two things that 
can go wrong: RAs and DHCP. If DNS discovery is integrated in RA we 
have fate sharing.

---

From: bill <[email-masked]>
Date: Wed, 12 Nov 2003 11:30:56 -0800 (PST)

> anytime you have two mechanisms to achieve the same thing.

	well, I can see nodes that move between topologies, some
	where RA is used/prefered and some where DHCP is used prefered.
	historically, the SA's for DHCP service are distinct from the
	SA's who manage routing, so moving forward, we are providing
	a tool to each community that performs essentially the same
	task.  The end systems have had to deal with getting IP 
	addresses assigned from multiple places (static, RA, DHCP)
	already - listing DNS server preference when there are 
	multiple inputs -can't- be that hard.

	And its not like the IETF has not promoted two solutions
	in the past...  can you say OSPF and ISIS?   Sure you can.

--bill

---

From: bill <[email-masked]>
Date: Wed, 12 Nov 2003 11:47:26 -0800 (PST)

> into eeprom, which was the point of my comment to you, yesterday.

	so would i, but for perhaps distinctly divergent reasons. :)

> /16 in class B) of the address is not used by anyone.

	and that can -NOT- be assured, hence the danger of
	promoting the use of well known addresses. 
> the addresses are restricted to special IP range.

	one can not ensure all parties that do routing will respect
	the IETF concerns regarding routing restrictions.  A quick
	look at the prohibitions of using RFC 1918 space in the 
	Internet adn the empirical evidence of thier leakage (AS112
	project) are a powerful incentive to protocol designers
	that operators take prohibitions as suggestions at best.
	that said, all addresses are potentially "well-known".

> but for ISPs of medium scale.

	missed an order of magnitude there.  presuming a vendor
	picks the "well-known" address that your enterprise uses
	and burns it into eproms (e.g. the recent netgear episode)
	and ships them -worldwide- then all those devices will
	try and use your service - since it has your well known
	address hard coded.   UoW NTP IP service was burned into
	a vendors hardware, saturating the incoming network links
	to the university and the university network itself.

> subscribers is operating DNS servers for all the subscribers.

	excessive traffic from non-customers.

> addresses with anycast addresses and AS numbers.

	and there are significant long-term problems with that 
	approach, such as content coherence and route hijacking.

--bill

---

From: Ted Lemon <[email-masked]>
Date: Wed, 12 Nov 2003 14:22:57 -0600

On Nov 12, 2003, at 12:58 PM, Iljitsch van Beijnum wrote:
> should use a stateful mechanism

The stateful vs. stateless bit refers to address configuration in the 
sense of getting an IP address for the node, not getting an IP address 
to which to send DNS requests.   When the stateful bit is set, you are 
supposed to use some stateful address configuration mechanism to get an 
IP address to use when communicating on the network.   Stateful DHCPv6 
is the only protocol that can currently be used for this, only because 
no other protocol has, as far as I am aware, been defined.

Your error may be in thinking that DHCPv6 is always stateful, and 
perhaps in not understanding what stateful means (it's a somewhat 
unfortunate use of terminology, IMHO, but that's water long since under 
the bridge).   What stateful means is that the node seeking an address 
to use sends a request to a server, which may have state on it about 
the node seeking an address, and may use that state to choose a 
configuration for the node.   It may also generate new state and store 
it at that time.   This is in contrast to stateless address 
configuration, where the client generates an address on the fly, 
without consulting any server, and where there is no server keeping 
track of what addresses are associated with what clients.

This has nothing to do with what we are talking about right now, except 
that DHCPv6 and DHCPv6-lite share the same transport.   I've heard you 
repeat several times that the stateless bit in the router advertisement 
can be used to say which mechanism to use, but that is completely 
wrong, because in using this bit in the way you propose, we would be 
making two changes to the behavior of the client, not one - it could, 
as you say, use DHCPv6 to get its DNS address, but it would also be 
required to use DHCPv6 to get its IP address.   We are specifically 
trying to avoid placing any such requirement on a network - stateless 
addrconf has to be orthogonal to how the DNS server address is 
obtained, because the two things are completely unrelated.

So we can not use the stateless bit in the router advertisement in the 
way you describe, and we do need to advance a new protocol 
specification in order to have a mechanism for choosing RA vs. 
DHCP-lite, and we don't have any pressing need to do that.   So we 
shouldn't.

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 13 Nov 2003 05:37:12 +0900

Iljitsch;
 
> configuration information.

That is the source of all the confusions caused by a poorly defined
word of "stateless". 

That is, DHCP-lite is considered to be a "stateless" mechanism.

I agreee DHCP is the way to go with the, so called, "stateful" cases.

						Masataka Ohta

---

From: Tim Chown <[email-masked]>
Date: Wed, 12 Nov 2003 21:07:11 +0000

> required to use DHCPv6 to get its IP address.   We are specifically 

Ted, I don't understand here, it seems to me from the spec that (in p.18
of RFC2461, and in the usage text in RFC2462) that the M and O bits
are independent;  i.e. a statelessly autoconfiguring host could get DNS
info from DHCPv6 with M=0 and O=1.     With M=0 and O=0 one would
then assume that an RA-based method could be used, and not clash with any
DHCPv6...?   Could you clarify what I'm missing?

> obtained, because the two things are completely unrelated.

I guess not everyone agrees with that :)

Tim

---

From: Alain Durand <[email-masked]>
Date: Wed, 12 Nov 2003 13:41:33 -0800

>	in the past...  can you say OSPF and ISIS?   Sure you can.

Except it is well understood that the two are mutually exclusive.
and restrospectively, wouldn't have we been better with just one?
(pick your favorite)

As a general point, I believe the IETF should refrain standardizing
two or more solution to the same problem. One is enough.
Let's focus the energy on other problems that require immediate attention.

    - Alain.

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 13 Nov 2003 07:00:51 +0900

bill;

> 	missed an order of magnitude there.

Because you said 0.1%.

>	presuming a vendor
> 	address hard coded.

That is a problem caused primarily by stupidity of a vendor but
partly by not having a standard (anycast) address of the NTP server.
If configuration is necessary, vendors tend to put some value
at factory.

If SNTP RFC have listed some well known anycast address (including
meaningless one such as 127.0.0.1) and have stated it should
be the well known default, it was fine.

>>anycast approach for the problems.

Thank you and Jim for another case.

> 	approach, such as content coherence and route hijacking.

Anycast root allows a local administrator control a local root
server.

So, content coherence is a local issue. You, as a subscriber trying
to run your own server, can ask your ISP or anyone you want where
a newest copy is. As an ISP, ask NIC or anyone you want.

Route hijacking is a problem of a unicast root sever and anycast
is the solution. How can you hijack a route confined in an ISP?

						Masataka Ohta

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 12 Nov 2003 15:55:48 -0600

> supposed to use some stateful address configuration mechanism to get 
> an IP address to use when communicating on the network.

This is from RFC 2461, [ADDRCONF] refers to RFC 2462:

4.2.  Router Advertisement Message Format

    Routers send out Router Advertisement message periodically, or in
    response to a Router Solicitation.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |     Code      |          Checksum             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Cur Hop Limit |M|O|  Reserved |       Router Lifetime         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Reachable Time                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Retrans Timer                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Options ...
      +-+-+-+-+-+-+-+-+-+-+-+-

[...]

       M              1-bit "Managed address configuration" flag.  When
                      set, hosts use the administered (stateful) protocol
                      for address autoconfiguration in addition to any
                      addresses autoconfigured using stateless address
                      autoconfiguration.  The use of this flag is
                      described in [ADDRCONF].

       O              1-bit "Other stateful configuration" flag.  When
                      set, hosts use the administered (stateful) protocol
                      for autoconfiguration of other (non-address)
                      information.  The use of this flag is described in
                      [ADDRCONF].

> perhaps in not understanding what stateful means

Whether or not DHCPv6 is stateful doesn't make a lot of difference with 
regard to the problem we're facing. If we assume that hosts will be 
using router advertisements for autoconfiguration, then adding DHCP for 
DNS configuration is exactly that: adding another protocol. This is bad 
because there is now an additional mechanism that can fail and there is 
additional delay in configuring.

Now obviously doing this using a heavy version of DHCP is worse than 
doing this using a light version of DHCP, but the fundamental problem 
is the same in both cases. The only reason I use the words stateful and 
stateless during this discussion is because this is what's in the RFCs.

While I can relate to the slippery slope and implementing certain 
functionality just once arguments, I strongly believe that pragmatic 
operational arguments (not having an additional protocol on the wire) 
should carry the most weight in this very particular case.

> I've heard you repeat several times that the stateless bit in the 
> router advertisement can be used to say which mechanism to use, but 
> that is completely wrong,

I beg to differ. I believe the above excerpt from RFC 2461 proves my 
case.

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 13 Nov 2003 05:10:54 +0900

Jim Reid;
 
> sends an NTP request once a second to that UoW server.

That is not an argument applicable to addresses dedicated to anycast.

With anycast, that someone send something to an address
and that someone send something to a server are different
things. Read a section on scoping in my draft.

						Masataka Ohta

---

From: Ted Lemon <[email-masked]>
Date: Wed, 12 Nov 2003 16:49:14 -0600

On Nov 12, 2003, at 3:07 PM, Tim Chown wrote:
> Could you clarify what I'm missing?

You obviously weren't aware that I hadn't read RFC2461 or RFC2462 since 
the last time I did some serious thinking about DHCPv6, which was quite 
a while ago, and that I had forgotten about the distinction between the 
'M' and 'O' bits.   Shame on you!   :')   You are right, and I 
apologize for stating my case based on my poor recollection, instead of 
going and reading up on the stateless bits first.

My first reaction to this was to say "well, then my point was wrong".  
My second reaction was "so why do so many people for whom I have great 
respect say we should pick one?"

After thinking some more, I think my objection is still correct - I 
just stated it badly because I didn't do my research first.   Let's say 
we use the 'O' bit to say what to do.   What if the 'O' bit is not set, 
but there's no DNS information in the RA?   Is there a protocol written 
down that says what to do in this case?   What if the 'O' bit is not 
set, and there is non-node-address in the RA, whatever that may be, but 
still no DNS information?  Do I do DHCP-lite in this case?   What if 
DHCP-lite gives me information that conflicts with what I got in the RA 
- which do I prefer?

 From the perspective of implementation, in order for a client to work 
correctly in all cases, it has to:
    - Know what to do in the cases I just mentioned
    - Implement DHCP-lite
    - Implement the DNS server RA option, which implies:
      Provide a way for the resolver and the RA listener to communicate.

This sounds doable, but is it in fact the minimal correct solution?   I 
don't think so.   I think the minimal correct solution is to pick one.  
  One reason I like DHCP-lite, as I stated in my previous message, is 
that it doesn't piggyback on a routing protocol, so you don't have to 
tie the RA listener and the resolver together.   So I think it's a good 
choice if we're going to pick one.  And I think picking one is a good 
idea, because it means that you only have to implement DHCP-lite.   You 
don't need to know what to do in the edge cases I talked about.

That doesn't mean we can't describe how to do the more complicated 
two-protocol case.   In the case of a cell phone network, where you 
don't mind hooking the resolver and the RA listener together, and you 
really want to stuff the DNS info in the RA message, you can still do 
it without any extra packet exchanges - you had to wait for the RA 
anyway, and if the 'O' bit is set and there's a DNS server option in 
the message, you're done - you don't have to do DHCP-lite.   But when 
you roam to a network that doesn't provide this functionality, you do 
have to be able to fall back to DHCP-lite.

What this means is that devices for which it's advantageous to use the 
RA DNS server information will have to implement both DHCP-lite and RA, 
and pay attention to the 'O' bit, and devices for which it's 
advantageous to implement only one protocol will just implement 
DHCP-lite.   And system administrators that want devices to take 
advantage of the 'O' bit if possible need to configure things so that 
that works.   Which can probably be done automatically, with no 
operator intervention, in applications like the cell sites.

The other thing this means is that we can move forward now.   
Describing how to make RA and DHCP-lite implementations coexist doesn't 
have to be on our critical path.

---

From: [email-masked]
Date: Thu, 13 Nov 2003 10:07:30 +1100

WKA adds yet one more set of addresses that need to be
	filtered at the organisation's boundaries.  Do you really
	trust the your neighbors DNS servers to have the *same*
	view of the world as you?

	It is easy to accidently introduce single points of failure
	into anycast solutions even though you have topologically
	spread your nameservers.  It much harder to do this with
	a non-anycast solution.

	WKA doesn't remove the need to have another solution to
	supply the search list.

	Mark
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: bill <[email-masked]>
Date: Wed, 12 Nov 2003 15:17:39 -0800 (PST)

> and restrospectively, wouldn't have we been better with just one?

	depends on when you ask...  8 years ago, the choices
	were radically different than today.  And given a specific
	topology in question, you would find one more efficent
	than an other one.  And there are several documented cases
	where both were/are used in the same topology.

	so, I would posit that the answer to your question is -NO-.

> Let's focus the energy on other problems that require immediate attention.

	Generally true, but as I have learned, 
	"all generalizations are false. this is true of all generalizations."

	given both RA and DHCP are defined, implemented, and deployable,
	recognizing both and working on interoperability clearly moves
	the locus to an issue that requires immediate attention, e.g.
	what does a node do when presented with information from both
	RA and DHCP wrt which DNS servers are available for use?

--bill

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 13 Nov 2003 08:40:38 +0900

Iljitsch;

> doing this using a light version of DHCP, but the fundamental problem is 
> the same in both cases. The only reason I use the words stateful and 

Good.

However, the problem is that RA insists that it distinguish "stateless"
and "stateful".

The simplest solution is to remove RA, entirely.

						Masataka Ohta

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 12 Nov 2003 18:03:11 -0600

> 	spread your nameservers.  It much harder to do this with

Agree completely. Anycast can work well when (1) you control the
end-points and (2) you control the netblock. The current proposal leaves
those elements under somebody else' control ('default' configs that use
hard-coded addresses which follow competing route advertisementss).

> 	WKA doesn't remove the need to have another solution to

I don't see that as a problem for the 'default' service since the data in
question is particular to each administrative domain, and therefore has to
be configured explicitly on a per-site basis. So for that particular data,
the admin either has to config the host anyway, or the admin should be
looking towards making a management investment in DHCP or whatever suits
their needs. But for a 'default' service that just needs to be able to
resolve basic FQDNs, being able to have resolvers locate functional
servers automagically is good enough, and is a reasonable scope.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: Tim Chown <[email-masked]>
Date: Thu, 13 Nov 2003 01:23:59 +0000

> respect say we should pick one?"

Good question.  I am trying to be open minded :)    My head says DHCPv6
is there and can be done now (is being done now).  My heart says lets
not preclude RA method.
 
>      Provide a way for the resolver and the RA listener to communicate.

I think the "what to do when a device gets an RA answer and a DHCPv6
answer" question may be avoidable.  The client should only select one
method based on the RA O/M bits.

The hint for configuration comes from the RA O/M bits.   The network provider 
has to configure the RA O/M bits to match the DHCPv6 or RA method that 
they support.

The device does not care if it is getting the O-bit DHCPv6 options via
"stateful" DHCPv6 or "stateless" DHCPv6 light.   

Cases are, if we assume O=0 means RA method is used:

1) M=1 O=1: Stateful address autoconfiguration, DNS options by DHCPv6

2) M=1 O=0: Stateful address autoconfiguration, DNS options by RA 

3) M=0 O=0: Stateless address autoconfiguration, DNS options by RA

4) M=0 O=1: Stateless address autoconfiguration, DNS options by DHCPv6

I think of the above (2) is the only improbable scenario.  The other
cases are valid for different types of networks.  I would hope (2) could
simply be discarded.

So I think the RA "hint" and service provided should always be in sync;
the problem is what support the client has, and in particular then
how/if you fall back when client support is not present for the method 
"hinted" by the RA.

The DHCPv6 camp is really suggesting cases (1) and (4) are the only
valid RA option settings that should be used.   This creates simplicity,
but at a cost of flexibility.

Consider client support.   We assume all devices have stateless address
autoconfiguration ability, so we don't have to fall back from that to DHCPv6
(full) for address autoconfiguration.

So that leaves these cases:

Case 1:
 - no DHCPv6 (full) => fall back to case (4)
 - neither DHCPv6 (full) or DHCPv6 (light) => fall back to case (3)
 - if the client has DHCPv6 (full) it has DHCPv6 (light)

Case 3:
 - no RA method for DNS options => fall back to case (4)

Case 4:
 - no DHCPv6 (light) => fall back to case (3).

So the real concern are these four fallback cases, and the delays or
other implications they have (like whether you will actually find a method
that works at all!).   A minimum agreed single method gives a guarantee 
that one fallback will work ....

Tim

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 13 Nov 2003 12:28:36 +0900

>>>>> On Wed, 12 Nov 2003 16:06:16 +0000, 
>>>>> Tim Chown <[email-masked]> said:

> implemented (Itojun said 13K lines of code for all?) and some experience

I concur (actually I've already concurred with you on this point).

I don't think we can reach a consensus by continuing this discussion
that would include another round of pros and cons comparison.  I know
someone pointed out in the 2nd dnsop meeting that it's not wise to
rush into a conclusion.  Still, I don't think we'll find a tie-breaker
by continuing the discussion.  I also know there is some
misunderstanding about the basic specification in this thread (such as
confusion about the "M" and "O" flags of router advertisement
messages).  And I'm not claiming I'm an exception; I admit I may also
misunderstand some technical points.  Still, I don't think
clarifications on these points can be a tie-breaker.

No one will win this battle, and the loser will be IPv6 (by the delay
of deployment).

Sadly, I cannot think of a good tool to break through the situation.
One typical approach might be to let the chairs decide (I'm not saying
this because I expect the chairs would pick up the one I support:-),
but this is probably against the IETF's convention.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 13 Nov 2003 11:00:44 +0900

Mark.Andrews;

> 	filtered at the organisation's boundaries.

No. Read the draft section 4.1.

>       Do you really

Are you having a view that the Internet still consists of voluntury
organizations directly connected? Read the draft section 4.1.

> 	spread your nameservers.  It much harder to do this with

Anycast, just like multicast, itself is no robust. Read the
draft section 4.1.

> 	WKA doesn't remove the need to have another solution to

That is not a requirement.

						Masataka Ohta

---

From: Mans Nilsson <[email-masked]>
Date: Thu, 13 Nov 2003 11:28:52 +0100

> 	multiple inputs -can't- be that hard.

It means more code, more bugs, more interop problems. 

> 	in the past...  can you say OSPF and ISIS?   Sure you can.

End nodes (the devices who receive autoconfig benefits) typically do 
not talk IGP, except that they may discover a route via RA's or get 
it via DHCPv4. Thus, the choice of IGP does not bother the end nodes. 
It is more like using vi or emacs to edit zone files. Does not affect 
the casual user/autoconfig node. 

So, my point is that the "interface to the masses" needs to be uniform,
as uniform as can be. One resolver configuration method (besides
$EDITOR /etc/resolv.conf) makes the world a less confused place.

And, I think we're in agreement on WKA. They are a can of worms. 

-- 
Måns Nilsson         Systems Specialist
+46 70 681 7204         KTHNOC
                        MN1334-RIPE

I fill MY industrial waste containers with old copies of the
"WATCHTOWER" and then add HAWAIIAN PUNCH to the top ...  They look NICE
in the yard ...

---

From: [email-masked]
Date: Fri, 14 Nov 2003 02:25:15 +1100

> organizations directly connected? Read the draft section 4.1.

	I believe organisations will continue to want to use split
	DNS.  Running split DNS will become much more than just
	runing nameservers and telling the clients where they are.
	It also involves reconfiguring routers to filter routes.
 
> Anycast, just like multicast, itself is no robust. Read the

	I did read the draft.  You draft is forcing the use of
	anycast to get load sharing.  The other proposals don't
	have this property.  You can get load sharing w/o
	resorting to unicast.

> That is not a requirement.

	It's not a requirement if the ONLY thing you want clients
	to know about the DNS is the addresses of nameservers.  In
	the real world there are lots of organisations that want
	to push other configuration details out.  The proposals
	you are competing with can support this.

	There have been cases where I have wanted to push out the
	other DNS configuration and times when I don't.  The lack
	of support for this is reason enough to reject this solution.

	You draft also states that the anycast addresses will have
	global scope.  Does this mean that we are going to have to
	introduce the concept of stub routers so that the correct
	prefixes are configured for nodes on a routerless network?

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 13 Nov 2003 10:28:27 -0600

> 	you are competing with can support this.

Well... It's 'possible' to pass a search list to the resolvers as part of
a startup negotiation, it's just not necessary, and it may even be
determined as undesirable after some more thinking.

In particular, if the logic focuses on choosing a candidate server versus
using any available server, then the server part of the algorithm can
require "return a list of SOAs for which you are authoritative", and the
client algorithm can allow the resolver to use the owner names of the SOAs
as the search list. Extending this logic a bit, it's feasible that any
particular implementation could provide a configuration ~directive that
filtered the domains which the server should return, thereby providing a
way for managers to control the search list array in use by the clients.

Negotiation versus queries isn't the focus of the current WKA proposal, of
course, but as I already said, I think that's the second necessary change
(switching to multicast is the first; anycast is a non-starter).

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 14 Nov 2003 01:59:36 +0900

Mark;

> 	DNS.

If you are talking about not organizations but organizations
doing something special, say so from the beginning.

>       Running split DNS will become much more than just

Split DNS costs, a lot. That's all.

> 	I did read the draft.

Read, and then, properly quote the draft. But, you actually don't
even read the draft.

>       You draft is forcing the use of
> 	anycast to get load sharing.

No, not at all. To quote the draft, instead of you, it says:

   Within a static boundary, there may be a single server for each
   anycast address, or there may be multiple servers sharing an anycast
   address, which may be useful for load distribution.

that there is no forcing.

 
> 	of support for this is reason enough to reject this solution.

You are talking about organizations wanting a lot "stateful"
configuration, which is out of the scope of the discussion.
 
> 	prefixes are configured for nodes on a routerless network?

As anycast servers advertise routes to themself, that is, they
are routers, that the network with them is not routerless.

But, I'm not sure what you want to do with DNS on such network.

							Masataka Ohta

---

From: [email-masked]
Date: Fri, 14 Nov 2003 04:14:59 +1100

> determined as undesirable after some more thinking.

	No one is saying you have to supply the information.  What I am
	saying is that the *ability* to do this is crucial in some
	environments.

	I don't want my ISP to supply a search path.  I also don't
	want my ISP to depend upon that search path in there HTML
	documents.

	I have also been a network adminstator in a business.  In that
	envirionment setting search lists is important.

---

From: Daniel Senie <[email-masked]>
Date: Thu, 13 Nov 2003 21:55:38 -0500

At 06:07 pm 11/12/2003, [email-masked] wrote:

         wka adds yet one more set of addresses that need to be
         filtered at the organisation's boundaries.  Do you really
         trust the your neighbors dns servers to have the *same*
         view of the world as you?

         Wka doesn't remove the need to have another solution to
         supply the search list.

Perhaps, if we do decide to continue down the well-known-address approach 
in this and other cases, we should give some thought to the class e address 
space. Does wka usage rise to the level where this would be justified? It's 
been some time since class d space was allocated to multicast.

Using space out of existing unicast space is problematic for the reasons 
outlined above.

---

From: Mans Nilsson <[email-masked]>
Date: Fri, 14 Nov 2003 10:53:11 +0100

> that implementors should proceed with now (some already have) and we
  ...
> implemented (Itojun said 13K lines of code for all?) and some experience

I support this path forward. 

While you're chewing, think of STEVEN SPIELBERG'S bank account ...  his
will have the same effect as two "STARCH BLOCKERS"!

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 14 Nov 2003 19:40:20 +0900

Daniel;

Read the draft.

					Masataka Ohta