Subject: DHCPv6lite, RA and WKA

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 17 Nov 2003 20:35:08 +0100

I do understand the concerns the proponents of DHCPv6lite-only have 
with regards to having more than one mechanism. The general software 
engineering approach is "put all your eggs in one basket, but be sure 
you're making one hell of a basket". I disagree this applies here, 
though.

I believe the situations where DNS addresses need to change and when a 
large number of hosts connect to a subnet simultaneously uncover 
problem areas with DHCPv6lite. The former can be handled by a full 
stateful implementation of DHCP, but using such an implementation when 
all that's needed is distribution of DNS addresses isn't attractive. 
Avoiding a "DHCP storm" when a large number of hosts connect isn't 
readily solvable without creating additional mechanisms, also not 
attractive.

For this reason, and because running the DHCP(lite) service results in 
additional operational complexity and security risks on both the 
servers and clients, I feel very strongly that we need a non-DHCP 
mechanism for determining DNS resolver addresses that can be used 
together with RFC 2462 IPv6 address configuration. This mechanism can 
either be an RA option or well-known addresses.

What I don't understand is the fear of well-known addresses. This 
subject seems to have an extensive history, but I can't seem to find 
the actual arguments, as the discussion has long since deteriorated to 
kindergarten level: "Would you want 200 million devices to be shipped 
with the DNS of your organization burned into ROM?"

Obviously the well known addresses for DNS resolvers shouldn't come 
from regular unicast space that is assigned to an organization. At the 
very least these addresses should be sitting in portable blocks so they 
can be moved around without impact to the organization hosting one (or 
more) of them. Another option would be anycasting the addresses in 
question. The best way to handle this would probably be for a small 
number of organizations to host a well know address each, and allow 
sites and ISPs to anycast the addresses within their AS. So a host 
within a site anycasting the DNS WKA the host has selected for a query, 
the request will be handled by a local DNS resolver. If the site 
doesn't anycast the address but the ISP does, the query goes to the ISP 
DNS resolver. If the ISP doesn't anycast either, the request goes to 
the organization hosting the WKA.

I don't believe the permutations of when to use which mechanism in the 
presence of multiple mechanisms are too complex. It boils down to 
"listen to the "additional stateful config" flag". The only situation 
where this leads to sub-optimal results is in the case where router 
advertisements indicate the use of DHCPv6lite for additional 
configuration, but the DHCP negotiation fails. When this happens, the 
presence of another configuration mechanism allows the host to function 
anyway. The choices are relatively straightforward:

1. Configure WKA or RA, overwrite with DHCP after DHCP completes
2. Configure WKA or RA only after DHCP fails

(Alternatively, what should happen in the case where the "additional 
stateful config" flag isn't set but there are no non-DHCP mechanisms 
available to configure DNS resolver addresses?)

I understand it's annoying to keep having this discussion, but 
annoyance doesn't configure DNS resolvers, so let's come up with an 
approach (nearly) everyone can live with and put this all to bed. After 
all, we're talking about a two page RFC (excluding the boilerplate) for 
either WKA or RA, this all pretty basic stuff.

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

---

From: Bob Hinden <[email-masked]>
Date: Tue, 18 Nov 2003 16:48:15 -0800

Iljitsch,

I think you make a very good case for going in this direction.  A few 
comments in line.

At 11:35 AM 11/17/2003, Iljitsch van Beijnum wrote:
>I do understand the concerns the proponents of DHCPv6lite-only have with 
>regards to having more than one mechanism. The general software 
>you're making one hell of a basket". I disagree this applies here, though.
>
>large number of hosts connect to a subnet simultaneously uncover problem 
>areas with DHCPv6lite. The former can be handled by a full stateful 
>implementation of DHCP, but using such an implementation when all that's 
>needed is distribution of DNS addresses isn't attractive. Avoiding a "DHCP 
>storm" when a large number of hosts connect isn't readily solvable without 
>creating additional mechanisms, also not attractive.
>
>additional operational complexity and security risks on both the servers 
>and clients, I feel very strongly that we need a non-DHCP mechanism for 
>determining DNS resolver addresses that can be used together with RFC 2462 
>IPv6 address configuration. This mechanism can either be an RA option or 
>well-known addresses.

As you point out below, all three mechanics could coexist in a hierarchy.

