Re: SLAAC vs DHCPv6 (Re: RFC4941bis: consequences of many addresses for the network)

[Alexandre Petrescu <[e-mail]>]

Le 28/01/2020 à 02:25, Fernando Gont a écrit :
> On 27/1/20 20:36, Brian E Carpenter wrote:
>> On 28-Jan-20 10:44, Fernando Gont wrote:
>>> On 26/1/20 17:47, Brian E Carpenter wrote:
>>>> On 27-Jan-20 09:22, Simon Hobson wrote:
>>>>> Gyan Mishra <[e-mail]> wrote:
>>>>>
>>>>>> The beauty behind SLAAC is that it works “out of the box” PNP like 
>>>>>> features makes it very user friendly to initiatally deploy.
>>>>>
>>>>> Remember that DHCP for IPv4 generally works "out of the box" for 
>>>>> most users. Certainly in the SOHO market, the presence of a built 
>>>>> in, auto-configured, and enabled DHCP server in the route means 
>>>>> that the user just "plugs it in and it works". By the time you get 
>>>>> to a level of network complexity where that isn't the case, then 
>>>>> there is normally a network admin either on the staff or hired n as 
>>>>> needed.
>>>>>
>>>>> If that isn't working reliably for users in the IPv6 world then 
>>>>> that suggests the various components needed haven't reached the 
>>>>> same level of completeness & correctness "mostly" available in the 
>>>>> IPv4 world. It isn't an argument that DHCPv6 "doesn't work".
>>>>
>>>> It's actually a historical accident. At the time that SLAAC was 
>>>> designed, DHCP(v4) wasn't mature and the state of the art in 
>>>> autoconfiguration was Appletalk, Novell IPX, and DECnet Phase IV. It 
>>>> really doesn't matter now. We can't roll the clock back.
>>>
>>> Well, we *could* end the pointless religious battle, mandate both SLAAC
>>> and DHCPv6, and let admins and operators run their networks in whatever
>>> way they please.
>>
>> That still doesn't resolve the issue of the lack of feature 
>> equivalence between RAs and DHCPv6,
> 
> Indeed. At the very least, one would have a DHCPv6 route option.
> 
> So far, IIRC the arguments against this have been that a DHCPv6 server 
> couldn't be ain a good position to tell where packets should be routed. 
> However, a number of proposals recently discussed in this working group 
> have failed that criteria (if it ever existed).
> 
> Folks that need/want to "enforce" policy, should be able to do so. 
> Besides, they should be able to rely on any automatic configuration 
> mechanism rather than having to duplicate the effort in both protocols.
> 
> e,g,-, My ISPs CPE does network configuration (addresses `other info) 
> with both SLAAC and DHCPv6 -- because they have to make sure it works 
> with whatever stuff their users plug.
> 
> Part of the outcome is that while my box does rfc7217+rfc4941, I also 
> configure dhcpv6 addresses, and the dhcpv6 server generates IIDs in a 
> predictable manner.
> 
> 
>> and there would some interesting discussions around which options need 
>> to be MTI. For example, is 
>  > PD mandatory to implement? It would be interesting to see a draft 
> (v6ops, perhaps?). However, I imagine that the constrained node people 
> would have something to say if we changed this to a MUST:
>>
>> "...all hosts SHOULD implement address configuration via DHCPv6." 
>> [RFC8504, section 6.5]
> 
> My understanding is that the constrained node folks already have to 
> deviate a bit from plain IPv6. So I guess that could be worked out.
> 
> It would seem to me the problem here is more of Android than anything else.

It is good to try to identify and describe a problem.

To me, there is indeed a problem of lack of support of DHCPv6 in Android.

This problem is materialized at home, and in cellular networks.

At home, the use of DHCPv6 by my CPE makes that Android gets disconnected.

On cellular, the lack of DHCPv6 in Android makes that chip manufacturer 
does not allow DHCPv6 through for anybody else, including DHCPv6-PD 
which has no equivalency in SLAAC.

These are facets of a problem.

Alex

> 
>