Re: Adoption Call for <draft-troan-6man-universal-ra-option>

[Brian E Carpenter <[e-mail]>]

On 23-Sep-21 21:43, Vasilenko Eduard wrote:
> Hi Brian,
> Please, give an example of the network where the router is missing.

It's sufficient that the ISP link is down. In that case any source
of external config is missing, so all DHCPv6 can provide is default
info, which RA does perfectly well.

> And if you would manage to find the one then why LLA would be not enough?

Well, one reason is that local browser activity becomes impossible (see
draft-carpenter-6man-rfc6874bis), whereas browsers work perfectly well
with ULA. But yes, that is precisely the argument for the LL part of SLAAC.

> 
> DHCP is not possible to make redundant - market would not agree. Technically it may be possible.

Indeed. I don't seriously propose that; it's an academic observation about
the difference in nature between SLAAC/RA and DHCPv6.

   Brian

> Eduard
> -----Original Message-----
> From: Brian E Carpenter [mailto:[e-mail]] 
> Sent: Wednesday, September 22, 2021 11:54 PM
> To: Vasilenko Eduard <[e-mail]>
> Cc: IPv6 List <[e-mail]>
> Subject: Re: Adoption Call for <draft-troan-6man-universal-ra-option>
> 
> Eduard,
> 
> Obviously, "dentist's office" is not to be taken literally. (Regardless of that, I sincerely hope that if I am in the dentist's chair when there is a power glitch and the ISP link goes down, the equipment will reboot and continue to function without the Internet.)
> 
> The reality is that there will always be stand-alone networks or networks that are intermittently connected, and there will always be unmanaged networks, and there will be self-managing networks. You are only considering a very old-fashioned network which is designed and managed in a top-down way according to a plan. That is not everything.
> 
> SLAAC/RA remains essential as part of the big picture. It's nothing to do with one particular variant of one particular open-source o/s.
> 
> Incidentally, I think we could easily make DHCP redundant. Making SLAAC/RA redundant would be much harder.
> 
> Regards
>    Brian Carpenter
> 
> On 23-Sep-21 01:12, Vasilenko Eduard wrote:
>> Hi Brian,
>> The world has changed 5 years after "the dentist's office scenario" was discussed (by the way - it did happen 2 decades ago). This scenario is outdated now.
>> Because modern "dentist's office" would be mandatorily connected to the Internet by the router that could easily have a local DHCP server.
>> The only absence of DHCP support on the one popular OS is keeping SLAAC alive.
>> Eduard
>> -----Original Message-----
>> From: Brian E Carpenter [mailto:[e-mail]] 
>> Sent: Wednesday, September 22, 2021 12:13 AM
>> To: Vasilenko Eduard <[e-mail]>; Fernando Gont <fernando.gont=[e-mail]>; Lorenzo Colitti <[e-mail]>
>> Cc: IPv6 List <[e-mail]>
>> Subject: Re: Adoption Call for <draft-troan-6man-universal-ra-option>
>>
>> On 21-Sep-21 19:51, Vasilenko Eduard wrote:
>>> Hi Fernando,
>>> The idea "standardize any remaining" looks good but SLAAC and DHCP are so different by architecture that it would not be possible.
>>> Example: DHCP is the choice for all types of businesses because of traceability (billing, troubleshooting, forensic) but SLAAC is silent in principle.
>>> Hence, SLAAC would be stuck in use cases where it is enforced by one company. If not this support SLAAC would be dead by now.
>>
>> Absolutely not. It isn't "enforced by one company". It does exactly what it was designed to do, what we called "the dentist's office scenario" in the early days of IPng design, actually modelled mainly on Appletalk. You can hook a few IPv6 boxes together on a wire and they will start talking to each other using SLAAC and link-local addresses. Add a router with a prefix and they will start talking to the world using SLAAC and RA. DHCPv6 is completely unnecessary until the network reaches a certain level of complexity.
>>
>> The problem area isn't the simultaneous existence of SLAAC/RA and DHCPv6. It's that they don't play well together. Maybe we should restate the problem as "how to make SLAAC/RA play together better". And task a design team with that problem.
>>
>> On 22-Sep-21 07:04, Vasilenko Eduard wrote:
>>
>>> Sorry, I still do not understand why the default router should be on DHCP.
>>> It is just 1 bit: "I am the router on this link". Almost always activated bit. No choice, no parameters. Easy to demarcate between different teams.
>>
>> Well indeed, the value comes when there are several routers (hence RFC8028). If you would like an equivalent of that functionality in DHCPv6, please specify it.
>>
>> (And BTW it is, to my understanding, implemented on the host side. If operators ask for it, no doubt it will appear on the router side.)
>>
>>>
>>> What is really a challenge: the prefix announced through the particular interface ("PIO"). The router should know where is this subnet.
>>> If prefix would be delivered through DHCP then the router should snoop and appoint the appropriate prefix to the interface.
>>> Probably you mean this challenge under the name "default router". 
>>
>> One thing about RFC8028 is that it shows that the phrase "default router" is insufficient, because the host needs to know the best router for a given prefix, not a general default.
>>
>>> I propose snooping on the router side to learn prefixes.
>>> By the way, IPv4 world does not have any automation here (like snooping) - they coordinate it manually between teams.
>>> The situation is more challenging for IPv6 - many prefixes need to be coordinated. Hence, more importance for automation of this process.
>>
>> Indeed. I think that is why we had the MIF WG. Any sign of PVDs in the real world?
>>
>>     Brian
>>