RE: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function

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:markzzzsmith@gmail.com]
Sent: Monday, November 20, 2017 9:31 PM
To: Templin, Fred L <Fred.L.Templin@boeing.com>
Cc: 6MAN <6man@ietf.org>; v6ops list <v6ops@ietf.org>; dhcwg@ietf.org
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.

"Internet Transparency and Application Configuration"
https://tools.ietf.org/html/draft-smith-v6ops-ce-dhcpv6-transparency-00#section-2

Regards,
Mark.

On 21 Nov. 2017 08:41, "Templin, Fred L" <Fred.L.Templin@boeing.com<mailto:Fred.L.Templin@boeing.com>> wrote:
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:i-d-announce-bounces@ietf.org<mailto:i-d-announce-bounces@ietf.org>] On Behalf Of internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>
Sent: Monday, November 20, 2017 1:21 PM
To: i-d-announce@ietf.org<mailto:i-d-announce@ietf.org>
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<http://tools.ietf.org>.

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

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org<mailto:I-D-Announce@ietf.org>
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
v6ops@ietf.org<mailto:v6ops@ietf.org>
https://www.ietf.org/mailman/listinfo/v6ops