Subject: I-D Action: draft-ietf-6man-rfc6434-bis-01.txt

From: [email-masked]
Date: Mon, 03 Jul 2017 08:40:47 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Maintenance of the IETF.

        Title           : IPv6 Node Requirements
        Authors         : Tim Chown
                          John Loughney
                          Timothy Winters
	Filename        : draft-ietf-6man-rfc6434-bis-01.txt
	Pages           : 38
	Date            : 2017-07-03

Abstract:
   This document defines requirements for IPv6 nodes.  It is expected
   that IPv6 will be deployed in a wide range of devices and situations.
   Specifying the requirements for IPv6 nodes allows IPv6 to function
   well and interoperate in a large number of situations and
   deployments.

   This document obsoletes RFC 6434, and in turn RFC 4294.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6434-bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-6man-rfc6434-bis-01
https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc6434-bis-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc6434-bis-01

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/

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 16 Jul 2017 16:06:08 +1200

Hi,

Some comments, but not a full review:

>    -  IPv6 over ATM Networks [RFC2492]

Is this still worth mentioning?

>    -  IP version 6 over PPP [RFC5072]
> 
>    In addition to traditional physical link-layers, it is also possible
>    to tunnel IPv6 over other protocols.  Examples include:

Shouldn't PPP be in this list, not the previous list?
 
>    -  Teredo: Tunneling IPv6 over UDP through Network Address
>       Translations (NATs) [RFC4380]
> 
>    -  Section 3 of "Basic Transition Mechanisms for IPv6 Hosts and
>       Routers" [RFC4213]
> 
>    **BIS Do we want a small section somewhere on UDP IPv6 tunneling, and
>    issues like RFC 6935, or 6936?**

Maybe. But the field is evolving: Teredo is surely obsolescent, there's
also TSP (RFC5572), and draft-ietf-intarea-gue is in progress. So I wonder
what you can really say.

> 5.1.  Internet Protocol Version 6 - RFC 2460
> 
>    The Internet Protocol Version 6 is specified in [RFC2460].  This
>    specification MUST be supported.
> 
>    **BIS Again, update for RFC 2460 -bis **
> 
>    Any unrecognized extension headers or options MUST be processed as
>    described in RFC 2460.

As well as s/2460/8200/, I suggest s/processed/treated/ to avoid another
debate about the meaning of 'processed' ;-).

