Subject: RE: DHCP failures (was RE: Do you want to have more meetings outsi de US ?)

From: "Jari Arkko" <[email-masked]>
Date: Fri, 3 Aug 2007 23:54:12 +0300

Tony,

> Absolute BS. There is no need for those to communicate. A host needs to be able to get configuration from either mechanism. 

A host needs to get the configuration from either one, yes. If the host can see (e.g. from the RA) what it should do AND both ways are implemented, then we are fine. I worry about cases where network implements just one way and the host the other. Granted, there are ways to deal with these, depending a little bit what one find acceptable - but I think it is a real issue to worry about. If not, please explain.

Jari

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 3 Aug 2007 14:16:59 -0700

Jari Arkko wrote:

> Tony,
> 
> > Absolute BS. There is no need for those to communicate. A host needs
> to be able to get configuration from either mechanism.
> 
> A host needs to get the configuration from either one, yes. If the host
> can see (e.g. from the RA) what it should do AND both ways are
> implemented, then we are fine. I worry about cases where network
> implements just one way and the host the other. Granted, there are ways
> to deal with these, depending a little bit what one find acceptable -
> but I think it is a real issue to worry about. If not, please explain.

It is very unlikely that a device would only implement DHCP, so the only
case to worry about is a device that does not implement DHCP (being a
slightly more complex message exchange), while the network operator insists
that their network only supports that. 

I am not particularly concerned about that case. The reason a manufacturer
would choose to not implement DHCP would be that it is a simple node (light
switch or the like), and the most likely case is that the network operator
that insists on DHCP would not want to allow these trivial devices anyway
because they will not have the UI to deal with the rest of the
DHCP-as-a-trust-anchor scenarios. Multi-purpose OSs will easily do both, and
are most likely to need the ability to switch as they move between
operational environments. 

Get over it and define both mechanisms. Let the operational community decide
what they will and will not support in their deployments. If the device
manufacturers want to deploy into networks that use DHCP-as-a-trust-anchor,
they will have to implement DHCP. If that is not worth their time, the
network needs to support a full set of services via the RA approach that is
more likely in networks without an elite network management staff that likes
to get paid well for their arcane knowledge of a more complex environment. 

I am not saying DHCP is wrong, just that forcing a one-size-fits-all answer
is wrong.

Tony

---

From: Jari Arkko <[email-masked]>
Date: Sat, 04 Aug 2007 20:40:42 +0300

Tony,

> It is very unlikely that a device would only implement DHCP

Hmm. So by "only implement DHCP" I presume that you mean
DHCPv6 + standard RA implementation, right? Reading on...

> so the only
I think we need a better understanding of what the options
are to analyze this fully. From what I can gather, we have
talked about

1. Standard RA only, no DHCP at all (at least on v6 side; but in dual
stack nodes the IPv4 side may provide, for instance, DNS information).

2. Standard RA + DHCP (a couple of variants exist).

3. Standard RA + options for DNS discovery a la draft-jeong.

4. Standard RA but no prefixes + DHCP + extensions for prefix information.

5. DHCP + extensions for prefix information and default routers.

My understanding is that current hosts/networks and majority of
implementations
fall in categories 1 and 2. It would be very, very desirable that a new
solution tolerates such nodes on the other side. For instance, a host
that only does 1 arrives in a network that supports solution 3, 4 or 5,
what happens? If the network only supports 4 or 5, we have a problem.
Similarly, if a host that only does 2 arrives at the network that only
supports 3 we have a problem.

But to get back to your first statement "It is very unlikely that a device
would only implement DHCP", what did you actually mean? Case 2
is less likely than case 1. But from what you wrote afterwards it
seemed like you really meant that case 3 is much more likely to
appear in real-life than case 2. If so, I don't agree...

> operational environments. 

Mumble. I agree about the multi-purpose OSs, on the long term. But we
also need to support the current ones.

> I am not saying DHCP is wrong, just that forcing a one-size-fits-all answer

As I said in my e-mail, having multiple solutions is not out of the
question -- but working out what this means for interoperability
is a requirement. And as always, the case for needing a new
way to implement something has to be made in terms of
tangible benefits.

Jari

---

From: Roger Jorgensen <[email-masked]>
Date: Sun, 5 Aug 2007 00:56:32 +0200 (CEST)

Hi,

think it's my first list and I dont bother to comment on everything, just 
voice my view on this.

I find this entire thread quite amusing in a way. It is so obvious for me 
that IPv6 need some sort of way to distribute other information than what 
RA does today. How it is dont don't really mather. DHCPv6 is one way, 
another probably smoother is to include an option in the RA packet to 
fetch more information from another source.

Probably todo both are the best path forward. However whatever is done the 
first thing to decide is what has the highest priority. RA or DHCPv6 
information, what happen if there are more than one RA or one DHCPv6 
server on the network?

I guess the current DHCP and RA handle the multiply option so whats left 
are to decide which one of them a client should give the highest priority. 
An easy way out are maybe to make it mandatory for everything to have RA 
for working, that means DHCPv6 has to provide RA information, and maybe RA 
also should have a flag that tell the client to listen to DHCP information 
instead... then everyone have their tool and everything will just work :)

... I guess you should also be able to on the client side to as a option 
somewhere well hidden to choice what you prefer, RA or DHCPv6...

But what bother me a bit is that RA are a deep down hidden thing in the 
Network stack, it just exist. Bbut DHCP is a client<>server thing, some 
layers further up in the network stack...

-- 

------------------------------
Roger Jorgensen              | - ROJO9-RIPE  - RJ85P-NORID
[email-masked]           | - IPv6 is The Key!
-------------------------------------------------------