Skip to main content

Last Call Review of draft-ietf-v6ops-unique-ipv6-prefix-per-host-03

Request Review of draft-ietf-v6ops-unique-ipv6-prefix-per-host-02
Requested revision 02 (document currently at 13)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2017-04-28
Requested 2017-04-12
Requested by Ron Bonica
Authors John Jason Brzozowski , Gunter Van de Velde
Draft last updated 2017-06-06
Completed reviews Genart Last Call review of -02 by Joel M. Halpern (diff)
Intdir Last Call review of -02 by Jouni Korhonen (diff)
Opsdir Last Call review of -03 by Tim Chown (diff)
Genart Last Call review of -03 by Joel M. Halpern (diff)
Secdir Last Call review of -03 by Watson Ladd (diff)
Opsdir Last Call review of -02 by Sarah Banks (diff)
Genart Telechat review of -07 by Joel M. Halpern (diff)
Assignment Reviewer Tim Chown
State Completed
Review review-ietf-v6ops-unique-ipv6-prefix-per-host-03-opsdir-lc-chown-2017-06-06
Reviewed revision 03 (document currently at 13)
Result Has Issues
Completed 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



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


“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

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”

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?


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.


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

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

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


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


Maybe add a note on isolation benefits in security considerations?