Subject: Re: [savi] DHCP States

From: "junbi"<[email-masked]>
Date: Sun, 25 Jul 2010 04:47:45 +0800 (CST)

Hi Joel,

By our IPv6 campus network operation experience, there are multiple reasons 
to do mixed. For example, not every one's PC can support dhcpv6 client 
functions now, moreover, not every dhcpv6 client software can interoperate 
with dhcpv6 server.
(we just did an interoperability testing for different clients with 
different server, e.g. visat/win7 are good with win server2008, but linux 
with dibbler client software are not doing good with that server). Then for 
those users, SLAAC is one choice to make them can still use IPv6.

More important, there is no standard track RFC to force operator to use just 
one address assignment in a local link. So people are free to chose the 
assignment methods. Therefore, to make SAVI RFC work in all possible cases, 
I think it should support mixed case (at least the hdcpv6-slaac-mixed is a 
more common case.

Best Regards,
Jun Bi

--------------------------------------------------
From: "Joel M. Halpern" <[email-masked]>
Sent: Saturday, July 24, 2010 10:22 PM
To: "Bi Jun" <[email-masked]>
Cc: "SAVI Mailing List" <[email-masked]>; "Mikael Abrahamsson" 
<[email-masked]>
Subject: Re: [savi] DHCP States

> 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
>>
>> --------------------------------------------------
>> From: "Joel M. Halpern" <[email-masked]>
>> Sent: Thursday, July 22, 2010 5:17 PM
>> To: "Mikael Abrahamsson" <[email-masked]>
>> Cc: "SAVI Mailing List" <[email-masked]>
>> Subject: Re: [savi] DHCP States
>>
>>> 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:
>>>> On Thu, 22 Jul 2010, Joel M. Halpern wrote:
>>>>
>>>>> 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.
>>>>
>>>> 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)).
>>>>
>>> _______________________________________________
>>> savi mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/savi
>>>
>>
> _______________________________________________
> savi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/savi
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 25 Jul 2010 15:16:27 -0400

Two comments on this answer.

1) What you describe does not lead to a need for using both modes.  In
fact, in both this note and the next one, what you describe is why you
need to support SLAAC.  I am not arguing that we should not support
SLAAC.  What I do not understand is why a network that is using SLAAC,
and wants to do SAVI, needs to also do DHCP.

2) As far as I can tell, the use of DHCP with SLAAC for the same prefix,
on the same link, is extremely prone to unexpected results.  The
simplest problem is the pre-hijack where a SLAAC host grabs an address
that DHCP will later attempt to assign.  I do not believe that SAVI can
meet its goals in such an environment.

If we really want to try to do this, we will have to figure out exactly
what corner cases there are, and document all the unexpected results
(the simplest being the pre-us hijack. where SLAAC machines use the DHCP
assigned address ranges.

I am sorry if I do not sound helpful.
Can you articulate why the site administrators, faced with a situation
in which they have to permit SLAAC< nonetheless choose to try to use
DHCP for some devices?  And what you expect SAVI to accomplish in that
environment.

Yours,
Joel

---

From: Fred Baker <[email-masked]>
Date: Sun, 25 Jul 2010 21:36:12 +0200

If I can make a side comment....

I think what we're working with here is the definition of "rough". We have agreed on multiple occasions that there are or will be networks that use DHCPv6, and there are or will be networks that use SLAAC, and there are networks in which both are in use.

I don't believe that further beloaboring the point is worth the effort. If it can be shown that no network will use DHCP, we don't need a DHCP solution. If it can be shown that no network will use SLAAC, we don't need a SLAAC solution. If it can be shown that no network will run both at the same time, they can run in an either/or fashion. None of those things have in fact been shown, and as a result we need both DHCP and SLAAC solutions, and they need to be able to run in a combined fashion on real networks.

Don't mind me, I'm just sitting in the back row in the room. But all this does make me wonder what it means to have "rough consensus".

---

From: "Jun Bi" <[email-masked]>
Date: Mon, 26 Jul 2010 00:56:11 +0200

Hi Jole,

--------------------------------------------------
From: "Joel M. Halpern" <[email-masked]>
Sent: Sunday, July 25, 2010 9:16 PM
To: "junbi" <[email-masked]>; "SAVI Mailing List" <[email-masked]>
Subject: Re: [savi] DHCP States

> that DHCP will later attempt to assign.

Hi Joel,

This is just why we need SAVI for dhcp-slaac mixed network (savi device 
implement both savi-dhcp and savi-slaac). SLAAC host need to be bound by 
savi-slaac solution,
If the slaac address is bound by savi device, then it is legal, and not 
hijacking. If a slaac  host wants to occupy many address in advance, at 
least in our slaac solution and CNGI-CERNET2 deployment, there is a binding 
limit for each port, so the SLAAC host can not attack (there is only server 
collision in the worst case). In our CNGI-CERNET2 savi testing, we have 
tested this case on savi switches, it won't be a problem.

>I do not believe that SAVI can

As I explained in my past emails, it's really not a corner case, it's very 
usual to permit both dhcp and slaac, especially when not every host can have 
its hdcpv6 client interoperate hdcpv6 server today.

> DHCP for some devices?  And what you expect SAVI to accomplish in that

I explained in my past email that why operator has to allow both SLAAC and 
DHCP in his network (one caee is that if I ask a user to only use dhcpv6, if 
his OS can't operate with my hdcpv6 server, e.g., a MAC OS and Linux has 
problem with win 2008 server, then I have to let him use slaac to access 
IPv6). Then to enable SAVI for dhcp-slaac-mixed is very easy. In the 
savi-switch deployed in CNGI-CERNET2, the switch implemented both savi-slaac 
and savi-dhcp solutions, then the operator just type two commend:
#savi enable dhcp snooping
#savi enable slaac snooping
Then everything will works fine. savi-slaac implementation will set up 
binding entry for slaac address, savi-dhcp implementation in the same switch 
will set up binding entry for dhcp address (before a dhcp server assigned 
address bound, we have this additional state "DETECTION" in savi-dhcp state 
machine for the mixed cases).

BTW, for dhcpv6-only networks, typing:
#savi enable dhcp snooping
#savi enable link-local snooping (because the link-local address need to be 
bound, to be used as source address for dhcp request message)