>What I don't understand is the fear of well-known addresses. This subject 
>seems to have an extensive history, but I can't seem to find the actual 
>arguments, as the discussion has long since deteriorated to kindergarten 
>level: "Would you want 200 million devices to be shipped with the DNS of 
>your organization burned into ROM?"
>
>Obviously the well known addresses for DNS resolvers shouldn't come from 
>regular unicast space that is assigned to an organization. At the very 
>least these addresses should be sitting in portable blocks so they can be 
>moved around without impact to the organization hosting one (or more) of 
>them. Another option would be anycasting the addresses in question. The 
>best way to handle this would probably be for a small number of 
>organizations to host a well know address each, and allow sites and ISPs 
>to anycast the addresses within their AS. So a host within a site 
>anycasting the DNS WKA the host has selected for a query, the request will 
>be handled by a local DNS resolver. If the site doesn't anycast the 
>address but the ISP does, the query goes to the ISP DNS resolver. If the 
>ISP doesn't anycast either, the request goes to the organization hosting 
>the WKA.
>
>presence of multiple mechanisms are too complex. It boils down to "listen 
>to the "additional stateful config" flag". The only situation where this 
>leads to sub-optimal results is in the case where router advertisements 
>indicate the use of DHCPv6lite for additional configuration, but the DHCP 
>negotiation fails. When this happens, the presence of another 
>configuration mechanism allows the host to function anyway. The choices 
>are relatively straightforward:
>

A slightly different approach is to start with well known addresses.  If an 
RA option is heard (probably in the same RA with the prefix) with new DNS 
addresses give these priority over the well known addresses.  If the RA 
messages tell the host to use DHCP for "additional stateful config", then 
request this information via DHCP.  If new DNS addresses are received via 
DHCP, then give these priority over any other DNS addresses known by the hosts.

>I understand it's annoying to keep having this discussion, but annoyance 
>doesn't configure DNS resolvers, so let's come up with an approach 
>(nearly) everyone can live with and put this all to bed. After all, we're 
>talking about a two page RFC (excluding the boilerplate) for either WKA or 
>RA, this all pretty basic stuff.

Perhaps four pages each, but I am in complete agreement with your point!

Bob

---

From: "Jaehoon Paul Jeong" <[email-masked]>
Date: Wed, 19 Nov 2003 13:20:57 +0900

I completely agree with both Iljitsch and Bob Hinden
at the point of making basic RFCs of RA and WKA  for DNS discovery.
Until now, many people have described these two schemes well enough 
in addition to DHCPv6-lite.
Through the experience in the actual world, we can verify the coexistence of these three schemes
or know which is the most preferable in each application domain in the aspect of practical use.
If many people in DNSOP wg agree with my opinion, I will start to implement my proposal of
RA-based DNS discovery in order to progress the coexistence with the other schemes.
Thanks.

/Jaehoon

---

From: Ralph Droms <[email-masked]>
Date: Wed, 19 Nov 2003 06:27:42 -0500

At 08:35 PM 11/17/2003 +0100, Iljitsch van Beijnum wrote:
>I believe the situations where DNS addresses need to change

This issue has never been found to be a problem DHCPv4.  The appropriate
timers will be added DHCPv6 to provide the same function in
stateless DHCPv6 (as you point out, those timers exist when DHCPv6 is used
for address assignment).

>  and when a large number of hosts connect to a subnet simultaneously 
> uncover problem areas with DHCPv6lite. The former can be handled by a 
> full stateful implementation of DHCP, but using such an implementation 
> when all that's needed is distribution of DNS addresses isn't attractive. 
> readily solvable without creating additional mechanisms, also not attractive.

"DHCP storm" has never been an issue for DHCPv4, where the problem is
potentially more serious because DHCPv4 is usually used for address
assignment.  What evidence do we have the "DHCP storm" will suddenly become
a problem in DHCPv6?

>IPv6 address configuration. This mechanism can either be an RA option or 

I think we should reserve judgment on the additional operational complexity
associated with stateless DHCPv6 until we actually have some operational
experience.   Based on the existing implementations of stateless DHCPv6, I
don't see where the additional operational complexity will come from.

>your organization burned into ROM?"

If well-known addresses are such a good idea, why haven't we adopted them
for IPv4?

Summarizing from below, I agree that we can specify the use of the 'O' bit
to control the use of stateless DHCPv6 just as the 'M' bit controls the use
of DHCPv6 for address assignment.  I still disagree that the supposed
shortcomings to stateless DHCPv6 given in the first paragraph are sufficient
to warrant the use of well known addresses or the development of an
extension to RAs.

---

From: Tim Chown <[email-masked]>
Date: Wed, 19 Nov 2003 13:31:01 +0000

> stateless DHCPv6 (as you point out, those timers exist when DHCPv6 is used

Right, adding a life-time for the non-address options (DNS, NTP, search
path,...) would allow clients to send periodic information requests to
the stateless server at a frequency determined by the site admin (who may
know about impending renumbering events or the addition, movement or removal 
of a DNS or NTP server).

But here I'm drifting from the "how do you convey DNS info to the client"
to the "how do you tell the client this info has changed" discussion.
There is some overlap.

> assignment.  What evidence do we have the "DHCP storm" will suddenly become

Presumably that enterprise networks will tend to have more IP(v6)-enabled
devices...?
 
> don't see where the additional operational complexity will come from.

It seems we should push ahead and try DHCPv6 Light until we see specific 
problems where (for example) piggybacking DNS info on RAs would be better.
It's for that reason that I started thinking out the renumbering issue (or
situations where non-address configuration settings like DNS or NTP server
change). 

