Subject: [savi] DHCP States

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 21 Jul 2010 12:14:33 -0400

In reviewing the savi dhcp draft, I realized that I did not understand 
what the detection state is for.
As far as I can tell, the live state is triggered by receiving a reply 
from the DHCP server.  at that point, the IP address is authoritatively 
assigned to the client.  If some other device tries to claim that IP 
address after that, too bad.  The address is authoritatively bound.

It looks like removing this state would save the SAVI device from 
needing to generate probes, and would simplify the state machine, and 
reduce error cases.

Am I missing something important?

Yours,
Joel

---

From: "Guang Yao" <[email-masked]>
Date: Thu, 22 Jul 2010 08:30:51 +0800

Hi, Joel

In RFC3315, it reads
" The client _SHOULD_ perform duplicate address detection [17] on each of
   the addresses in any IAs it receives in the Reply message before
   using that address for traffic.  If any of the addresses are found to
   be in use on the link, the client sends a Decline message to the
   server as described in section 18.1.7. "

And in RFC4862, it reads
" Duplicate Address Detection MUST be performed on all unicast
   addresses prior to assigning them to an interface, regardless of
   whether they are obtained through stateless autoconfiguration,
   DHCPv6, or manual configuration, with the following exceptions:"

>From these words, we can infer that DHCP server may possibly assign a
duplicate address.

Actually, if stateless and DHCP are both allowed in a network, what will
happen if DHCP server assigns an address already assigned by slaac?
I don't think it is reasonable to bind the address with the DHCP client. 

Best regards,
Guang

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Joel
> M. Halpern
> Sent: Thursday, July 22, 2010 12:15 AM
> To: SAVI Mailing List
> Subject: [savi] DHCP States
> 
> _______________________________________________
> savi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/savi

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 21 Jul 2010 21:14:58 -0400

As far as I can tell, if you are going to allow stateless address 
assignment on the network, there is no poiint in using DHCPv6 for 
address assignment.  The DHCP server can not know what addresses are 
assigned.  So all sorts o contortions have to be jumped through.
It seems much simpler to say to folks, if you want to have a hope of 
securing the net, run it one way or the other, but not both.

As a minor point. RFC 4862 is only about SLAAC.  It does not update 
3315.  As far as I can tell, 4862 as written assumes that some other 
document mandates the DAD be run with DHCPv6 based address assignment. 
That is a reasonable thing to mandate.  But the document doesn't do so. 
  And I presume that there was a reason that 3315 wrote it as a SHOULD 
rather than a MUST.  (I rather expect Thomas to pipe up somewhere here.)

But even if it does mandate it, and even if in a purely architectural 
sense one could allow both to be used, securing the combination is 
almost meaningless.  So I would really like to understand why it is 
important that SAVI allow for both to be used, on the same prefix, on 
the same link.

Yours,
Joel

PS: If we really have to support them both, then getting the LIVE and 
DETECTION states, and all possible transitions, right is going to take 
significantly more work.

---

From: "Guang Yao" <[email-masked]>
Date: Thu, 22 Jul 2010 10:19:45 +0800

I agree that from the perspective of management, allowing only one
assignment method will be convenient. Actually, in DHCP document, we explain
that detection state can be omitted by configuration, if there is no
possible collision in address assignment.

However, there is no such an assumption in SAVI. And it is clear that both
can be used in the same network. Should we say, savi doesn't support such a
scenario, please disable one of them? 

