Subject: Combining IPv6 ND and DHCPv6 into a single, unified function

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 20 Nov 2017 21:40:53 +0000

Hello,

IPv6 ND and DHCPv6 have traditionally been thought of as independent functions,
with the requirement that the IPv6 ND RS/RA exchange has to happen first so that
the node can examine the M/O bits to determine whether it can use DHCPv6. As
nearly as I can tell, this two round-trip process (IPv6 RS/RA followed by DHCPv6
Solicit/Reply) is the only argument conceivable against DHCPv6 from a functional
standpoint.

The two round-trip process can add significant delay and waste bandwidth especially
on low-end data links like many aviation wireless links. It can also impart unnecessary
messaging overhead on more robust links during periods of congestion.

This document therefore proposes a unification of IPv6 ND and DHCPv6 where
the two functions work together as if they were one. This is accommodated by
a new IPv6 ND option in RS/RA messages called the "DHCPv6 option". By working
together as one function, IPv6 ND and DHCPv6 can supply requesting nodes with
all link-specific autoconfiguration information and any managed address/prefix
delegations in a single round trip message exchange.

I would ask these discussion lists to consider what is it that you really don't
like about DHCPv6. Maybe you think it is ugly. Maybe you don't like the way
the acronym rolls off your tongue when you speak it. Maybe it has an onerous
stigma of being stateful. But, then I would also ask you to consider what a
replacement would look like. Because, I think any suitable replacement
would have to essentially duplicate what DHCPv6 already does.

Comments?

Fred

-----Original Message-----
From: I-D-Announce [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, November 20, 2017 1:21 PM
To: [email-masked]
Subject: I-D Action: draft-templin-6man-dhcpv6-ndopt-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : The DHCPv6 Option for IPv6 Neighbor Discovery
        Author          : Fred L. Templin
	Filename        : draft-templin-6man-dhcpv6-ndopt-00.txt
	Pages           : 6
	Date            : 2017-11-20

Abstract:
   IPv6 Neighbor Discovery (IPv6ND) specifies a control message set for
   nodes to discover neighbors, routers, prefixes and other services on
   the link.  It also supports a manner of StateLess Address
   AutoConfiguration (SLAAC).  The Dynamic Host Configuration Protocol
   for IPv6 (DHCPv6) specifies a service for the stateful delegation of
   addresses and prefixes.

   Currently, at least two round-trip message exchanges are necessary in
   order to perform the IPv6ND router discovery and DHCPv6 address/
   prefix delegation functions.  This document presents a protocol for
   combining these two round trips into a single round trip by joining
   the two services into a single unified service.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-templin-6man-dhcpv6-ndopt/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-templin-6man-dhcpv6-ndopt-00
https://datatracker.ietf.org/doc/html/draft-templin-6man-dhcpv6-ndopt-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 20 Nov 2017 22:17:41 +0000

Fred:

I'm not so sure that this idea is really needed. You can always start both RS and DHCPv6 at the same time if you always know you want to use DHCPv6?

In section 2, aren't you missing some "pad" octets to "make" the DHCPv6 message (really the IPv6 ND DHCPv6 option) a multiple of 8 octets long (as the "Length" field in the ND header is a multiple of 8). A better design, because there are no DHCPv6 "pad" options, might be:

A) The pad bytes are after the IPv6 ND Length field (your reserved) and depend on the padding needed - these would be 0 octets before the msg-type to make the length work out (so the IPv6 ND DHCPv6 option ends at an 8 octet boundary). When extracting the DHCPv6 message, any first octets that are 0 values would be skipped to find the start of the msg-type (since the DHCPv6 msg-type cannot be 0).

B) Use the 2 reserved octets to specify the real length of the DHCPv6 message. Any octets beyond these are ignored. Alternatively, you could use 1 octet to indicate the number of pad octets (and leave the other octet as reserved).

And, of course the maximum sized DHCPv6 message you can send is 8 * 256 - 4 = 2,044 octets.

Also, for the "DHCPv6 Solicit" message, I think you want to say "DHCPv6 Solicit w/Rapid Commit"? (You mention Rapid Commit only in the Introduction.)

- Bernie

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Templin, Fred L
Sent: Monday, November 20, 2017 4:41 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function

Hello,

IPv6 ND and DHCPv6 have traditionally been thought of as independent functions, with the requirement that the IPv6 ND RS/RA exchange has to happen first so that the node can examine the M/O bits to determine whether it can use DHCPv6. As nearly as I can tell, this two round-trip process (IPv6 RS/RA followed by DHCPv6
Solicit/Reply) is the only argument conceivable against DHCPv6 from a functional standpoint.

