Unique IPv6 Prefix per Host
RFC 8273

Received changes through RFC Editor sync (created alias RFC 8273, changed title to 'Unique IPv6 Prefix per Host', changed abstract to 'This document outlines an approach utilizing existing IPv6 protocols to allow hosts to be assigned a unique IPv6 prefix (instead of a unique IPv6 address from a shared IPv6 prefix).  Benefits of using a unique IPv6 prefix over a unique service-provider IPv6 address include improved host isolation and enhanced subscriber management on shared network segments.', changed pages to 10, changed standardization level to Informational, changed state to RFC, added RFC published event at 2017-12-04, changed IESG state to RFC Published)

[Ballot discuss]
I've put in a DISCUSS because I think the point I raise below warrants further discussion, unless the WG already discussed it and concluded otherwise.

Section 7 says:

"However, when combining both IPv6 privacy extensions and a unique
  IPv6 Prefix per Host a reduced privacy experience for the subscriber
  is introduced, because a prefix may be associated with a subscriber,
  even when the subscriber implemented IPv6 privacy extensions RFC4941
  [RFC4941]."

If an operator assigns the same unique prefix to the same host every time the host connects to the network, the unlinkability benefits of using IPv6 privacy extensions are completely negated. It seems reasonable to me for this document to normatively RECOMMEND that operators assign a different unique prefix to a returning host for the purpose of limiting linkability to the lifetime of the host's connection to the network. I'm sure there are exception cases where this wouldn't make sense, and some examples of those could be given. But by default this seems to me like a reasonable recommendation to mitigate the privacy risk introduced by the unique prefix, while the attacks described in Section 1 would also still be mitigated.

Did the WG discuss this?

[Ballot comment]
Two nits:
- Lorenzo: https://mailarchive.ietf.org/arch/msg/v6ops/EbF-7q17N9qy8N4KV2mOMuMY9YY (emphasise the multi addressing)
- Tim: https://mailarchive.ietf.org/arch/msg/v6ops/Fu-b--IA3NkbgvmXET1tygeF920 (should 7217 be mentioned not just old 4862 SLAAC, and on consistency between 8106 and stateless DHCPv6)

I trust the responsible AD's judgement to evaluate if those editorial changes are important enough.

Regards, Benoit

IESG: This is a returning document -- it successfully passed IESG eval 2017-08-17 with one DISCUSS (Suresh, cleared 9/13). I sent it back to the WG for some additional clarifications, and it has now had a second (short) WGLC.  This is a useful document / contribution, and believe that it is ready for publication, but I wanted to give the IESG the chance to weigh in.

[Ballot discuss]
* Section 4

It is not clear what you intend here

"IPv6 Router Advertisement Interval = 300s"

The router advertisement interval is not configured as an absolute value but as minimum and maximum bounds (MinRtrAdvInterval and MaxRtrAdvInterval) which are used to calculate the actual advertisement interval. When the RA is sent from an interface, the actual interval is an uniformly distributed random value between the MinRtrAdvInterval and MaxRtrAdvInterval. At the very minimum you need to clarify if you would like to have this as a lower bound or as an upper bound.

[Ballot comment]
* Section 4

-> I think text is needed here to handle the case where the DNS server is provided in the RA itself  (RFC8106)

"In addition it will use stateless DHCPv6 to get the IPv6 address of the DNS server"

-> I am not sure what is the motivation for this text.

"however it SHOULD NOT use stateful DHCPv6 to receive a service provider managed IPv6 address"

-> This text seems incorrect

"due to the L-bit set, it SHOULD send this traffic to the First Hop Provider Router"

I think it should be the exact opposite. i.e. say *unset* instead of set

"due to the L-bit being unset, it SHOULD send this traffic to the First Hop Provider Router"

[Ballot comment]
I have no technical comments, but a number of editorial comments:

- General: I think this could use another proofreading and/or editing pass for the following issues:
-- Inconsistent tense--especially use of future or present continuous.
-- Wordy and convoluted sentences
-- Use of "/" as a conjunction.

- Abstract:
The abstract is longer and more detailed than is useful. The last paragraph could have stood alone as the abstract.
It's not clear to me if "hosts (subscribers)" means something different than "hosts" in context.

-1:
Please expand "IA_NA" on first use.
s/"This document will focus..."/"This document focuses..."

"As such the use
  of IPv6 SLAAC based subscriber and address management for provider
  managed shared network services is the recommended technology of
  choice, as it does not exclude any known IPv6 implementation."
Does this document make that recommendation, or is that some pre-existing recommendation?


-3: "The Best Current Practice documented in this note is to provide a
  unique IPv6 prefix to hosts/subscribers devices connected to the
  provider managed shared network."