For slaac-only networks, typing:
# #savi enable ndp snooping

---

From: "Jun Bi" <[email-masked]>
Date: Mon, 26 Jul 2010 01:11:04 +0200

> and wants to do SAVI, needs to also do DHCP.

Hi, Joel,

There are 3 scenarios: dhcp-only, slaac-only, and dhcp-slaac-mixed.

My past emails explained why we need dhcp-slaac mixed.
When a network wants to use dhcp, it may still need slaac, then we need to 
support savi for dhcp-slaac mixed.

If a network wants to use slaac, then I don't think it must also need 
dhcpv6.
This case, we call savi-slaac-only. But this doesn't mean we don't need 
savi-dhcp-slaac-mixed network, right?

Best Regards,
Jun Bi

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 26 Jul 2010 08:37:55 +0200 (CEST)

On Sun, 25 Jul 2010, Joel M. Halpern wrote:

> DHCP for some devices?

Because they can.

It's as simple as that.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Fred Baker <[email-masked]>
Date: Mon, 26 Jul 2010 09:21:26 +0200

On Jul 26, 2010, at 8:37 AM, Mikael Abrahamsson wrote:

>> Can you articulate why the site administrators, faced with a situation in which they have to permit SLAAC< nonetheless choose to try to use DHCP for some devices?

Because there are some hosts that they care what they use for an address, but the vast percentage of hosts are not critical to control

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 26 Jul 2010 03:47:30 -0400

Yes, you can run your network with both DHCP and SLAAC.
As far as I can tell, unless one has additional operational constraints 
not defined by the IETF, and these are enforced by the SAVI devices 
(clearly out of scope for theis WG), the operation in this mixed mode 
will work unreliably.  It is somewhat unreliable withotu SAIV< and 
becomes less reliable if you try to use SAVI in conjunction with the 
mixed mode.

It may be that with enough work we can make it work safely in a way that 
is compliant with the existing standards and has understandable effects 
on the users.  But it will take additional work.
As such, I would strongly urge separating the concerns.  Document the 
pure DHCP case first, and then separately figure out what we need to do 
in SAVI devices that are supporting DHCP and SLAAC on the same prefix on 
the same link.

Yours,
Joel

---

From: Fred Baker <[email-masked]>
Date: Mon, 26 Jul 2010 09:51:42 +0200

that may be true. I don't think that means people will stop doing it. We may need to simply specify what cases we have not resolved.

On Jul 26, 2010, at 9:47 AM, Joel M. Halpern wrote:

> As far as I can tell, unless one has additional operational constraints not defined by the IETF, and these are enforced by the SAVI devices (clearly out of scope for theis WG), the operation in this mixed mode will work unreliably.  It is somewhat unreliable withotu SAIV< and becomes less reliable if you try to use SAVI in conjunction with the mixed mode.
> 
> It may be that with enough work we can make it work safely in a way that is compliant with the existing standards and has understandable effects on the users.  But it will take additional work.
> As such, I would strongly urge separating the concerns.  Document the pure DHCP case first, and then separately figure out what we need to do in SAVI devices that are supporting DHCP and SLAAC on the same prefix on the same link.
> 
> Yours,
> Joel
> 

http://www.ipinc.net/IPv4.GIF

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 26 Jul 2010 10:08:17 +0200 (CEST)

> that may be true. I don't think that means people will stop doing it. We may need to simply specify what cases we have not resolved.

I agree. Make best-effort implementation with a list of caveats where SAVI 
doesn't solve things perfectly.

As far as I can see, SLAAC wasn't designed with SAVI-like security in mind 
so I'm pretty sure SLAAC can't be protected 100% by SAVI anyway, so the 
people who want tracability and security will operate with DHCP only.

The people who want SLAAC will have to make do with what's possible, but 
I'm sure this is still better than no protection by SAVI at all.

---

From: Fred Baker <[email-masked]>
Date: Mon, 26 Jul 2010 10:11:40 +0200

On Jul 26, 2010, at 10:08 AM, Mikael Abrahamsson wrote:

> The people who want SLAAC will have to make do with what's possible, but I'm sure this is still better than no protection by SAVI at all.

agreed

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 26 Jul 2010 13:35:23 +0200 (CEST)

> becomes less reliable if you try to use SAVI in conjunction with the 

<http://www.faqs.org/rfcs/rfc4862.html>

end of third paragraph in the introduction:

"... Both stateless address autoconfiguration and DHCPv6 may be used 
simultaneously."