The two round-trip process can add significant delay and waste bandwidth especially on low-end data links like many aviation wireless links. It can also impart unnecessary messaging overhead on more robust links during periods of congestion.

This document therefore proposes a unification of IPv6 ND and DHCPv6 where the two functions work together as if they were one. This is accommodated by a new IPv6 ND option in RS/RA messages called the "DHCPv6 option". By working together as one function, IPv6 ND and DHCPv6 can supply requesting nodes with all link-specific autoconfiguration information and any managed address/prefix delegations in a single round trip message exchange.

I would ask these discussion lists to consider what is it that you really don't like about DHCPv6. Maybe you think it is ugly. Maybe you don't like the way the acronym rolls off your tongue when you speak it. Maybe it has an onerous stigma of being stateful. But, then I would also ask you to consider what a replacement would look like. Because, I think any suitable replacement would have to essentially duplicate what DHCPv6 already does.

Comments?

Fred

-----Original Message-----
From: I-D-Announce [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, November 20, 2017 1:21 PM
To: [email-masked]
Subject: I-D Action: draft-templin-6man-dhcpv6-ndopt-00.txt

Abstract:

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 20 Nov 2017 22:38:40 +0000

Hi Bernie,

> From: Bernie Volz (volz) [mailto:[email-masked]]
> Sent: Monday, November 20, 2017 2:18 PM
> To: Templin, Fred L <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: Combining IPv6 ND and DHCPv6 into a single, unified function
> 
> Fred:
> 

I only want a (single request, single reply) message exchange; I don't want to have
to start multiple exchanges even if in parallel. I am worried about links that have
bandwidth well south of 1Mbps - some as low as 32Kbps. 

> In section 2, aren't you missing some "pad" octets to "make" the DHCPv6 message (really the IPv6 ND DHCPv6 option) a multiple of 8
> octets long (as the "Length" field in the ND header is a multiple of 8). A better design, because there are no DHCPv6 "pad" options,
> might be:
> 
> A) The pad bytes are after the IPv6 ND Length field (your reserved) and depend on the padding needed - these would be 0 octets
> before the msg-type to make the length work out (so the IPv6 ND DHCPv6 option ends at an 8 octet boundary). When extracting the
> DHCPv6 message, any first octets that are 0 values would be skipped to find the start of the msg-type (since the DHCPv6 msg-type
> cannot be 0).

Yes, that works. We could also steal three bits from the "Reserved" field to encode a
"pad length" value. The value would tell how many trailing zero octets are present.

> B) Use the 2 reserved octets to specify the real length of the DHCPv6 message. Any octets beyond these are ignored. Alternatively,
> you could use 1 octet to indicate the number of pad octets (and leave the other octet as reserved).

Right, I like using three bits from the Reserved field to encode the number of
pad octets. Good catch.

> And, of course the maximum sized DHCPv6 message you can send is 8 * 256 - 4 = 2,044 octets.

Yes, that should be enough but should be noted. Thanks.