> to warrant the use of well known addresses or the development of an

If we do find a need for multiple solutions, we really need
a) a baseline solution for all cases as Mat suggested (is this possible?)
b) to know that each method will interoperate 

These are both complexities in the multiple solution approach that we should
have a convincing answer to.

Tim

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 20 Nov 2003 04:29:32 +0900

Ralph Droms;

> This issue has never been found to be a problem DHCPv4.

There is no such thing as stateless autoconf of IPv4.

> The appropriate

You mean you will have to develop yet another standard for yet
another protocol extension to get DHCPv6(-lite or whatever) work?

> assignment.  What evidence do we have the "DHCP storm" will suddenly become

In addition to a "stateless" cause, introduction of multicast, for
example, may casue the storm.

> If well-known addresses are such a good idea, why haven't we adopted them

Because of a lot of misunderstandings on anycast, as demonstrated by
RFC1546, David, Bill, Mark and others, for example, that anycast
could have provided robustness, which promote unnecessarily complex
configuration (e.g. having servers sharing an address in a single
subnet is not a useful configuration), which is implies complex
operations.

							Masataka Ohta

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 20 Nov 2003 00:53:49 +0100

> assignment.  What evidence do we have the "DHCP storm" will suddenly 

I find it surprising that this problem has never come up in IPv4. In 
IPv6 it could potentially be worse as hosts already have an address so 
the DHCP traffic can get in the way of real traffic, unlike with IPv4.

>> For this reason, and because running the DHCP(lite) service results 
>> in additional operational complexity and security risks on both the 
>> together with RFC 2462 IPv6 address configuration.

> experience.

Disagree. We need DNS configuration in IPv6 yesterday. Waiting for 
DHCPv6lite specs, then implementations and finally operational 
experience and THEN find out that there is indeed a problem and start 
work on other mechanisms will take too much time.

Besides, the question isn't whether DHCP can function well. I'm sure it 
can. The question is whether people who have otherwise no need for DHCP 
should be made to use it by not making alternative ways to configure 
DNS resolver addresses available.

> Based on the existing implementations of stateless DHCPv6, I

As long as everything works there is just the additinal delay of having 
to wait for DHCP to complete. This should be pretty fast in most 
circumstances. But if it _doesn't_ work then debugging is going to be 
very inconvenient because there are now two protocols involved in 
configuring hosts when they come online. And any open ports add to the 
security risks.

>> the actual arguments, as the discussion has long since deteriorated 
>> to kindergarten level: "Would you want 200 million devices to be 
>> shipped with the DNS of your organization burned into ROM?"

> If well-known addresses are such a good idea, why haven't we adopted 

Because IPv4 doesn't have a mechanism similar to RFC 2462 for address 
discovery/creation. So DNS configuration has always been something that 
went along with address discovery (= manual configuration, PPP and 
DHCP).

> to warrant the use of well known addresses or the development of an

But do you agree that the fact that many people don't want to run 
DHCPv6 is sufficient reason?

Iljitsch van Beijnum

---

From: Ted Lemon <[email-masked]>
Date: Wed, 19 Nov 2003 23:27:55 -0600

> the DHCP traffic can get in the way of real traffic, unlike with IPv4.

Could you explain what you mean here?   This doesn't make any sense to 
me.   The transport model for DHCPv4 and DHCPv6 are virtually 
identical, so I'm having trouble understanding what the distinction is 
that you're making.   I don't think the presence of a link-local 
address in IPv6 makes any difference, and I don't see how, in the 
stateless case, the address acquired from stateless addrconf makes any 
difference, since the DHCPv6 client still has to talk to the relay 
agent.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 20 Nov 2003 13:00:04 +0100

On 20-nov-03, at 6:27, Ted Lemon wrote:

>> IPv6 it could potentially be worse as hosts already have an address 
>> so the DHCP traffic can get in the way of real traffic, unlike with 
>> IPv4.

> that you're making.

The difference is that with IPv4, a host is unable to send data before 
completing DHCP negotiation, as it doesn't have an address yet. This 
isn't necessarily the case with IPv6 as hosts will configure an address 
for themselves based on router advertisements. So DHCP traffic and 
"regular" traffic may get in eachother's way when a bunch of hosts 
become online at the same time.

.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Ted Lemon <[email-masked]>
Date: Wed, 19 Nov 2003 23:27:55 -0600

---

From: Ted Lemon <[email-masked]>
Date: Thu, 20 Nov 2003 10:13:33 -0600

On Nov 20, 2003, at 6:00 AM, Iljitsch van Beijnum wrote:
> isn't necessarily the case with IPv6 as hosts will configure an 
> address for themselves based on router advertisements. So DHCP traffic 
> and "regular" traffic may get in eachother's way when a bunch of hosts 

So you're talking about the case where you're doing stateless addrconf 
and DHCPv6 to get DNS info?   I still don't get what you mean - how is 
DHCP traffic going to get in the way of "regular" traffic or vice 
versa?

.