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

[Mark Smith <[e-mail]>]

On Wed, 22 Sep 2021, 07:14 Brian E Carpenter, <[e-mail]>
wrote:

> 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.
>


Can't find Eduard's original, so I'll comment here.

DHCPv6 and DHCPv4 were never designed for billing or forensic uses.

DHCP of both flavours does not record IP addresses in use.

DHCPv4 doesn't record manually configured IPv4 addresses. DHCPv6 doesn't
record manually configured IPv6 addresses or link-local addresses.

The only thing DHCP keeps is a database of DHCP clients.

If you want address traceability, you need a solution that works regardless
of how IPv6 addresses are configured or generated, be it manually, via
SLAAC or via DHCPv6.

Regards,
Mark.


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