> Also, for the "DHCPv6 Solicit" message, I think you want to say "DHCPv6 Solicit w/Rapid Commit"? (You mention Rapid Commit only in

Yes. Rapid Commit is assumed everywhere but should be explicitly stated.

Thanks - Fred
 
> IPv6 ND and DHCPv6 have traditionally been thought of as independent functions, with the requirement that the IPv6 ND RS/RA
> exchange has to happen first so that the node can examine the M/O bits to determine whether it can use DHCPv6. As nearly as I can
> tell, this two round-trip process (IPv6 RS/RA followed by DHCPv6
> The two round-trip process can add significant delay and waste bandwidth especially on low-end data links like many aviation wireless
> links. It can also impart unnecessary messaging overhead on more robust links during periods of congestion.
> 
> This document therefore proposes a unification of IPv6 ND and DHCPv6 where the two functions work together as if they were one.
> This is accommodated by a new IPv6 ND option in RS/RA messages called the "DHCPv6 option". By working together as one function,
> IPv6 ND and DHCPv6 can supply requesting nodes with all link-specific autoconfiguration information and any managed address/prefix
> I would ask these discussion lists to consider what is it that you really don't like about DHCPv6. Maybe you think it is ugly. Maybe you
> don't like the way the acronym rolls off your tongue when you speak it. Maybe it has an onerous stigma of being stateful. But, then I
> would also ask you to consider what a replacement would look like. Because, I think any suitable replacement would have to
> essentially duplicate what DHCPv6 already does.
> 
> Comments?
> 
> Fred
> 
>

---

From: Sander Steffann <[email-masked]>
Date: Tue, 21 Nov 2017 00:34:32 +0100

Hi,

> delegations in a single round trip message exchange.

Interesting way of doing this. I have thought about combining ND and DHCPv6 before, but more as a different distribution mechanism: ND for pushing options to all clients on the network, and DHCPv6 for clients requesting specific options for themselves. Just to make it possible to use both mechanisms for all options (MAP/DSLite/etc options in RA would be nice).

What you are doing is another way of looking at it. If I understand correctly you're basically keeping the full functionality of DHCPv6 but using RS/RA as a transport instead of UDP. I wonder what the speed benefit of that would be in practice. Also compared to "impatient" systems that send out DHCPv6 a request before even receiving an RA.

> would have to essentially duplicate what DHCPv6 already does.

In my opinion DHCPv6 is fine. I implemented a server and it is a *lot* cleaner to implement than DHCPv4. Just plain UDP on link-local and multicast sockets :)  Especially the stateless version is very easy to implement. It's not the ultimate configuration protocol, and for certain things distributing information via RA is a much better fit to the way the network is run. But DHCPv6 has its place and its role, and in certain environments (DHCPv6-PD in ISP networks, DHCPv6 in enterprise etc) it does what the network and system operators need.

The main problem with DHCPv6 as an operator has been dealing with DUIDs when the link-layer address in the DUID is based on a different interface than the interface sending the DHCPv6 request. Mostly because the requesting interface's MAC address has always been used with DHCPv4 and is often printed on the outside of the device. But these days LDRA and DHCPv6 relays can tell the DHCPv6 server what the MAC address of the requesting interface was, and we can use that to identify the client (in addition to its DUID). With vendors starting to implement this relay option this is mostly a solved problem now.

Another thing that makes me a bit sad is the lack of DHCPv6 reconfigure support. That could be used to take away some of the complaints against DHCPv6 (and any client-initiated configuration protocol) that there is no way for the network to inform the client of changes.

I see no need to replace it with something else that would indeed need to duplicate its functionality.

Cheers,
Sander

---

From: Mark Smith <[email-masked]>
Date: Tue, 21 Nov 2017 16:30:57 +1100

Hi Fred,

I think this fundamentally violates the principle that the network is
application agnostic or transparent, allowing it to support any new host
residing application without any upgrades to the network. I think the
principle of network application transparency should apply to application
configuration.

We don't have to upgrade routers to carry new application protocols, we
shouldn't have to upgrade routers to support configuring new applications.

"Internet Transparency and Application Configuration"

https://tools.ietf.org/html/draft-smith-v6ops-ce-dhcpv6-transparency-00#section-2

Regards,
Mark.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 21 Nov 2017 07:25:33 +0100 (CET)

> https://tools.ietf.org/html/draft-smith-v6ops-ce-dhcpv6-transparency-00#section-2

DHCP is a pain for rapidly changing (perhaps mobile) environments. It's 
fundamentally a polling protocol where the network hands out resources for 
a certain amount of time, and there is little chance to invalidate them. 
It's stateful.

Devices need addresses to communicate. So if environments that are dynamic 
and require fast/short setup times to gain addresses, then we need the 
network to support that.

This is not an "application" as in a program running somewhere. This is a 
deployment scenario where devices need addresses quickly with short 
turnaround times and in a bandwidth constrained environment. Saying we 
can't change the network to support this is just silly.

So you think 6lo was a bad idea and violated the network agonostic 
principle?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 21 Nov 2017 15:47:46 +0900

On Tue, Nov 21, 2017 at 6:40 AM, Templin, Fred L <[email-masked]>
wrote:

> like about DHCPv6. Maybe you think it is ugly.

As generally implemented and deployed, I think the main things that are
wrong with DHCPv6 are as follows. Note that these are not necessarily
limits imposed the protocol itself, but they are definitely limits imposed
by the implementations and how people typically deploy them. As such, the
following are not required to be true, but are only true in practice in the
vast majority of deployments.

   - In stateful form:
      - Inability to support multiple sources of information (the client
      picks the first lease it gets).
      - Very difficult to update devices when network changes because it's
      fundamentally based on leases and renews and RECONFIGURE is not (widely)
      implemented.
      - Makes possible stateful address assignment of individual IP
      addresses. It's really not a good idea to rely only on this for IP
      addressing, but there are decades of operational practice around
it in IPv4
      and old habits (and legacy deployed systems) die hard.
      - Typically deployed using relays and centralized assignment, which
      is very unsuited to topology changes.
         - If all you have is a central addressing server, you don't want
         to bother that server with constant topology updates from all over the
         network so it can update the hosts.
         - Also, if the topology changes enough, the server might even be
         unreachable from some hosts.
      - In stateless form:
      - Very hard to update devices when anything changes on the network.
      The minimum in the stateless DHCPv6 RFC is 10 minutes, which is *way* too
      long for certain types of networks like mobile hotspots.

The inability to update hosts with new network information is a crucial
weakness because it forces networks to appear to hosts as if they never
change. But networks change all the time. If you can't update the hosts on
a timely basis about a changes, either you never change the network, or you
have an outage, or you lie to the hosts. So we end up with things like VRRP
and NAT to ensure the host never sees the network change.

NAT, of course, is the ultimate way of never changing anything - you could
deploy IPv4 by assigning every host on every network 192.168.1.2 (gateway
and DNS server 192.16.1.1) and just NATing everything with layer-2 aware
NAT.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 21 Nov 2017 15:50:37 +0000

Hi Mark,

What we are doing here is properly joining the IPv6 ND and DHCPv6 functions into
a single unified autoconfiguration service for all time. Routers that don’t recognize
the DHCPv6 option in RS messages will simply ignore it and process it as a plain
vanilla RFC4861 RS. In that case, all RFC4861 functions still apply, including the
processing of the ‘M’ and ‘O’ bits. It is fully backwards compatible and does
not require any changes to existing routers.

Thanks - Fred

From: Mark Smith [mailto:[email-masked]]
Sent: Monday, November 20, 2017 9:31 PM
To: Templin, Fred L <[email-masked]>
Cc: 6MAN <[email-masked]>; v6ops list <[email-masked]>; [email-masked]
Subject: Re: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function

Hi Fred,

I think this fundamentally violates the principle that the network is application agnostic or transparent, allowing it to support any new host residing application without any upgrades to the network. I think the principle of network application transparency should apply to application configuration.

We don't have to upgrade routers to carry new application protocols, we shouldn't have to upgrade routers to support configuring new applications.

Regards,
Mark.

On 21 Nov. 2017 08:41, "Templin, Fred L" <[email-masked]<mailto:[email-masked]>> wrote:
Hello,

Comments?

Fred

-----Original Message-----
From: I-D-Announce [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Monday, November 20, 2017 1:21 PM
To: [email-masked]<mailto:[email-masked]>
Subject: I-D Action: draft-templin-6man-dhcpv6-ndopt-00.txt

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

[email-masked]<mailto:[email-masked]>

_______________________________________________
v6ops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/v6ops

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 21 Nov 2017 15:57:29 +0000

Hi Mikael,

> From: Mikael Abrahamsson [mailto:[email-masked]]
> Sent: Monday, November 20, 2017 10:26 PM
> To: Mark Smith <[email-masked]>
> Cc: Templin, Fred L <[email-masked]>; [email-masked]; v6ops list <[email-masked]>; 6MAN <[email-masked]>

I am using DHCPv6 PD for mobile hosts and networks over VPNs and it works
great. If the node moves, it simply sends an IPv6ND unsolicited NA message
to update the router's neighbor cache, and the prefix delegation remains
stable. 

> a certain amount of time, and there is little chance to invalidate them.

DHCPv6 Release is the client's function for invalidating prefix delegations.
DHCPv6 Reconfigure is the router's function for invalidating them.

> It's stateful.

Anything that manages a delegated prefix is going to necessarily be stateful.
If a different stateful protocol were developed it would be a functional
equivalent of DHCPv6. 

> So you think 6lo was a bad idea and violated the network agonostic

I don't know how the above relates to DHCPv6.

Thanks - Fred
[email-masked]

---

From: Mark Smith <[email-masked]>
Date: Wed, 22 Nov 2017 18:19:09 +1100

On 21 Nov. 2017 10:34 am, "Sander Steffann" <[email-masked]> wrote:

Hi,

> delegations in a single round trip message exchange.

Interesting way of doing this. I have thought about combining ND and DHCPv6
before, but more as a different distribution mechanism: ND for pushing
options to all clients on the network,

So how often do you want to upgrade router firmware? Everytime you want to
deploy an application that uses a new DHCPV6 option?

What do you do when the router vendor says, "we're never going to implement
that new DHCPV6 option in that router model, we don't have enough customers
any more for that model to justify all the development and testing time".
Never deploy the application?

What do you do if the router before says, "that DHCPv6 option is on our
implementation road map, we're expecting to implement it in 6 months
time."? Wait six months before you deploy the application?

Pushing layer 4+ configuration options into ND creates a dependency on
router firmware for application deployment that doesn't exist today in
either ND or DHCPV6.

Another example of this trap. Remember that NTP amplification DoS from 3 or
4 years ago? One place I'm aware of were using their PE routers to also
provide customers with NTP time, and the router implementation was
vulnerable. From memory, the vendor took around a week to release a fix.
Then the next 6 to 8 weeks were spent organising high impact change
controls because router firmware upgrades either required reboots or there
was a hazard of one. The number of PE routers was in the 10s, imagine time
and effort, and vulnerability exposure time if there were 100s or 1000s of
PE routers providing NTP time to customers.

Compare that to if the NTP service/application was not "in" the network,
not "in" the routers' control planes, and as service reachable over the
network. Only patches to the NTP servers would have been necessary, and
there would have been far fewer of those.

and DHCPv6 for clients requesting specific options for themselves. Just to
make it possible to use both mechanisms for all options (MAP/DSLite/etc
options in RA would be nice).

What you are doing is another way of looking at it. If I understand
correctly you're basically keeping the full functionality of DHCPv6 but
using RS/RA as a transport instead of UDP. I wonder what the speed benefit
of that would be in practice. Also compared to "impatient" systems that
send out DHCPv6 a request before even receiving an RA.

> would have to essentially duplicate what DHCPv6 already does.

In my opinion DHCPv6 is fine. I implemented a server and it is a *lot*
cleaner to implement than DHCPv4. Just plain UDP on link-local and
multicast sockets :)  Especially the stateless version is very easy to
implement. It's not the ultimate configuration protocol, and for certain
things distributing information via RA is a much better fit to the way the
network is run. But DHCPv6 has its place and its role, and in certain
environments (DHCPv6-PD in ISP networks, DHCPv6 in enterprise etc) it does
what the network and system operators need.

The main problem with DHCPv6 as an operator has been dealing with DUIDs
when the link-layer address in the DUID is based on a different interface
than the interface sending the DHCPv6 request. Mostly because the
requesting interface's MAC address has always been used with DHCPv4 and is
often printed on the outside of the device. But these days LDRA and DHCPv6
relays can tell the DHCPv6 server what the MAC address of the requesting
interface was, and we can use that to identify the client (in addition to
its DUID). With vendors starting to implement this relay option this is
mostly a solved problem now.

Another thing that makes me a bit sad is the lack of DHCPv6 reconfigure
support. That could be used to take away some of the complaints against
DHCPv6 (and any client-initiated configuration protocol) that there is no
way for the network to inform the client of changes.

I see no need to replace it with something else that would indeed need to
duplicate its functionality.

Cheers,
Sander

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 22 Nov 2017 16:33:07 +0900

On Wed, Nov 22, 2017 at 4:19 PM, Mark Smith <[email-masked]> wrote:

> Another example of this trap. Remember that NTP amplification DoS from 3
> or 4 years ago? One place I'm aware of were using their PE routers to also

These are all good reasons for ND being limited to only those options that
are strictly necessary for connectivity. There are those who argue that
even DHCPv6 is too low-level for that sort of thing and that
application-level configuration should be moved to another protocol.

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 22 Nov 2017 15:25:20 +0000

Hi Mark,

The router doesn’t need to implement DHCPv6 server; it can implement DHCPv6
relay, or it can not implement DHCPv6 at all and it will continue to work the way it
always has.

Your argument about  having to update router firmware when a new DHCPv6
option is specified is no different than the case when a new IPv6 ND option is
specified – both are applications, and updates to either would need to be
accommodated. With this proposal, we get a unified stateless/stateful service
that can natively handle all IPv6 autoconfiguration services now and into the
future.

Thanks - Fred

From: Mark Smith [mailto:[email-masked]]
Sent: Tuesday, November 21, 2017 11:19 PM
To: Sander Steffann <[email-masked]>
Cc: Templin, Fred L <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function

On 21 Nov. 2017 10:34 am, "Sander Steffann" <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

> delegations in a single round trip message exchange.
Interesting way of doing this. I have thought about combining ND and DHCPv6 before, but more as a different distribution mechanism: ND for pushing options to all clients on the network,

So how often do you want to upgrade router firmware? Everytime you want to deploy an application that uses a new DHCPV6 option?

What do you do when the router vendor says, "we're never going to implement that new DHCPV6 option in that router model, we don't have enough customers any more for that model to justify all the development and testing time". Never deploy the application?

What do you do if the router before says, "that DHCPv6 option is on our implementation road map, we're expecting to implement it in 6 months time."? Wait six months before you deploy the application?

Pushing layer 4+ configuration options into ND creates a dependency on router firmware for application deployment that doesn't exist today in either ND or DHCPV6.

Another example of this trap. Remember that NTP amplification DoS from 3 or 4 years ago? One place I'm aware of were using their PE routers to also provide customers with NTP time, and the router implementation was vulnerable. From memory, the vendor took around a week to release a fix. Then the next 6 to 8 weeks were spent organising high impact change controls because router firmware upgrades either required reboots or there was a hazard of one. The number of PE routers was in the 10s, imagine time and effort, and vulnerability exposure time if there were 100s or 1000s of PE routers providing NTP time to customers.

Compare that to if the NTP service/application was not "in" the network, not "in" the routers' control planes, and as service reachable over the network. Only patches to the NTP servers would have been necessary, and there would have been far fewer of those.

and DHCPv6 for clients requesting specific options for themselves. Just to make it possible to use both mechanisms for all options (MAP/DSLite/etc options in RA would be nice).

Cheers,
Sander

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 22 Nov 2017 15:52:21 +0000

Hi Lorenzo,

I respect your taking the time to post this useful critique, and expect that others
with a deeper background in the DHCPv6 architecture would want to respond in
detail. Thank you for sharing your thoughts.

For myself, In my environment I have mobile node clients with many routers
on the link – each of which implements the DHCPv6 relay and/or server. The
link is NBMA, meaning that multicast is not supported natively, so that the
client has to send the DHCPv6 Solicit to one or a couple of routers via LL
multicast to L2 unicast mapping. The client gets the exact same service
regardless of which router or routers it picks.

As long as the client remains on the link, it can continue to maintain the
prefix delegations it has received from its routers, and can even change to
a different set of routers if it thinks that would give better service. This is
true even if the client’s L2 addresses change, which is signaled by sending
unsolicited NAs to the routers the same as specified in RFC4861.

Again, this is just what I am doing in my environment and it gives a very
satisfactory service. What my draft is proposing is a unification of IPv6 ND
and DHCPv6 to give the best functions of both stateless and stateful
auconfiguration in a single unified package. And, if DHCPv6 would not
be suitable for supporting the stateful function, then we would have to
define something new that is.

Thanks - Fred

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Monday, November 20, 2017 10:48 PM
To: Templin, Fred L <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function

On Tue, Nov 21, 2017 at 6:40 AM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:
I would ask these discussion lists to consider what is it that you really don't
like about DHCPv6. Maybe you think it is ugly.

As generally implemented and deployed, I think the main things that are wrong with DHCPv6 are as follows. Note that these are not necessarily limits imposed the protocol itself, but they are definitely limits imposed by the implementations and how people typically deploy them. As such, the following are not required to be true, but are only true in practice in the vast majority of deployments.

  *   In stateful form:

     *   Inability to support multiple sources of information (the client picks the first lease it gets).
     *   Very difficult to update devices when network changes because it's fundamentally based on leases and renews and RECONFIGURE is not (widely) implemented.
     *   Makes possible stateful address assignment of individual IP addresses. It's really not a good idea to rely only on this for IP addressing, but there are decades of operational practice around it in IPv4 and old habits (and legacy deployed systems) die hard.
     *   Typically deployed using relays and centralized assignment, which is very unsuited to topology changes.

        *   If all you have is a central addressing server, you don't want to bother that server with constant topology updates from all over the network so it can update the hosts.
        *   Also, if the topology changes enough, the server might even be unreachable from some hosts.

  *   In stateless form:

     *   Very hard to update devices when anything changes on the network. The minimum in the stateless DHCPv6 RFC is 10 minutes, which is *way* too long for certain types of networks like mobile hotspots.
The inability to update hosts with new network information is a crucial weakness because it forces networks to appear to hosts as if they never change. But networks change all the time. If you can't update the hosts on a timely basis about a changes, either you never change the network, or you have an outage, or you lie to the hosts. So we end up with things like VRRP and NAT to ensure the host never sees the network change.

NAT, of course, is the ultimate way of never changing anything - you could deploy IPv4 by assigning every host on every network 192.168.1.2 (gateway and DNS server 192.16.1.1) and just NATing everything with layer-2 aware NAT.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 22 Nov 2017 11:53:50 -0500

My understanding is that Fred Templin essentially wants to carry DHCP
(configuration) options in ND/RA.

I think that they are most often stateless (i.e. not addresses at all or
other resources).

I've heard the IPv4 PPP folks lament that they should have just had an IPCP
option to carry DHCPv4 options, and indeed that's why we have almost no IP6CP
options, as it's all done by ND and DHCPv6.

{Having implemented a DHCPv6 server just to serve PPP links, it really feels
dumb.  Yes, the management is all centralized, but it's centralized via
RADIUS, not via DHCP relays. }

So I suggest that Fred should go ahead with his document as Experimental,
with our blessing, and an obligation to report on how well it works in
his situation.   Given the timescales that I think his industry works at, he
might need more time than an average Experimental code allocation.
He would have to deal how/if/when all experimental systems would be withdrawn
should the experiment be unsuccessful, I think.

I guess he could use ND codes 253/254, but I think an assignment would not
kill here.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 22 Nov 2017 17:31:29 +0000

Hi Michael,

This isn't an experiment; this is a unified stateless/stateful autoconfiguration
service for IPv6 for all time.

We all want prefix delegation, and that will necessarily be a stateful function.
And, if the prefix delegation service would not be DHCPv6 PD then we would
need to develop a new PD architecture. Either way, though, it should be
implemented as a unified function with IPv6ND.

Thanks - Fred

> From: ipv6 [mailto:[email-masked]] On Behalf Of Michael Richardson
> Sent: Wednesday, November 22, 2017 8:54 AM
> To: [email-masked]; [email-masked]; [email-masked]

---

From: Fred Baker <[email-masked]>
Date: Wed, 22 Nov 2017 16:18:54 -0800

> On Nov 22, 2017, at 8:53 AM, Michael Richardson <[email-masked]> wrote:
> 

On thing that I have never understood is the lack of an RA option that carries any DHCPv6 option. This entire silly debate would end if RAs encompassed DHCP options.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 23 Nov 2017 13:05:20 -0500

> On thing that I have never understood is the lack of an RA option that
    > carries any DHCPv6 option. This entire silly debate would end if RAs
    > encompassed DHCP options.

I think that this is mostly what Fred wants to define.

Apparently he also wants to do stateful DHCPv6 things (such as PD), which I
am much less enthusiastic about putting into RAs/NDs as they cease to be
idempotent.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 27 Nov 2017 13:19:54 +0000

> On thing that I have never understood is the lack of an RA option that carries
> any DHCPv6 option. This entire silly debate would end if RAs encompassed
> DHCP options.

Thus forcing either routers or hosts (or both) to support two distinct mechanisms to do the same thing if there is to be any hope of interoperability. And if the host supports both, then it also needs to implement code for which wins when both are present and the options provided have conflicting info.
If you really want DHCPv6 options in RAs for closed ecosystem use cases, include a huge caveat that routers are not required to support both mechanisms -- routers are only required to do DHCPv6. Any host that only implements receipt of DHCPv6 options via RA must not expect to operate in an open ecosystem. Put the burden on the hosts. 
Barbara

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 27 Nov 2017 17:30:19 +0000

Hi Fred,

> From: ipv6 [mailto:[email-masked]] On Behalf Of Fred Baker
> Sent: Wednesday, November 22, 2017 4:19 PM
> To: Michael Richardson <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked]

