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

[Mark Smith <[e-mail]>]

On Tue, 11 Dec 2018 at 04:42, Sander Steffann <[e-mail]> wrote:
>
>  Hi Fred,
>
> > 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.
>
> 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.

I don't.

That would mean that to deploy a newly IETF "DHCPv6 option in RA"
option, a new version of router firmware would need to be deployed to
each and every network segment where the hosts want to run the new
"DHCPv6 option in RA" option application.

This would be changing the application/service model from
"applications over the top of the network" - the Internet model, to
"applications within the network" - the traditional PSTN/telephone
network model (i.e. smart network, dumb hosts). Shifting or
replicating DHCPv6 options into RAs would really be that fundamental a
change. We shouldn't have to possibly "upgrade the network", meaning
upgrade routers, to deploy a new application.

The problem with stateless DHCPv6, and DHCP in general is that it was
designed when hosts weren't very mobile. Now they are, so there is a
new requirement that DHCPv6 doesn't satisfy very well. However, I
don't think putting DHCPv6 options in RAs is the answer.


There's been a fairly recent trend to provide access to services over
the Internet regardless of the point of attachment while also also
avoiding the need to update host settings when the host moves using
another method - well known anycast addresses that work to reach the
service (DNS most visibly, however also NTP from Google, Microsoft and
Apple). PCP mentioned earlier also has a well known IANA allocated
anycast address.


Regards,
Mark.




>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
>
> 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. It also means that the router has to keep more state while waiting for DHCPv6 to complete. Normal DHCPv6 relaying can be implemented stateless.
>
> 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.
>
> 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.
>
> Cheers,
> Sander
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------