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

Hi,

- 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

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

Timothy Winters

2017-07-16 08:25:00 UTC

Hi Brian,

On Sun, Jul 16, 2017 at 12:06 AM, Brian E Carpenter <

Post by Brian E Carpenter
Hi,

- IPv6 over ATM Networks [RFC2492]

Is this still worth mentioning?

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

- IP version 6 over PPP [RFC5072]
In addition to traditional physical link-layers, it is also possible

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

Yes.

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.

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

Thanks, we'll make all those updates.

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.

K, we'll remove the note.

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.

Thanks, we'll update that to Normative.

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

Maybe not :-(

I still have hope.....

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.

Thanks for the feedback.

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.

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

OK, this text looks fine to me.

I like this idea, how about.

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

14. Router-Specific Functionality

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.

Post by Brian E Carpenter
Regards
Brian
--------------------------------------------------------------------
IETF IPv6 working group mailing list
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

Brian E Carpenter

2017-07-16 23:03:57 UTC

Tim,

Trimming this just to your direct questions:

On 16/07/2017 20:25, Timothy Winters wrote:
...

- IPv6 over ATM Networks [RFC2492]

Is this still worth mentioning?

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

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

...

I like this idea, how about.
Since RFC 8028 updates rule 5.5 from RFC 6724 implementations SHOULD
implement this rule.

Looks good.

Thanks,
Brian

Nick Hilliard

2017-07-17 12:09:29 UTC

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

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

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

Tim Chown

2017-07-17 07:14:29 UTC

Hi,

In-line...

Post by Timothy Winters
Hi Brian,
Hi,

- IPv6 over ATM Networks [RFC2492]

Is this still worth mentioning?
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.

- IP version 6 over PPP [RFC5072]
In addition to traditional physical link-layers, it is also possible

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

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.

So I think we’ll not ad text here.

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/.)
Thanks, we'll make all those updates.

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.
K, we'll remove the note.

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.
Thanks, we'll update that to Normative.

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

Maybe not :-(
I still have hope.....

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.
Thanks for the feedback.

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

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.

Or we could just point at RFC8064?

14. Router-Specific Functionality

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.

No preference either way here.

Thanks Brian,
Tim

Post by Timothy Winters
Regards
Brian
--------------------------------------------------------------------
IETF IPv6 working group mailing list
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
--------------------------------------------------------------------
IETF IPv6 working group mailing list
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Lorenzo Colitti

2017-07-16 09:31:41 UTC

Post by i***@ietf.org
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

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.

Erik Kline

2017-07-16 10:13:15 UTC

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

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.

Nick Hilliard

2017-07-16 11:20:01 UTC

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

Lorenzo Colitti

2017-07-16 11:25:10 UTC

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.

Job Snijders

2017-07-16 12:12:08 UTC

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

Nick Hilliard

2017-07-16 12:14:02 UTC

Post by Lorenzo Colitti
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.

"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

Sander Steffann

2017-07-16 12:53:26 UTC

Hi,

Post by Nick Hilliard

Post by Lorenzo Colitti
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.

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

+1

Cheers,
Sander

Lorenzo Colitti

2017-07-16 13:47:39 UTC

Post by Nick Hilliard
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.

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?

Nick Hilliard

2017-07-16 14:50:26 UTC

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

Morizot Timothy S

2017-07-16 15:36:59 UTC

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 ***@google.com<mailto:***@google.com> wrote:
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.

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

Brian E Carpenter

2017-07-16 22:59:33 UTC

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.

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

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

Brian

Morizot Timothy S

2017-07-17 00:14:53 UTC

Post by Morizot Timothy S

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.

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

David Farmer

2017-07-16 14:43:04 UTC

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.

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:***@umn.edu
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>
===============================================

David Farmer

2017-07-16 14:54:34 UTC

Post by David Farmer

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

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:***@umn.edu
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
===============================================

STARK, BARBARA H

2017-07-17 01:52:01 UTC

On Sun, Jul 16, 2017 at 6:25 AM, Lorenzo Colitti <***@google.com<mailto:***@google.com>> wrote:
On Sun, Jul 16, 2017 at 1:20 PM, Nick Hilliard <***@foobar.org<mailto:***@foobar.org>> 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

Tim Chown

2017-07-17 09:00:34 UTC