Yes, that is what the draft says. The client's DHCPv6 request messages are
included in RS options, and the server's DHCPv6 reply messages are included
in RA options. A unified IPv6 ND/DHCPv6 autoconfiguration service.

As near as I can tell, everyone wants prefix delegation which is by nature
a stateful service. Some seem to be questioning DHCPv6 as the correct
architecture for the stateful service, but if not DHCPv6 then there would
need to be a new prefix delegation architecture - perhaps a design from
scratch. But, when all is said and done, it would end up looking very much
like DHCPv6.

Thanks - Fred

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 28 Nov 2017 12:06:53 +1300

On 28/11/2017 02:19, STARK, BARBARA H wrote:
> Thus forcing either routers or hosts (or both) to support two distinct mechanisms to do the same thing if there is to be any hope of interoperability. 

Yes and no. Let's consider a host that needs a particular piece of
information. As an example, consider the address of the next-hop router
for a given prefix. There are three separate parts to this:

1. Receiving some sort of message containing an appropriate option.
2. Decoding the option
3. Storing the result.

The important one is #3. The mechanism for storing the result
is unavoidable, and stateful, whatever the delivery protocol
and encoding.

In the real world, most hosts today have several versions of
#1 in their code: RA, DHCP, RADIUS come to mind. (What they
enable is another matter.)