The sentence hard to follow. Consider "This document recommends...".  I'm not sure how to interpret "hosts/subscribers devices"

"Each unique IPv6 prefix can
  function as control-plane anchor point to make sure that each
  subscriber is receiving"
s/"... subscriber is receiving ..."/"... subscriber receives..."



-4: Is "First Hop Provider Router" different than "First Hop Router"?

In the last bullet (L-flag=0), are NEVER and ALWAYS in all-caps expected to have different meaning than if they had normal capitalization?

The sentence starting with "The architected result of designing the RA as documented above..." is convoluted and hard to follow.

"... however it SHOULD NOT use stateful DHCPv6 to receive
  a service provider managed IPv6 address": Is that really a normative requirement, or is it a statement of fact about existing requirements?

"it SHOULD send this traffic
  to the First Hop Provider Router." : statement of fact?

- 5: "To reduce
  undesired resource consumption on the First Hop Router the desire is
  to remove UE/subscriber context in the case of non-permanent UE, such
  as in the case of WiFi hotspots as quickly as possible. "
Convoluted sentence.

"A possible solution is to use a subscriber inactivity timer which, after
  tracking a pre-defined (currently unspecified) number of minutes,
  deletes the subscriber context on the First Hop Router."

s/which/that  (Consider " ... timer that deletes...after a predetermined number of minutes"

-7: "The
  combination of both IPv6 privacy extensions and operator based
  assignment of a Unique IPv6 Prefix per Host provides each
  implementing operator a tool to manage and provide subscriber
  services and hence reduces the experienced privacy within each
  operator controlled domain."

I have trouble following that sentence. Is the point to say that providing tools to manage and provide services reduces privacy in general? As worded, it almost sounds like this is meant as a feature, which I assume is not the case.

[Ballot comment]
Document: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt


I found the discussion of the shared network medium a bit
confusing. As I understand it, the idea is that if we are
on a shared network and we have the same prefix, I might
try to send to you directly. What you want to do is make
that not happen by having each node have a separate prefix.
Correct? If so, perhaps promote this bullet, and also have
it describe the problem and why this provides a solution:

  o  Two devices (subscriber/hosts), both attached to the same provider
      managed shared network should only be able to communicate through
      the provider managed First Hop Router


It's a bit unclear to me how much you are saying that
something is current practice versus how much you are
recommending it. For instance, the abstract reads more
like what you would expect for PS.

  This document outlines an approach utilising existing IPv6 protocols
  to allow hosts to be assigned a unique IPv6 prefix (instead of a
  unique IPv6 address from a shared IPv6 prefix).  Benefits of unique
  IPv6 prefix over a unique IPv6 address from the service provider
  include improved subscriber isolation and enhanced subscriber
  management.

But then S 4 seems to be documenting:

  The IPv6 RA flags used for best common practice in IPv6 SLAAC based
  Provider managed shared networks are:


  The use of a unique IPv6 prefix per UE adds an additional level of
  protection and efficiency as it relates to how IPv6 Neighbor
  Discovery and Router Discovery processing.  Since the UE has a unique
  IPv6 prefix all traffic by default will be directed to the First Hop
  provider router.  Further, the flag combinations documented above
  maximise the IPv6 configurations that are available by hosts
  including the use of privacy IPv6 addressing.

It's not quite clear to me why unique prefixs are needed here if
people set L=0. Is it that people ignore L=0?

Finally, I'm a bit confused about how to read this text about the
L=0 bit in cases where I have multiple devices rather than just one
at the customer prem. Say I have a topology with a home router
and devices behind it. I.e.,

                    Service Provider
                          |
                          |
                        Customer
                        Router
                          |
              +-----------+-----------+
              |          |          |
            Host 1      Host 2      Host 3

I assume what happens here is that the router gets prefix X, assigns
itself XY, and then the Hosts get XA, XB, XC, etc, a la 7278. Is that
right? If so, my question is about packets coming into the Router from
the SP, which have (say) XA.  The text about the L-flag suggests that
the router should send them back to the gateway, but that's clearly
not right. What am I missing?

[Ballot comment]
One nit:

Please consider moving

  Benefits of unique
  IPv6 prefix over a unique IPv6 address from the service provider
  include improved subscriber isolation and enhanced subscriber
  management.

to the first paragraph of the Abstract. I’m assuming that this explains the “needs that have arisen” in the first sentence of the Abstract, of course.

[Ballot comment]
To me this seems approriate for BCP; I'm saying this because this was mentioned in the shepherd-write-up as it was brought up by the gen-art review.

Please also consider the following comment from the gen-art review (Thanks Joel!):
"The issue of status for the document (BCP vs Informational) is for the IESG
  to conclude.  However, even if it is a BCP, as I understand the purpose,
  this document is intended to describe the practices to be used when a
  provider has decided to deploy a /64 per host.  The wording that is chosen
  throughout the document makes it appear that the underlying decision about
  such a deployment is also a recommended practice."
I agree that wording could be made clearer here!

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-ietf-v6ops-unique-ipv6-prefix-per-host-03.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC: Ron Bonica , v6ops@ietf.org, rbonica@juniper.net, draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org, draft-ietf-v6ops-unique-ipv6-prefix-per-host.all@ietf.org, v6ops-chairs@ietf.org, warren@kumari.net
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Unique IPv6 Prefix Per Host) to Best Current Practice


