Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)

[Victor Kuarsingh <[e-mail]>]

On Mon, Nov 13, 2017 at 9:29 AM, Fernando Gont <[e-mail]> wrote:
> On 11/13/2017 10:17 PM, Victor Kuarsingh wrote:
>> On Mon, Nov 13, 2017 at 8:51 AM, Fernando Gont <[e-mail]> wrote:
>>> On 11/13/2017 09:35 PM, Victor Kuarsingh wrote:
>>>> On Mon, Nov 13, 2017 at 8:20 AM, Fernando Gont <[e-mail]> wrote:
>>>>> On 11/13/2017 07:14 PM, Lorenzo Colitti wrote:
>>>>>> On Mon, Nov 13, 2017 at 6:21 PM, Fernando Gont <[e-mail]
>>>>>> <mailto:[e-mail]>> wrote:
>>>>>>
>>>>>>     >From a operational point of view, one would wonder why pursue this path
>>>>>>     as opposed to e.g. do DHCPv6
>>>>>>
>>>>>>
>>>>>> As for DHCPv6 specifically, one reason is that DHCPv6-only networks are
>>>>>> not recommended by the IETF. RFC 7934.
>>>>>
>>>>> Yes, sorry: I meant DHCPv6-PD.
>>>>>
>>>>> RFC7934:
>>>>>
>>>>>     Due to the drawbacks imposed by requiring explicit requests for
>>>>>     address space (see Section 4), it is RECOMMENDED that the network
>>>>>     give the host the ability to use new addresses without requiring
>>>>>     explicit requests.  This can be achieved either by allowing the host
>>>>>     to form new addresses autonomously (e.g., via SLAAC) or by providing
>>>>>     the host with a dedicated /64 prefix.  The prefix MAY be provided
>>>>>     using DHCPv6 PD, SLAAC with per-device VLANs, or any other means.
>>>>>
>>>>> Therefore, why re-invent PD in SLAAC?
>>>>
>>>> PD is quite vast, and this draft describes a specific set of use
>>>> cases.  It does not seem like a re-invention of PD in SLACC to me.
>>>
>>> Again: Why not use DHCPv6-PD?
>>>
>>
>> I would leave this up to the operators to decide.
>
> We are the ones trying to make SLAAC stateful, contributing to IPv6
> automatic configuration complexity, and apparent lack of coherence with
> respect to which protocol supports both, and why we e.g. disregard the
> work of other WGs (e.g. dhc).

I don't see how this work has any impact on what was done in DHC and
disregards it.  We potentially conflating things here?

Much in the same way RFC8106 (DNS info in RAs) does not disregard
DHCPv6 since it too can offer DNS information.

>
> If you want to *partially* duplicate functionality in another protocol,
> please provide a rationale, or don't.

Same point as above.  Some apparent duplication may exist, but these
are also two different deployment models. There are reasons why
operators choose one or the other model.  Telling them to use a
different model is not a valid rebuttal in my mind.

>
>
>
>> They are designing
>> their network and know their requirements best.
>
> Exactly: nobody specified the requirements, or said why DHCPv6-PD
> doesn't fullfill them.

What if operator does not have a DHCPv6 service for that access
network? (not saying this was driver for draft, but this is one
example).  Adding in a robust DHCPv6 service is not always trivial, so
if an operator is desiring to have this (/64 per host) capability,
while potentially keeping their service deployment framework SLACC,
why are we objecting to it?  SLAAC is a viable model to use, and the
draft describes the reasons for wanting a /64 per host.  So it seems
clear to me.

To exemplify, (maybe too far out of context),

If I asked for an extension to IS-IS for my deployment, and you told
me to use OSPF because that option was already there, my response
would be - "I am not using OSPF".

>
>
>
>> There are many factors the weigh into why operators make certain
>> decisions.  There are circumstances were DHCPv6-PD would be quite
>> valid, and others, as described in the draft, where the methods
>> described are desirable.  I don't think there is any one way to build
>> a network (I am yet to have built two that look exactly the same given
>> different input requirements).
>
> You still have not answered my question.

The operator has chosen to use a SLACC model, they need/want the
robustness/capability from a /64 per host.  So, if that's the case,
what DHCPv6 has to offer is not relevant   to what the operator would
need in this case.  A direct quote form the draft seems to also show
one of the reasons (others reasons can exist or may exist in future)

"To not exclude any known IPv6
   implementations, IPv6 SLAAC based subscriber and address management
   is the recommended technology to reach highest percentage of
   connected IPv6 devices on a provider managed shared network service."



regards,

Victor K



>
> --
> Fernando Gont
> SI6 Networks
> e-mail: [e-mail]
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>