So where's the duplication? It seems to be in the decoding
step. With a little software engineering, there could be
a single decoder that handles all the possible formats, and
doesn't care which protocol delivered it.

> And if the host supports both, then it also needs to implement code for which wins when both are present and the options provided have conflicting info.

I suspect that is needed anyway, in the general case.

> If you really want DHCPv6 options in RAs for closed ecosystem use cases, include a huge caveat that routers are not required to support both mechanisms -- routers are only required to do DHCPv6.

Yes, if an option is primarily defined for DHCP, that makes sense.

> Any host that only implements receipt of DHCPv6 options via RA must not expect to operate in an open ecosystem. Put the burden on the hosts.

Probably. Unless this thing becomes popular.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 28 Nov 2017 12:59:12 +1300

> am much less enthusiastic about putting into RAs/NDs as they cease to be

I think a key sentence in the draft is this:
"The IPv6 ND function then acts as a Lightweight DHCPv6
 Relay Agent (LDRA) [RFC6221] to forward the message to the DHCPv6
 relay or server function on-board the router."

If it's clear that ND is serving only as a lightweight relay,
doesn't your concern go away? As far as I can see, lightweight
relays are stateless.

      Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 28 Nov 2017 14:21:58 +0900

On Tue, Nov 28, 2017 at 8:06 AM, Brian E Carpenter <
[email-masked]> wrote:

> [...]

You can't really separate these steps because the protocols that deliver
configuration information have different semantics. For example, DHCPv6 is
poll-based and requires explicit renewal, but RAs are push-based.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 28 Nov 2017 17:02:17 +0000

Hi, if there is some concern about backwards compatibility and accepting
configuration information from multiple sources the scenario is as follows:

- the host MAY include a DHCPv6 Request option in its RS message
- routers that do not recognize the DHCPv6 Request option, or that
   do not implement a DHCPv6 relay or server, ignore the option and
   return an RA with no DHCPv6 option and with M/O bits set as normal
- routers that recognize the DHCPv6 Request option and that implement
   a DHCPv6 relay or server process the DHCPv6 Request then include a
   DHCPv6 Reply option in unicast RAs that they send back to the host
- the host processes the RA message and also processes the DHCPv6
   Reply while accepting the union of the configuration information
   provided by both IPv6 ND and DHCPv6

Note that there will never be a time that a router includes a DHCPv6 Reply
option in its RA message unless the host first included a DHCPv6 Request
option in its RS. And, even if it did, hosts that do not recognize the option
will simply ignore it and process the rest of the RA message as normal.

The approach is therefore fully backwards compatible and provides
the best combination of both IPv6 ND and DHCPv6 autoconfiguration.

