Last Call Review of draft-ietf-v6ops-unique-ipv6-prefix-per-host-03
review-ietf-v6ops-unique-ipv6-prefix-per-host-03-opsdir-lc-chown-2017-06-06-00

• Status
• Email expansions
• History

• Versions
• 00

Review
review-ietf-v6ops-unique-ipv6-prefix-per-host-03-opsdir-lc-chown-2017-06-06

I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments. 

This document describes the rationale and a BCP mechanism by which UEs in a shared network (such as WiFi, or in a DC) can be assigned a unique IPv6 prefix rather than just receiving a single address.

Overall, I believe the document to be Ready with Issues, and I support its publication when these have been answered/resolved.

The issues I have with the document are:

1. While I support the idea, I’m not sure if its use is mature enough as yet to be BCP status. I appreciate this draft morphed from an unitive personal draft that described at least one specific deployment, but some assurance of maturity is perhaps desirable?

2. The document seems to want to say “do this with SLAAC”, but has a few contradictory mentions in it of DHCPv6, e.g. at one point saying use RFC6106 for DNS options, and elsewhere stateless DHCP. It says it’s a method that all UEs can use, but (as evidenced by a long thread elsewhere on v6ops or 6man) RDNSS support in RAs is not mandatory, or implemented by all platforms.

3. The L=0 flag statement is perhaps a little misleading.  As per RFC4861, “L=0 means the advertisement makes no statement about on-link or off-link properties of the prefix. If the L flag is not set a host MUST NOT conclude that an address derived from the prefix is off-link.”  Some clarity here  might improve the text, e.g. say that because no assumption can be made, packets would be sent to the gateway.

4. There’s an assumption of /64; perhaps useful to explicitly call this out given the recent long discussion on the “classless” draft. i.e. it’s a MUST given the current address architecture, but hardcoding it forever should be avoided. 

Nits:

p.2 

“satified by UE” -> “satisfied by the UE” (and expand UE here rather than on the next line).

p.3 

“per RFC7934” -> “, as described in RFC7934” 

The “In addition…” sentence seems to duplicate the “During the time…” sentence?  Remove one or merge the two.

Does SLAAC not exclude any known IPv6 implementation? What about RFC6106 support?

In Section 2, the third bullet says “and configuration mechanisms”, yet the doc is essentially saying use SLAAC?  Is it really supporting a wide range, when just one method is recommended in Section 1?

The fifth bullet point could call out isolation explicitly.  And add a “,” after “shared network”

The sixth bullet - change “neighborship” to “neighbor”, and correct “managent” typo.

Could you add a bullet point on user benefits here?  And what about minimising need for IPv6 NAT?

The intro says a benefit is “enhanced subscriber management”, so that might be more explicitly mentioned here too?

p.3

In Section 4 para 1, RFC6106 (or RFC 8106 now) is not universally implemented, or mandated in specs; should it be explicitly mentioned here? Is the intent to be all-RA based, or use stateless DHCP?

In para 2, is the “and/or DHCPv6” really meant?  Again I’m not clear if the BCP is meant to be SLAAC-only, or is allowing DHCPv6 as well.  Perhaps clarify early in the document and be consistent in the text.

p.5

Delete closing ) on first bullet.

First para - “to how” -> “to”

Add reference to RFC4861, given RA flags are used in the text.

Cite RFC7934 here, to support multiple addressing requirement (it’s in your references).

Para 2, it says use stateless DHCPv6 (and not RFC6106) - consistency point again.

Section 5 - I assume the RAs are unicast here too?  Any scalability concerns if so? 

p.6 

Do we need to set fixed RA timers here?  Are these really BCP for all scenarios?

Not convinced an idle timer is a good thing; what happens if a UE was idle and then restarts using a prefix that might then have been allocated somewhere else?  Shouldn’t the RA timers be honoured instead, just like a DHCP lease?

RFC4941 is repeated in its reference (delete one instance).

p.7

Maybe add a note on isolation benefits in security considerations?