Re: [Snac] I-D Action: draft-ietf-snac-simple-00.txt

[Esko Dijk <[e-mail]>]

What about the case where DHCPv6-PD is available, but the stub router doesn’t get the desired prefix length or encounters some error in the process?
In that exceptional case it still MAY allocate a prefix out of its ULA prefix.

Depending on the reader, “is available” and “works for me” can be different things.

Esko

From: Snac <[e-mail]> On Behalf Of Ted Lemon
Sent: Monday, February 20, 2023 13:08
To: Florian Obser <[e-mail]>
Cc: [e-mail]
Subject: Re: [Snac] I-D Action: draft-ietf-snac-simple-00.txt

Yup, good catch. Thanks!

On Mon, 20 Feb 2023 at 07:06, Florian Obser <[e-mail]<mailto:[e-mail]>> wrote:

5.2.2 states:
|   If IPv6 prefix delegation is available, which implies that IPv6
|   service is also available on the infrastructure link, then the stub
|   router MAY use IPv6 prefix delegation to acquire a prefix to
|   advertise on the stub network, rather than allocating one out of its
|   ULA prefix.

and 5.2.3:
|   Therefore, when DHCPv6-PD is available, the stub router MUST use DHCPv6
|   PD rather than its own prefix.

That's contradictory, I suppose 5.2.2 should say:
|   If IPv6 prefix delegation is available, which implies that IPv6
|   service is also available on the infrastructure link, then the stub
|   router MUST use IPv6 prefix delegation to acquire a prefix to
|   advertise on the stub network, rather than allocating one out of its
|   ULA prefix.

Or maybe just drop the last paragraph from 5.2.2 entirely.

--
In my defence, I have been left unsupervised.

--
Snac mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/snac