RE: Adoption call for <draft-pref64folks-6man-ra-pref64-02>

["Templin (US), Fred L" <[e-mail]>]

Hi Sander,

See below for responses:

>> You may be interested to know that there is a proposal for combining IPv6ND
>> and DHCPv6 into a single unified service:
>> 
>> https://datatracker.ietf.org/doc/draft-templin-6man-dhcpv6-ndopt/
>> 
>> It works by having IPv6ND RS/RA messages include an embedded DHCPv6
>> message. So, all messages on the wire are RS/RA, but DHCPv6 messages
>> are carried as payload. It is backwards-compatible and requires only the
>> standardization of a single new IPv6ND option. It would also eliminate
>> the need to clone existing DHCPv6 options as new IPv6ND options and
>> vice-versa. Does it satisfy the requirements?
>
> Not completely. I know that Lorenzo wants to push new options/values whenever the network wants the clients to
> update their settings, and this seems to require the client to send a new RS after it receives an RA with the Reconfigure
> option. At that point we're back at normal DHCPv6 behaviour, just with an extra layer of encapsulation. To make this
> useful for both Push (RA) and Pull (DHCPv6) scenarios there is a need to include DHCPv6 options in unsolicited
> multicast RA messages as well.

Push behavior can be accomplished by having the router's RA include an unsolicited
DHCPv6 Reply message, i.e., as if a client had issued an Information-Request. The
Reply would include any stateless info the DHCPv6 service is configured to include.

> I don't see the need to replace stateful DHCPv6 with RA options, but I do see the wish to use RA in the same way that
> stateless DHCPv6 is used. What you describe has almost exactly the same behaviour as a client that sends a DHCPv6
> Solicit without waiting for the first RA to arrive. What your proposal does is:
>
> Client: send RS with DHCPv6 Solicit inside it
> Router: extract DHCPv6 message from RS
> Router: relay DHCPv6 message
> Router: wait for DHCPv6 Reply to come back
> Router: combine RA and DHCPv6 Reply
> Client: receive RA and DHCPv6 Reply

Right - the relaying process is per "Lightweight DHCPv6 Relay Agent (LDRA)" as
specified in RFC6221.

> Combining the RA and DHCPv6 messages means that the client will only get a reply when the slowest of the two is
> completed, which will usually mean that the RA is delayed to wait for the DHCPv6 reply.

I don't know of anything in RFC4861 that guarantees fast delivery of RA responses
to RSes. Plus, the client would include the DHCPv6 option only in RS messages that
need to explicitly request DHCPv6 information meaning that the client would be
willing to wait for a reply.

> It also means that the
> router has to keep more state while waiting for DHCPv6 to complete. Normal DHCPv6 relaying can be implemented
> stateless.

No, that is not true. The router does not need to maintain state while the
DHCPv6 service is processing the message. The router is simply a stateless
LDRA relay agent.

> I'd rather see the client send an RS and a DHCPv6 Solicit in parallel. It can then receive the RA as quickly as possible.
> So for stateful or per-client specific configuration I think the existing DHCPv6 mechanisms works better than
> combining it with RA as you propose.

Again, RFC4861 offers no guarantee of timely delivery of RA responses to RSes
and the DHCPv6 process is not going to take forever - certainly no more than a
few 10's of msecs. But, if a faster response is somehow desired the client can
send two RS messages; one with a DHCPv6 option and one without.

Thanks - Fred

> What I would prefer to see is to be able to include all the generic (non client-specific) options in the RA. There are
> all kinds of options that could benefit from this: DNS options in RA are an obvious example, because they already
> have an RA specific option. But that could be extended to much more options, like the DS-Lite AFTR, MAP-E and
> MAP-T mappings, timezone info, NTP servers, etc. It shouldn't be necessary that every option is defined multiple
> times like RFC7710 does. Such a mapping should be there by default.