In Tsinghua, multiple address assignment methods are allowed. Slaac is
allowed to configure general address, and DHCP is used to assign special
address (IVI address, refer to
http://tools.ietf.org/html/draft-xli-behave-ivi-00). 

If folks all agree that savi is not expected to handle possible collision
when multiple address assignment methods are used (not only DHCP and slaac,
but also manually configuration, and possibly something new), we can make a
concession to omit this state. Just make this point clear in Charter and
framework doc.

Best regards,
Guang

Joel
> M. Halpern
> Sent: Thursday, July 22, 2010 9:15 AM
> To: Guang Yao
> Cc: 'SAVI Mailing List'
> Subject: Re: [savi] DHCP States
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 21 Jul 2010 22:39:03 -0400

My personal opinion is that we should indeed specify that SAVI does not 
support mixed modes.
You refer to the case of some nodes having manually configured 
addresses.  If those nodes are down, then there is nothing SAVI can do 
to prevent some other node from pre-empting those addresses, and 
producing errors for the host with the manually configured addresses.

Manual configuration plus DHCP can, in a non-SAVI sense, be made 
workable, since all that is required is that the DHCP server be 
configured with the range of addresses that the operator will be 
manually configuring.  But how the SAVI devices can know when such 
claims are legitimate, and when they are not, and how SAVI can properly 
enforce them, is beyond me.

Support for expired internet drafts that have not been adopted by the 
community is clearly not a requirement for this working group.  Hence I 
am still left confused as to what combined cases savi needs to support.

Yours,
Joel M. Halpern

---

From: "Guang Yao" <[email-masked]>
Date: Thu, 22 Jul 2010 11:05:11 +0800

> My personal opinion is that we should indeed specify that SAVI does 
> not support mixed modes.

It is left to the decision of chairs. I'm personally not on the side of
supporting this point.

It is a trade-off between universality and complexity.

Best regards,
Guang

Joel
> M. Halpern
> Sent: Thursday, July 22, 2010 10:39 AM
> To: Guang Yao
> Cc: 'SAVI Mailing List'

---

From: "Jun Bi" <[email-masked]>
Date: Thu, 22 Jul 2010 06:33:34 +0200

Hi Joel,

However, the reality is that the users will use mixed address assignment 
methods (at least for popular address assignment methods), for example, in 
Tsinghua FIT building, it's such an environment. Therefore, I think savi 
needs to handle this situation.
Although it makes thing complicated, but it makes the savi solution more 
deployable.

Best Regars,
Jun Bi

--------------------------------------------------
From: "Joel M. Halpern" <[email-masked]>
Sent: Thursday, July 22, 2010 4:39 AM
To: "Guang Yao" <[email-masked]>
Cc: "'SAVI Mailing List'" <[email-masked]>
Subject: Re: [savi] DHCP States

> You refer to the case of some nodes having manually configured addresses. 
> If those nodes are down, then there is nothing SAVI can do to prevent some 
> other node from pre-empting those addresses, and producing errors for the 
> host with the manually configured addresses.
>
> Manual configuration plus DHCP can, in a non-SAVI sense, be made workable, 
> since all that is required is that the DHCP server be configured with the 
> range of addresses that the operator will be manually configuring.  But 
> how the SAVI devices can know when such claims are legitimate, and when 
> they are not, and how SAVI can properly enforce them, is beyond me.
>
> community is clearly not a requirement for this working group.  Hence I am 
> still left confused as to what combined cases savi needs to support.
>
> Yours,
> Joel M. Halpern
>
> Guang Yao wrote:
>> scenario, please disable one of them? In Tsinghua, multiple address 
>> assignment methods are allowed. Slaac is
>> http://tools.ietf.org/html/draft-xli-behave-ivi-00). If folks all agree 
>> that savi is not expected to handle possible collision

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 22 Jul 2010 07:10:55 +0200 (CEST)

> Although it makes thing complicated, but it makes the savi solution more 

I agree, SAVI should support SLAAC+DHCP combination used on the same 
network. I can see plenty of deployment scenarios where this might be done 
(my home is one of them).

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 22 Jul 2010 09:15:08 -0400

I am aosrry, I am not understanding the answer to the question.
My question was not "do users want to do this?" but rather "why do users 
want to do this?"
Given that at best it works marginally, and that the savi guanratee for 
it is even weaker, what is the benefit to the user of adding DHCP based 
address assignment while still using SLAAC.
One could claim it was for transition, but it is a transition that never 
ends.  So that doesn't work.

Yours,
Joel

Mikael Abrahamsson wrote:
>> However, the reality is that the users will use mixed address 
>> assignment methods (at least for popular address assignment methods), 
>> for example, in Tsinghua FIT building, it's such an environment. 
>> Therefore, I think savi needs to handle this situation.
>> Although it makes thing complicated, but it makes the savi solution 
>> more deployable.
> 
> network. I can see plenty of deployment scenarios where this might be 
> done (my home is one of them).
>

---

From: Eric Levy-Abegnoli <[email-masked]>
Date: Thu, 22 Jul 2010 15:36:05 +0200

Joel M. Halpern a écrit :
> My question was not "do users want to do this?" but rather "why do 
> users want to do this?"
Routers and servers (Web servers, Ntp servers, Certificate servers, dhcp 
servers, etc.) don't get their address thru DHCP, unless someone is 
really looking for trouble. And of course link-locals won't get assigned 
by DHCP neither, although the address scope should prevent colisions 
between address assignment methods..
And then one could allow both assignments method, but restrict by policy 
what one could do with address obtained with one method
So it's fairly un-realistic to expect that when DHCP is going to be 
used, everybody will get its address from there.
 
Best regards
Eric
> Given that at best it works marginally, and that the savi guanratee 
> for it is even weaker, what is the benefit to the user of adding DHCP 
> based address assignment while still using SLAAC.
> One could claim it was for transition, but it is a transition that 
> never ends.  So that doesn't work.
>
> Yours,
> Joel
>
>>> assignment methods (at least for popular address assignment 
>>> methods), for example, in Tsinghua FIT building, it's such an 
>>> environment. Therefore, I think savi needs to handle this situation.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 22 Jul 2010 09:48:46 -0400

Let us separate issues a little:

I am concerned about the behavior within a prefix.  Allowing SLAAC for 
one prefix and DHCP for another works fine.

While I understand the argument for allowing manually configured 
addresses, in conjunction with DHCP or SLAAC, it does not actually work. 
   SAVI can not prevent the hijacking of a manually assigned address 
when the server providing that address is down (which happens.)  Hence, 
attempting to provide a SAVI guarantee on such a network will result in 
a system that does not meet the most obvious and simple need.
Also, in the case of a properly working, properly configured DHCP based 
network with some manual configuration appearing to use SLAAC, one never 
needs the extra states in the state machine, since the DHCP assignment 
will never collide with the manually provisioned assignment.
(The problem of course is that the SAVI devices have no idea which 
addresses can be legitimately claimed by SLAAC, or by whom they can be 
claimed.  So they can not ensure things work right.)

And, for a network that is using arbitrary SLAAC, there is no point in 
allowing some machines to use DHCP based address assignment.  All 
machines support SLAAC.  And the dual assignment is unreliable and error 
prone.

So we have a combination of desirable things that don't work, and 
undesirable things.

Given all that, for networks where one wants SAVI to work reliably, one 
needs to make some choices.  We could try asking the IETF to update RFC 
3315.  Which would help a bit.  Or we can tell people "these are the 
scenarios that the current protocol suite can secure."

But trying to provide a security solution for a combination where it 
does not provide meaningful results is asking for trouble.

Yours,
Joel

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 22 Jul 2010 16:47:01 +0200 (CEST)

On Thu, 22 Jul 2010, Joel M. Halpern wrote:

> My question was not "do users want to do this?" but rather "why do users want 
> to do this?"
> Given that at best it works marginally, and that the savi guanratee for it is 
> even weaker, what is the benefit to the user of adding DHCP based address 
> assignment while still using SLAAC.

I'm doing it at home "because I can", because I have devices that don't 
support DHCPv6 so I want them to do SLAAC, but I also want to be able to 
hand out DHCPv6 information, plus I want devices to get DHCPv6 address 
that I then allow PD to.

I think the case should be the opposite, if SAVI won't support this 
deployment scenario then there should be important reason not to. Saying 
that it's not "perfect" (in that case I can make the case that SLAAC 
shouldn't be supported by SAVI at all), doesn't mean it shouldn't be 
supported.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 22 Jul 2010 10:58:58 -0400

You don't need SAVI at home.  I have no objection to your using any 
combination you want to, in your non-SAVI network.  (You may want to 
experiment witsavi, which is laudable.  But that is not a reason to 
support complex experimental setups in the RFC.)

Using DHCP for information other than address assignment is extremely 
valuable, and completely outside our scope.

So I am still trying to understand why a security-sensitive network 
administrator who understands the effects of his tools and hsi not 
trying to run experiments to see how things work would use both SLAAC 
and DHCP for IP address assignment.

Given that allowing that particular combination adds significant 
complication, at the very least I would recommend that we finish the 
basic work without allowing that, and then come back and try to see if 
there is indeed a driver, what the constraints are, and how to make 
something useful for that combination.

Yours,
Joel

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 22 Jul 2010 17:11:38 +0200 (CEST)

> and DHCP for IP address assignment.

A security conscious administrator (or ISP) wouldn't use SLAAC at all, he 
would use DHCP only. I still think SAVI should support all deployment 
models, otherwise we can do away with the SLAAC support as well (at least 
for obtaining address(es)).

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 22 Jul 2010 11:17:48 -0400

While I like the idea of not supporting SLAAC with SAVI, my 
understanding of the objection was that since all devices support SLAAC, 
and not all devices support DHCPv6 address assignment, it follows that 
network administrators may need, in environments where they do not have 
sufficient control over the end devices, to allow SLAAC.

If folks wanted to just say "no SLAAC with SAVI", I would applaud the 
security improvement.  But then, almost all my customers use DHCP.

Yours,
Joel

Mikael Abrahamsson wrote:
> A security conscious administrator (or ISP) wouldn't use SLAAC at all, 
> he would use DHCP only. I still think SAVI should support all deployment 
> models, otherwise we can do away with the SLAAC support as well (at 
> least for obtaining address(es)).
>

---

From: Sam Hartman <[email-masked]>
Date: Thu, 22 Jul 2010 11:46:23 -0400

Is it possible to get DHCPv6 to work with CGAs, HBAs and privacy
addresses?

If not, then besides device support, there are some important V6
situations where DHCP assignment is the wrong technical approach.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 24 Jul 2010 16:22:42 -0400

I am not proposing that we not support SLAAC>  (While tempting, as I 
suspected that is not reasonable, and as you say does not match the 
charter.)
However, the charter does not say that every combination of everything 
must be supported.
I will repeat my question:  What problem for the users are we solving by 
encouratging them to use both DHCP and SLAAC for address assignment for 
the same IPv6 prefix on the same broadcast domain?
If we are not solving a meaningful problem, then we should not do it.

Yours,
Joel

Bi Jun wrote:
> Hi Joel,
> 
> You are proposing a big change on SAVI WG charter (the WG charter 
> requires savi solutions to support all address assignment methods).
> 
> Although personally I agree that SLAAC is not a good address assignment 
> method (need an improvement to enhance the manageability and security), 
> but it has been widely used, so I agree with the charter to support all 
> assignment methods, including mixed environment. It will make the SAVI 
> more widely been used.
> 
> thanks,
> Jun Bi
> 
> Sent: Thursday, July 22, 2010 5:17 PM
> To: "Mikael Abrahamsson" <[email-masked]>
> Cc: "SAVI Mailing List" <[email-masked]>
>> understanding of the objection was that since all devices support 
>> SLAAC, and not all devices support DHCPv6 address assignment, it 
>> follows that network administrators may need, in environments where 
>> they do not have sufficient control over the end devices, to allow SLAAC.
>>
>>>> trying to run experiments to see how things work would use both 
>>>> SLAAC and DHCP for IP address assignment.
>>>
>>> A security conscious administrator (or ISP) wouldn't use SLAAC at 
>>> all, he would use DHCP only. I still think SAVI should support all 
>>> deployment models, otherwise we can do away with the SLAAC support as 
>>> well (at least for obtaining address(es)).
>>>