Re: I-D Action: draft-mishra-6man-variable-slaac-01.txt

On Fri, 6 Nov 2020, 02:45 Lorenzo Colitti, <lorenzo=
40google.com@dmarc.ietf.org> wrote:

> So are you suggesting defining a "delegated prefix" RA option that would
> only be correct to use on point-to-point links?
>
> Technically I think that would work and would be quite simple to
> implement. I think someone might have proposed it already, perhaps
> Alexandre?
>
> I think the downsides are a) we already have something that does this
> (DHCPv6 PD), and b) if such an option were ever to be sent on a
> non-point-to-point link, it would cause havoc.
>

I worked on a production deployment of PD back in 2010 and then when I
moved to another city was an end-user of it for the next 8 years. IPv6
enabled became enabled by default on new customer connections about a year
after the 2010 deployment.

I still keep in contact with people there, there are no reported PD
"nightmares". It just worked.

I'd also expect to have heard about PD nightmares on either the 6man or
v6ops mailing lists.

The first time I've even heard the term "PD nightmare" is below.

> On Thu, Nov 5, 2020 at 9:15 AM Ca By <cb.list6@gmail.com> wrote:
>
>>
>>
>> On Wed, Nov 4, 2020 at 2:37 PM Brian E Carpenter <
>> brian.e.carpenter@gmail.com> wrote:
>>
>>> On 05-Nov-20 04:45, Ca By wrote:
>>> >
>>> >
>>> > On Wed, Nov 4, 2020 at 12:52 AM Lorenzo Colitti <lorenzo=
>>> 40google.com@dmarc.ietf.org <mailto:40google.com@dmarc.ietf.org>> wrote:
>>> >
>>> >     On Tue, Nov 3, 2020 at 4:27 PM Gyan Mishra <hayabusagsm@gmail.com
>>> <mailto:hayabusagsm@gmail.com>> wrote:
>>> >
>>> >         It's hard to see why this draft is needed anyway. All that is
>>> needed
>>> >
>>> >             is to remove the "64 bit" statement from the addressing
>>> architecture,
>>> >             which the WG has consistently failed to reach consensus
>>> about.
>>> >
>>> >
>>> >             Gyan>  This topic has come up many times over the years in
>>> heated debate and this is another instance of that.  Agreed.  However, what
>>> makes this instance different is that we have a major problem to be solved
>>> with 4G  &  now as 5G is rolled out, segmentation is of utmost importance.
>>> I think in the past we have not had a major problem to be solved and so
>>> this change being proposed did not gain traction,  but now as 5G becomes
>>> the "norm" as it will compete directly with broadband that customers will
>>> start using 5G in SOHO as well as other environments.   This is a major
>>> issue that has come up with the ramp up for 5G IPv6 only deployments.
>>> >
>>> >
>>> >     There is already a solution to this: use DHCPv6 PD on 5G networks.
>>> It's been supported since 3GPP release 10 several years ago.
>>> >
>>> >
>>> > Has any mobile provider deployed dhcpv6 pd?
>>> >
>>> > Perhaps the mobile providers have seen what an operational nightmare
>>> dhcpv6 pd is and... are like nope.
>>>
>>> Perhaps that needs to be documented over in v6ops.
>>>
>>> > I am in favor of the ietf opening their eyes to a better solution.
>>> >
>>> > Rfc7278 is universally deployed because it is easy.
>>>
>>> As far as I can tell that is no use for the case of routed network
>>> connected to a hotspot, since there is still only one /64 prefix.
>>>
>>> > Can we do better (more /64s) and easy ?
>>>
>>> You mean multiple /64s for a single mobile device? Rather than fixing
>>> 3GPP to support shorter prefixes, which seems simpler.
>>>
>>>     Brian
>>
>>
>> Mobile providers have not deployed dhcp pd in the last 10 years.
>>
>> As a mobile provider, my bet is the next 10 years may be no better.
>>
>> Yet, rfc 7278 is deployed in many places in mobile
>>
>>
>>>
>>> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>