(And don't forget s/1981/8201/.)

> 5.7.  IPv6 Jumbograms - RFC 2675
...
>     and there is essentially no reported experience from usage.
>    Consequently, IPv6 Jumbograms [RFC2675] remain optional at this time.
> 
>    **BIS Are these used?  Do we need to modify the text for that? **

I don't think so. They appear to be harmless and maybe somebody will
need them one day, so there is no obvious argument for deprecation.

> 5.10.  First-Hop Router Selection - RFC 8028
...
>    Hosts that may be deployed in such multihomed environments SHOULD
>    follow the guidance given in [RFC8028].

Which should therefore be listed as a Normative reference.

> 6.1.  IP Version 6 Addressing Architecture - RFC 4291
> 
>    The IPv6 Addressing Architecture [RFC4291] MUST be supported.
> 
>    **BIS Update to 4291-bis **

Maybe not :-(

>    **BIS Add note on Why /64?  RFC 7421, after the conclusion of the
>    RFC4291-bis (lengthy!!!) discussions on the 64-bit IID topic.  But no
>    need for /127 p2p text RFC 6164.  And no need for note on IID
>    significance, as per RFC 7136. **

I'm not sure we need to mention RFC 7421 here at all. If 4291bis gets
published, it will be mentioned there. If it doesn't get published,
64 remains fixed anyway.

> 6.3.  IPv6 Stateless Address Autoconfiguration - RFC 4862
> 
>    Hosts MUST support IPv6 Stateless Address Autoconfiguration as
>    defined in either [RFC4862] or [RFC7217].

That's wrong, surely? SLAAC is defined in 4862, and 7217 doesn't even
formally update it. I think you should simply delete 'or [RFC7217]'.

>                                              It is recommended that,
>    unless there is a specific requirement for MAC addresses to be
>    embedded in an IID, nodes follow the procedure in RFC7217 to generate
>    SLAAC-based addresses.

That only applies if a stable IID is wanted.  I would suggest:

It is recommended that,
unless there is a specific requirement for MAC addresses to be
embedded in an IID, nodes follow the procedures in [RFC7217]
or [RFC4941] (see below) to generate SLAAC-based addresses.

(I think we've already established that it's possible to operate
a node that has no stable global-scope address.)

> 6.6.  Default Address Selection for IPv6 - RFC 6724
> 
>    IPv6 nodes will invariably have multiple addresses configured
>    simultaneously, and thus will need to choose which addresses to use
>    for which communications.  The rules specified in the Default Address
>    Selection for IPv6 [RFC6724] document MUST be implemented.

I am concerned about the famous rule 5.5 in RFC6724. It's optional there,
but elsewhere you have a SHOULD for RFC8028, whose section 3.3 in turn
promotes rule 5.5 to a SHOULD. Could we add that promotion here
too? Otherwise there is a complicated trail for implementers to follow.

> 14.  Router-Specific Functionality

I think you should require BCP198 (RFC7068) support.

Regards
     Brian

---

From: Timothy Winters <[email-masked]>
Date: Sun, 16 Jul 2017 04:25:00 -0400

Hi Brian,

> Is this still worth mentioning?

Probably not, we'll remove this in the next draft.  How do you feel about
Frame Relay?

> Shouldn't PPP be in this list, not the previous list?
Yes.

> (And don't forget s/1981/8201/.)
Thanks, we'll make all those updates.

> need them one day, so there is no obvious argument for deprecation.
K, we'll remove the note.

> Which should therefore be listed as a Normative reference.
Thanks, we'll update that to Normative.

> >    **BIS Update to 4291-bis **
I still have hope.....

> published, it will be mentioned there. If it doesn't get published,
Thanks for the feedback.

> a node that has no stable global-scope address.)
OK, this text looks fine to me.

> too? Otherwise there is a complicated trail for implementers to follow.
I like this idea, how about.

Since RFC 8028 updates rule 5.5 from RFC 6724 implementations SHOULD
implement this rule.

> I think you should require BCP198 (RFC7068) support.
Interesting thought (should be RFC7608).   I don't have a problem adding
this, I'll check with the co-authors.

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

-- 

Now offering testing for SDN applications and controllers in our SDN switch
test bed. Learn more today http://bit.ly/SDN_IOLPR

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 16 Jul 2017 11:31:41 +0200

>         Filename        : draft-ietf-6man-rfc6434-bis-01.txt

I see that the document still says:

   There will be a wide
   range of IPv6 deployment models and differences in address assignment
   requirements, some of which may require DHCPv6 for stateful address
   assignment.  Consequently, all hosts SHOULD implement address
   configuration via DHCPv6.

We should abandon this documentation, for two reasons.

First, networks that require DHCPv6 assignment are explicitly NOT
RECOMMENDED by current IETF best practices. Specifically, RFC 7934 section
8 says "it is RECOMMENDED that the network give the host the ability to use
new addresses without requiring explicit requests". A DHCPv6-only network
cannot meet this recommendation, because on a DHCPv6-only network, all
addresses acquisition requires an explicit request to the network.

Second, the draft says "Where devices are likely to be carried by users and
attached to multiple visisted networks, DHCPv6 client anonymity profiles
SHOULD be supported as described in [RFC7844]".

But RFC 7844 says that hosts SHOULD prefer stateless address configuration
over DHCPv6: "hosts using the anonymity profile SHOULD use stateless
address configuration instead of stateful address configuration".

So for such devices, there is a direct conflict: this document says they
SHOULD do DHCPv6, but RFC 7844 says they SHOULD not if other addressing
modes are available.

I would propose the following text for section 6.5:

   [...] There will be a wide
   range of IPv6 deployment models and differences in address assignment
   requirements, some of which may use DHCPv6 for stateful address
   assignment in addition to other addressing modes. Using DHCPv6 as the
   only IPv6 address configuration mechanism is NOT RECOMMENDED
   [RFC 7934 section 8].

   In the absence of a router, IPv6 nodes using DHCP for address
   assignment MAY initiate DHCP to obtain IPv6 addresses and other
   configuration information, as described in Section 5.5.2 of
   [RFC4862].

   Where devices are likely to be carried by users and attached to
   multiple visisted networks, DHCPv6 client anonymity profiles SHOULD
   be supported as described in [RFC7844] to minimise the discolosure of
   identifying information. This profile recommends that the device prefer
   stateless address configuration over DHCPv6 address configuration.

   Devices that do not have particular anonymity requirements SHOULD
   implement address configuration via DHCPv6 in order to be able to
   take advantage of IPv6 addresses available only via DHCPv6.

---

From: Erik Kline <[email-masked]>
Date: Sun, 16 Jul 2017 19:13:15 +0900

On 16 July 2017 at 18:31, Lorenzo Colitti <[email-masked]> wrote:
> RECOMMENDED by current IETF best practices. Specifically, RFC 7934 section 8
> says "it is RECOMMENDED that the network give the host the ability to use
> over DHCPv6: "hosts using the anonymity profile SHOULD use stateless address
> configuration instead of stateful address configuration".
>

Sounds good to me.

I also think that section 5.9 on RFC 4191 should be a MUST.  We don't
want to end up in a situation where routers are sending out PIOs with
/56s and L=0 in order to maintain internal connectivity when RAs have
default_router_lifetime=0, e.g. because the upstream network has gone
away.

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 16 Jul 2017 12:20:01 +0100

Lorenzo Colitti wrote:
> There will be a wide range of IPv6 deployment models and differences
> in address assignment requirements, some of which may require DHCPv6
> for stateful address assignment.  Consequently, all hosts SHOULD
> implement address configuration via DHCPv6.
> 
> RECOMMENDED by current IETF best practices. Specifically, RFC 7934 
> section 8 says "it is RECOMMENDED that the network give the host the 
> ability to use new addresses without requiring explicit requests". A 
> DHCPv6-only network cannot meet this recommendation, because on a 
> DHCPv6-only network, all addresses acquisition requires an explicit 
> request to the network.
> 
> Second, the draft says "Where devices are likely to be carried by
> users and attached to multiple visisted networks, DHCPv6 client
> anonymity profiles SHOULD be supported as described in [RFC7844]".

neither of these suggestions form anything even close to an adequate
basis to drop the recommendation for dhcpv6.

The self-selection addressing model does not suit the deployment
requirements for many types of ipv6 networks, including enterprise,
provider hosting, terrestrial access networks (e.g. docsis / gpon /
ipoe) and others.  If the recommendation for dhcpv6 is dropped, then
there is no recommended ietf model for operator-assigned addressing, and
this would leave a glaring hole in the ipv6 host specification.

Just because SLAAC works for many types of ipv6 deployments, that
doesn't make it a suitable model for every situation.

Nick

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 16 Jul 2017 13:25:10 +0200

> this would leave a glaring hole in the ipv6 host specification.

That's a fair opinion to hold, but the fact of the matter is that a SHOULD
for DHCPv6 conflicts with RFC 7934 and RFC 7844.

We shouldn't publish a host requirements document that contradicts the host
address assignment BCP and that cites RFC7844 while contradicting that
document's recommendation to use stateless in preference to stateful.

---

From: Job Snijders <[email-masked]>
Date: Sun, 16 Jul 2017 14:12:08 +0200

On Sun, Jul 16, 2017 at 01:25:10PM +0200, Lorenzo Colitti wrote:
> > there is no recommended ietf model for operator-assigned addressing,
> > and this would leave a glaring hole in the ipv6 host specification.
> 
> That's a fair opinion to hold, but the fact of the matter is that a
> SHOULD for DHCPv6 conflicts with RFC 7934 and RFC 7844.

I think that the words 'opinion' and 'fact' may need to be swapped
around in the above sentence. Operator-assigned addressing should not be
left out or discouraged.

Kind regards,

Job

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 16 Jul 2017 13:14:02 +0100

> SHOULD for DHCPv6 conflicts with RFC 7934 and RFC 7844.

"The fact of the matter"? :-)

There is no conflict here.

The "SHOULD" that you quoted in rfc7934 refers to how an opinion about
people ought to run their networks, but does not conflict with the
SHOULD in 6434bis, which refers to what the IETF is proposing ought to
be supported on host devices.  These two things are very different indeed.

Nick

---

From: Sander Steffann <[email-masked]>
Date: Sun, 16 Jul 2017 14:53:26 +0200

Hi,

> Op 16 jul. 2017, om 14:14 heeft Nick Hilliard <[email-masked]> het volgende geschreven:
> 
> Lorenzo Colitti wrote:

+1

Cheers,
Sander

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 16 Jul 2017 15:47:39 +0200

> be supported on host devices.  These two things are very different indeed.

It's not an opinion, it's an IETF best practice. And I really don't see how
you can say there's no contradiction. For the moment, let's consider mobile
hosts that follow the anonymity profile.

This document says that hosts SHOULD support DHCPv6 because operators might
use it. But our current recommendations say that:

   1. Such hosts SHOULD prefer SLAAC over DHCPv6
   2. DHCPv6-only networks are NOT RECOMMENDED

Due to #1, such hosts will always prefer SLAAC over DHCPv6 on networks that
have both. So a "SHOULD support DHCPv6" requirement will only matter on
networks that don't do SLAAC, which are NOT RECOMMENDED.

So we're basically saying that they SHOULD implement IPv6 only for the
purpose of connecting to networks that are NOT RECOMMENDED. How can we
recommend something that is only used for something that is NOT RECOMMENDED?

---

From: David Farmer <[email-masked]>
Date: Sun, 16 Jul 2017 09:43:04 -0500

On Sun, Jul 16, 2017 at 6:25 AM, Lorenzo Colitti <[email-masked]> wrote:

> We shouldn't publish a host requirements document that contradicts the
> host address assignment BCP and that cites RFC7844 while contradicting that

Lets start with RFC 7934 it is a set of RECOMMENDATIONS for how networks
should supply addresses to general purpose hosts.  First, not everything
fits into that scope and even within that scope as a RECOMMENDATION that
means "there may exist valid reasons in particular circumstances to ignore
a particular item" [RFC2119].  So, it by no means precludes the possibility
that hosts could find them on a network that is only providing addresses
via DHCPv6. Therefore, a SHOULD for DHCPv6 in the host requirements still
seems appropriate to me.

As for RFC 7844, it is scoped to mobile hosts that want privacy from the
DHCP server, and it says "The anonymity profiles have the effect of hiding
the client identity from the DHCP server.  This is not always desirable.
..."  A document that itself recognizes it's primary purpose "is not always
desirable" even within it's defined scope, isn't a strong argument for
changing the RECOMMENDED behavior of all host.

Further, a "recommendation to use stateless in preference to stateful"
isn't a prohibition on stateful, Until, stateful is prohibited or all
networks are required to provided stateless, a SHOULD for DHCPv6 in the
host requirements still seems appropriate to me.

Thanks.

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815 <(612)%20626-0815>
Minneapolis, MN 55414-3029   Cell: 612-812-9952 <(612)%20812-9952>
===============================================

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 16 Jul 2017 15:50:26 +0100

Lorenzo Colitti wrote:
> For the moment, let's consider mobile hosts that follow the
> anonymity profile.

Here's a better idea: let's consider cable modems running on a DOCSIS3
network.

> So we're basically saying that they SHOULD implement IPv6 only for 
> the purpose of connecting to networks that are NOT RECOMMENDED. How 
> can we recommend something that is only used for something that is 
> NOT RECOMMENDED?

because there is no obligation to use dhcpv6, just a recommendation that
it should be supported by the host.  You're confusing the two issues and
they are quite separate.

Nick

---

From: David Farmer <[email-masked]>
Date: Sun, 16 Jul 2017 09:54:34 -0500

> host requirements still seems appropriate to me.

I should have added; while I don't think you are providing a valid argument
against a SHOULD for DHCPv6 in the host requirements, it is a completely
valid argument against a MUST for DHCPv6 in the host requirements.

Thanks.

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: Morizot Timothy S <[email-masked]>
Date: Sun, 16 Jul 2017 15:36:59 +0000

I’ve commented on this topic in the past, but will simply make one more observation on this specific point. The RFC is informational, so isn’t a matter of huge concern as it has no impact on product selection or the procurement process. If the manufacturer/developer of a host decides they don’t want to make a product they can sell to enterprises utilizing DHCPv6 only host networks (except perhaps in some very limited, restricted capacity), that’s fine. Plenty of other companies will. However, I do agree the recommendation should be updated to reflect reality, otherwise I suppose it could lead developers of such host products that DHCPv6 support is actually optional. In some environments it is. In others it is not. But then, I also believe the developers of such hosts understand their markets and are unlikely to be misled by an informational RFC.

It does, however, strike me as somewhat silly for the IETF to continue to “NOT RECOMMEND” (as I gather from the appendix of changes was the case way back in 4294) a use case that complies with the standards, has been deployed, is being deployed, and will continue to be used in the future. It’s not even a matter of whether or not connection security is deployed or neighbor tables (or arp for v4) and other data are collected from network devices. (At the sorts of organizations and networks with which I’m familiar, both are often true. There are even networks where nothing but manually configured devices are allowed and switch ports must be manually enabled.) Rather, the security monitoring and analysis processes (automated and manual) are in part built around dhcp for basic client networks. It’s a relatively small lift to extend those processes to DHCPv6. It would be a much larger lift to develop entirely new, parallel ones using different data, even though that alternative data are likely also collected and available. It’s particularly unwieldy while IPv4, with its existing processes, is in use on some or all of those networks.

Perhaps in the future, if there’s ever a compelling use case for widespread deployment of SLAAC on general purpose host data networks and IPv4 has mostly been retired from the network outside enclaves where it’s still required for one reason or another, those processes can and probably will be revisited, especially as deployed tools are updated or replaced. Until such time, I know for certain that at least on certain sorts of large enterprise networks DHCPv6-only has been, is, and will continue to be deployed and used, at least on most general purpose host data networks in the enterprise. Those companies that wish to develop general purpose host devices they can sell for use on such networks will support that use case whatever informational recommendations the IETF chooses to publish. Specialty networks for IOT devices (sensors, cameras, lighting, or whatever) are a different matter. Those sorts of things are already segregated into their own networks when using IPv4. If they have special network requirements and otherwise meet our capability requirements, those always have been and will continue to be accommodated.

The enterprise space varies a lot according to the sort of enterprise, but it’s never going to really look like a general hosting company or generic user ISP. Enterprises can and do restrict what connects and functions on their networks. Enterprise networks do not have to support every kind of device or every configuration option. And most large ones probably won’t. But many companies developing host devices would still like to sell them to large enterprises. And if they want to do so, they should certainly consider supporting DHCPv6. It seems to me the IETF recommendation should reflect that reality.

Scott

Lorenzo Colitti [email-masked]<mailto:[email-masked]> wrote:

This document says that hosts SHOULD support DHCPv6 because operators might use it. But our current recommendations say that:

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 17 Jul 2017 10:59:33 +1200

On 17/07/2017 03:36, Morizot Timothy S wrote:
> I’ve commented on this topic in the past, but will simply make one more observation on this specific point. The RFC is informational

That's our choice. I think that with IPv6 being at Full Standard, 
it's time to open the debate about whether 6434bis should be a BCP.

> so isn’t a matter of huge concern as it has no impact on product selection or the procurement process.

Only for customers who treat RFC status as holy writ. Many people are
more realistic and will use an RFC called "Node Requirements" as
a requirements checklist.

...> This document says that hosts SHOULD support DHCPv6 because operators might use it. 

Operators might *require* it, so a recommended-to-implement requirement
is entirely appropriate for a document aimed at implementers.

> But our current recommendations say that:
> 

As others have said, that is compatible with recommended-to-implement.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 17 Jul 2017 11:03:57 +1200

Tim,

Trimming this just to your direct questions:

On 16/07/2017 20:25, Timothy Winters wrote:
...
> Probably not, we'll remove this in the next draft.  How do you feel about

I don't really know - is it still deployed in the real world? If so,
you could leave it in.

...
> Since RFC 8028 updates rule 5.5 from RFC 6724 implementations SHOULD

Looks good.

Thanks,
    Brian

---

From: Morizot Timothy S <[email-masked]>
Date: Mon, 17 Jul 2017 00:14:53 +0000

Brian E Carpenter [[email-masked]] wrote:
> > I’ve commented on this topic in the past, but will simply make one more
> observation on this specific point. The RFC is informational
> 

Sorry, I realized that comment didn't clearly state what I was thinking. I meant if it were a standards document specifying that DHCPv6 only networks, a perfectly valid configuration in the standards to date, were not recommended (in any context) or a standards document specifying that DHCPv6 as a protocol was not recommended, then I would have more concerns over the state of the document. It wouldn't change anything in operational configuration or practice, but would clearly be a more significant issue. Given that this is an information recommendation for host developers, it has no direct impact on those purchasing or otherwise electing to use said hosts. Even if it were a BCP (which would be odd to call something a "common practice" of any sort if it didn't recommend host developers consider DHCPv6 support since many hosts do support it today), that would have little impact since as those purchasing or electing to use "hosts", we write our own requirements for them. So I was really just trying to note that I was commenting from the perspective of those who specify requirements for procuring host devices, not from the perspective of those who develop said devices.

From that perspective, since hosts may very well find themselves excluded from consideration by some sorts of large enterprises if they do not support DHCPv6, a document aimed at their developers makes more sense if it notes they should consider supporting DHCPv6. The developer may decide it doesn't fit their model or the host may be a very special purpose IOT sort of host which in a large enterprise may be segregated into its own network anyway. Given that, the change to SHOULD seems to make a lot more sense than what people may have thought when 4294 was written. (Again, from the appendix of this bis, it looks like that's what is actually be updated in the revision.) Doing anything else looks like pretty poor advice to developers of hosts, again from my perspective. And from my operational experience, many hosts support DHCPv6 and DHCPv6 only networks just fine today, whatever the current recommendations might say. Updating the recommendations to reflect reality seems reasonable.

Scott

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 17 Jul 2017 01:52:01 +0000

On Sun, Jul 16, 2017 at 6:25 AM, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>> wrote:
On Sun, Jul 16, 2017 at 1:20 PM, Nick Hilliard <[email-masked]<mailto:[email-masked]>> wrote:
The self-selection addressing model does not suit the deployment
requirements for many types of ipv6 networks, including enterprise,
provider hosting, terrestrial access networks (e.g. docsis / gpon /
ipoe) and others.  If the recommendation for dhcpv6 is dropped, then
there is no recommended ietf model for operator-assigned addressing, and
this would leave a glaring hole in the ipv6 host specification.

That's a fair opinion to hold, but the fact of the matter is that a SHOULD for DHCPv6 conflicts with RFC 7934 and RFC 7844.

We shouldn't publish a host requirements document that contradicts the host address assignment BCP and that cites RFC7844 while contradicting that document's recommendation to use stateless in preference to stateful.

Lets start with RFC 7934 it is a set of RECOMMENDATIONS for how networks should supply addresses to general purpose hosts.  First, not everything fits into that scope and even within that scope as a RECOMMENDATION that means "there may exist valid reasons in particular circumstances to ignore a particular item" [RFC2119].  So, it by no means precludes the possibility that hosts could find them on a network that is only providing addresses via DHCPv6. Therefore, a SHOULD for DHCPv6 in the host requirements still seems appropriate to me.

As for RFC 7844, it is scoped to mobile hosts that want privacy from the DHCP server, and it says "The anonymity profiles have the effect of hiding the client identity from the DHCP server.  This is not always desirable. ..."  A document that itself recognizes it's primary purpose "is not always desirable" even within it's defined scope, isn't a strong argument for changing the RECOMMENDED behavior of all host.

<bhs> +1. RFC 6434 Node Requirements are general-purpose for all nodes on all networks. And should remain so. They should not be tailored to 3GPP networks or mass market end user networks or any other special network. RFC 7934 and 7844 are not for all nodes. BTW, many wireline access networks do not support SLAAC for address assignment to the CE Router. Which is why RFC 7084 exists -- to provide specific guidance for that specific use case. RFC 7084 does not conflict with RFC 6434. Because its use case is distinct from that of RFCs 7934 and 7844, it doesn’t conflict with them either.

Further, a "recommendation to use stateless in preference to stateful" isn't a prohibition on stateful, Until, stateful is prohibited or all networks are required to provided stateless, a SHOULD for DHCPv6 in the host requirements still seems appropriate to me.

<bhs> +1

---

From: Tim Chown <[email-masked]>
Date: Mon, 17 Jul 2017 07:14:29 +0000

Hi,

In-line...

> On 16 Jul 2017, at 09:25, Timothy Winters <[email-masked]> wrote:
> 
> Hi Brian,
> 
> On Sun, Jul 16, 2017 at 12:06 AM, Brian E Carpenter <[email-masked]> wrote:
> Hi,
> 
> Probably not, we'll remove this in the next draft.  How do you feel about Frame Relay?

At present it seems we’ll leave that in.

> also TSP (RFC5572), and draft-ietf-intarea-gue is in progress. So I wonder

So I think we’ll not ad text here.

> published, it will be mentioned there. If it doesn't get published,

Yes, we’ll leave it a little while to see how 4291-bis pans out.

> OK, this text looks fine to me. 

Or we could just point at RFC8064?

> Since RFC 8028 updates rule 5.5 from RFC 6724 implementations SHOULD implement this rule. 
> 
> Interesting thought (should be RFC7608).   I don't have a problem adding this, I'll check with the co-authors. 

No preference either way here.

Thanks Brian,
Tim

> Now offering testing for SDN applications and controllers in our SDN switch test bed. Learn more today http://bit.ly/SDN_IOLPR
>

---

From: Tim Chown <[email-masked]>
Date: Mon, 17 Jul 2017 09:00:34 +0000

Hi,

In-line...

> On 17 Jul 2017, at 02:52, STARK, BARBARA H <[email-masked]> wrote:
> 

To support Barbara’s comments above, it's worth noting that RFC7844 includes exceptions, specifically in Section 5, stating that anonymity profiles are not always desirable:

5.  Operational Considerations

   The anonymity profiles have the effect of hiding the client identity
   from the DHCP server.  This is not always desirable.  Some DHCP
   servers provide facilities like publishing names and addresses in the
   DNS, or ensuring that returning clients get reassigned the same
   address.

   Clients using an anonymity profile may be consuming more resources.
   For example, when a client changes its link-layer address and
   requests a new IP address, the old IP address is still marked as
   leased by the server.

   Some DHCP servers will only give addresses to pre-registered MAC
   addresses, forcing clients to choose between remaining anonymous and
   obtaining connectivity.

   Implementers SHOULD provide a way for clients to control when the
   anonymity profiles are used and when standard behavior is preferred.

   Implementers MAY implement this control by tying the use of the
   anonymity profiles to that of link-layer address randomization.

Tim

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 17 Jul 2017 13:09:29 +0100

> I don't really know - is it still deployed in the real world? If so,

legacy situations only and it disappeared off the sales catalogues of
most providers 15-20 years ago.  There aren't any good reasons to
include it in the draft.

Nick