The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document:
- 'Unique IPv6 Prefix Per Host'
  as Best Current
Practice

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-06-06. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  In some IPv6 environments, the need has arisen for hosts to be able
  to utilize a unique IPv6 prefix, even though the link or media may be
  shared.  Typically hosts (subscribers) on a shared network, either
  wired or wireless, such as Ethernet, WiFi, etc., will acquire unique
  IPv6 addresses from a common IPv6 prefix that is allocated or
  assigned for use on a specific link.

  In most deployments today, IPv6 address assignment from a single IPv6
  prefix on a shared network is done by either using IPv6 stateless
  address auto-configuration (SLAAC) and/or stateful DHCPv6.  While
  this is still viable and operates as designed, there are some large
  scale environments where this concept introduces significant
  performance challenges and implications, specifically related to IPv6
  router and neighbor discovery.

  This document outlines an approach utilising existing IPv6 protocols
  to allow hosts to be assigned a unique IPv6 prefix (instead of a
  unique IPv6 address from a shared IPv6 prefix).  Benefits of unique
  IPv6 prefix over a unique IPv6 address from the service provider
  include improved subscriber isolation and enhanced subscriber
  management.


The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-host/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-host/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc6106: IPv6 Router Advertisement Options for DNS Configuration (Proposed Standard - IETF stream)
    rfc4941: Privacy Extensions for Stateless Address Autoconfiguration in IPv6 (Draft Standard - IETF stream)
    rfc4862: IPv6 Stateless Address Autoconfiguration (Draft Standard - IETF stream)
    rfc3315: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (Proposed Standard - IETF stream)

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

This draft is intended for publication as BCP. It doesn't need to be PS
because it doesn't change SLAAC or DHCPv6. However, it does explain
how and why those protocols might be used to assign a a prefix to a host
(as opposed to an address).

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  In some IPv6 environments the need has arisen for hosts to be able to
  utilise a unique IPv6 prefix even though the link or media may be
  shared.  Typically hosts (subscribers) on a shared network, either
  wired or wireless, such as Ethernet, WiFi, etc., will acquire unique
  IPv6 addresses from a common IPv6 prefix that is allocated or
  assigned for use on a specific link.

  In most deployments today IPv6 address assignment from a single IPv6
  prefix on a shared network is done by either using IPv6 stateless
  address auto-configuration (SLAAC) and/or stateful DHCPv6.  While
  this is still viable and operates as designed there are some large
  scale environments where this concept introduces significant
  performance challenges and implications, specifically related to IPv6
  router and neighbor discovery.

  This document outlines an approach utilising existing IPv6 protocols
  to allow hosts to be assigned a unique IPv6 prefix (instead of a
  unique IPv6 address from a shared IPv6 prefix).  Benefits of a unique
  IPv6 prefix compared to a unique IPv6 address from the service
  provider are going from improved subscriber isolation to enhanced
  subscriber management.

Working Group Summary

This draft elicited significant discussion on the WG mailing list, up to
and including the WGLC. All issues have been resolved

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

This draft was reviewed by the shepherd and several members of the WG.

Personnel

  Ron Bonica is the Document Shepherd. Warren Kumari is the Responsible Area
  Director?

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The document is ready for publication. It is a very short document that
requires only a cursory understanding of SLAAC and DHCPv6. In either case,
it is fairly obvious that the procedures described in this document will work
without any protocol changes.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

Additional reviews have been requested from OPSDIR, INTDIR and
GENART. Reviews are due on 4/28 and the document will not appear
on a telechat agenda before then.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

During the GENART Review, Joel Halpren said that the document should
be published as INFORMATIONAL, not BCP. The authors and the WG
felt that it should be BCP. Lacking a clear definition of BCP requirements,
we decided to defer this decision to the IESG.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

Consensus is strong

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

- The document uses 2119 language but doesn't have a reference to RFC 2119
- The document has an obsolete reference to RFC 6106 (obsoleted by 8106)

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A

(13) Have all references within this document been identified as
either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No. All references are to RFCs

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

This document requires no actions from IANA

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

N/A

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

I ran the IETF Nit-check tool