[IPv6]Re: Working Group Last Call for <draft-ietf-6man-pio-pflag>

[Lorenzo Colitti <[e-mail]>]

On Thu, May 30, 2024 at 6:52 PM Ole Troan <otroan=
[e-mail]> wrote:

> 1) Consequences for the addressing model. While Lorenzo would claim this
> is an operational issue that’s already handled in v6ops. I don’t quite
> agree. It’s the whole community’s responsibility for a responsible
> addressing model.
>

Well, but that's why we have IETF last call: to ensure the whole community
gets to debate the documents that we publish. That definitely happened
here. The points you make were made during the WG discussion and the IETF
last call of the document that describes the deployment model. There was a
lot of discussion on the topic in the various stages of the process, and in
the end rough consensus in the community was to publish the document.


> 2) Interactions with IA_NA, SLAAC on the interface. There’s a lot of
> corner cases here. Do we need a state machine specified? Should we require
> running code before proceeding this? Any implementations already?
>

Do you think the text is unclear about this? It's fairly clearly specified
in section 6.1 and fairly simple.

   - The client needs to maintain a list of every PIO with a nonzero
   preferred lifetime and P=1. If there are any, the client should request and
   review prefixes via DHCPv6 PD.
   - If the client has not seen at least one PIO with P=0, it should not
   ask for addresses via DHCPv6 IA_NA
   - SLAAC is entirely independent from DHCPv6. The client should not run
   SLAAC on any PIO with P=1, and should run it as normal on any prefix with
   P=0 and A=1.

There is running code: at least Android has an implementation. But nobody
can actually ship code until the document progresses or an early allocation
is made. If we want to wait for shipping code before progressing the
document, then the chairs will have to request an early allocation.

3) What about RA without a PIO? Then the P-flag wouldn’t work. Is that a
> valid use case?
>

It doesn't seem a very useful thing to do, since any network that has a
subnet prefix will always want to notify hosts of that prefix using a PIO.
But a network that wants to do this can achieve this effect by sending a
PIO for any prefix with P=1 and with zero lifetimes (or with A=0, L=0).


> 4) What about services that expect hosts to be on the same link? Like
> mDNS. The addresses assigned via this mechanism is on a different link than
> the upstream link. What do we do about that?
>

Just like any deployment where hosts are not on a shared link,
multicast-based services will not work. In many networks this is desirable.
For example, many large enterprise networks block device-to-device
communication entirely, for security reasons.