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

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

Hi Mark,

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

We are using the IPv6ND/DHCPv6 service on hosts that are very mobile
(e.g., enterprise mobile devices such as cellphones, airplanes, unmanned
air vehicles, etc.). The code is freely available here:

http://linkupnetworks.org/aero/AERO-OpenVPN-2.0.tgz

Thanks - Fred

> -----Original Message-----
> From: Mark Smith [mailto:[e-mail]]
> Sent: Monday, December 10, 2018 11:29 AM
> To: Sander Steffann <[e-mail]>
> Cc: Templin (US), Fred L <[e-mail]>; Lorenzo Colitti <lorenzo=[e-mail]>; Suresh Krishnan
> <[e-mail]>; 6man WG <[e-mail]>; Fernando Gont <[e-mail]>; 6man Chairs <6man-
> [e-mail]>
> Subject: Re: Adoption call for <draft-pref64folks-6man-ra-pref64-02>
> 
> 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
> > --------------------------------------------------------------------