Thanks - Fred

> From: dhcwg [mailto:[email-masked]] On Behalf Of STARK, BARBARA H
> Sent: Monday, November 27, 2017 5:20 AM
> To: Fred Baker <[email-masked]>; Michael Richardson <[email-masked]>
> Subject: Re: [dhcwg] [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function
> 
> Thus forcing either routers or hosts (or both) to support two distinct mechanisms to do the same thing if there is to be any hope of
> interoperability. And if the host supports both, then it also needs to implement code for which wins when both are present and the
> options provided have conflicting info.
> If you really want DHCPv6 options in RAs for closed ecosystem use cases, include a huge caveat that routers are not required to
> support both mechanisms -- routers are only required to do DHCPv6. Any host that only implements receipt of DHCPv6 options via RA
> must not expect to operate in an open ecosystem. Put the burden on the hosts.
> Barbara
> 
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 28 Nov 2017 17:08:49 +0000

Hi Lorenzo,

In this proposal, DHCPv6 and IPv6 ND peacefully coexist. After the initial autoconfiguration,
if the host needs to renew, release, rebind, etc. it simply issues a new RS and the router
responds with a new RA. So, all IPv6 ND and DHCPv6 operations are driven from a single
engine, namely RS/RA.

Thanks - Fred

From: ipv6 [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: Monday, November 27, 2017 9:22 PM
To: Brian E Carpenter <[email-masked]>
Cc: [email-masked]; [email-masked]; Michael Richardson <[email-masked]>; [email-masked]
Subject: Re: [dhcwg] [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function

On Tue, Nov 28, 2017 at 8:06 AM, Brian E Carpenter <[email-masked]<mailto:[email-masked]>> wrote:
Yes and no. Let's consider a host that needs a particular piece of
information. As an example, consider the address of the next-hop router
for a given prefix. There are three separate parts to this:

You can't really separate these steps because the protocols that deliver configuration information have different semantics. For example, DHCPv6 is poll-based and requires explicit renewal, but RAs are push-based.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 29 Nov 2017 08:29:18 +1300

> poll-based and requires explicit renewal, but RAs are push-based.

I think those are mechanical details. RAs expire & the host waits
for renewal; a DHCP host solicits renewal; but from a bird's eye view
that is a hidden distinction.

    Brian