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

[Ole Troan <[e-mail]>]

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

This issue isn’t going away, but let’s hear what the working group has to say.

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

I think this is complicated enough that it would be useful to have other implementors having a go at it. That’s probably the only way we can ensure that the spec is implementable, unambiguous and results in deterministic behaviour.

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

An RA without a PIO, with M-flag set is a perfectly acceptable way of operating the network.
One obvious solution would be to move the P-flag out of the PIO to the RA. It’s connection with the PIO is somewhat arguable anyway.
(And it would give your implementation an experimental flag to use)


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

This has to be made clear in the draft. But I think frequently enough this is a requirement. For a network where mDNS previously worked, the introduction of this mechanism broke all the hosts that supports it, doesn’t seem like an acceptable outcome.
Either an applicability statement that this mechanism cannot be used on links where some sort of on-link discovery mechanism is used (how would you even know), or a solution for how it could be done.

Best regards,
Ole