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

[Gyan Mishra <[e-mail]>]

On Sun, Jan 26, 2020 at 8:41 AM Jared Mauch <[e-mail]> wrote:

>
>
> > On Jan 23, 2020, at 9:08 AM, Fernando Gont <[e-mail]>
> wrote:
> >
> > * DHCPv6 support is not required, and in fact we seem to do our best to
> >  trash DHCPv6 and borrow cool DHCPv6 features into slaac as much as
> >  possible -- which doesn't help the situation.
>
> This for me is an example of one of the problems around IPv6.
>
> The IPv6 solution space includes things like:
>
> * Don’t do DHCPv6, do SLAAC
> ** We forgot to include DNS, so RDNSS
> * Do DHCPv6, don’t do SLAAC
> ** Some hosts won’t do DHCPv6
> ** Not all hardware does DHCPv6-PD properly
> ** Not all software does DHCPv6-PD properly
> ** Not all networks can support DHCPv6-PD
>
> The general discussion for me here is we need to ensure we’re not
> violating rfc1925[1] 2.1 which at times seems to be blame shifted to
> operators or vendors.  While everyone has their weaknesses we need to
> ensure the ecosystem we specify is robust enough.
>
> - Jared
>
> [1] - Yes I know, doesn’t make it any less true though.


    Gyan> Agreed.

The beauty behind SLAAC is that it works “out of the box” PNP like features
makes it very user friendly to initiatally deploy.  However, what’s sitting
under the covers in the black box ends up being an operational nightmare.

See my email reply to the last thread and what boils down to the crux of
the issue.

>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: [phone]

Email: [e-mail]