Subject: [v6ops] Last Call: <draft-ietf-v6ops-unique-ipv6-prefix-per-host-03.txt> (Unique IPv6 Prefix Per Host) to Best Current Practice

From: The IESG <[email-masked]>
Date: Tue, 23 May 2017 12:41:43 -0700

The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document:
- 'Unique IPv6 Prefix Per Host'
  <draft-ietf-v6ops-unique-ipv6-prefix-per-host-03.txt> 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
[email-masked] mailing lists by 2017-06-06. Exceptionally, comments may be
sent to [email-masked] 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)

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 25 May 2017 16:12:25 -0700

On Tue, May 23, 2017 at 12:41 PM, The IESG <[email-masked]> wrote:

> final comments on this action.

 I think this is a desirable way to configure public IPv6 network access
and support the publication of this document as BCP. I see a couple issues
that probably need to be resolved before publication:

1. Off-link flag.

   If the UE/
   subscriber desires to send anything external including other UE/
   subscriber devices (assuming device to device communications is
   enabled and supported), then, due to the L-bit set, it SHOULD send
   this traffic to the First Hop Provider Router.

I think the document might need to say what the First Hop Provider Router
needs to do in the case when it the host sends the router a packet for a
destination in the same prefix as the host. (This can happen since L=0.) It
seems that the router could simply turn around and send an NS for that IPv6
address, which would likely just end up going back to the host. Seems like
we might want to avoid that.

2. If this document is to be a BCP, then the RA timers should probably not
be a part of this document. They are over-prescriptive, and they conflict
with the suggestions in RFC 7772, which says:

      In order to limit the amount of power used to receive Router
      Advertisements to, say, 2% of idle power (i.e., to impact idle
      battery life by no more than 2%), the average power budget for
      receiving RAs must be no more than 0.1 mA, or approximately 7 RAs
      per hour.

That argues for an RA interval of > 500 seconds, which is half the power
consumption of the value in this document (300 seconds).

Cheers,
Lorenzo

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 27 May 2017 08:24:39 +1200

Hi,

I should have noticed this during the v6ops discussions, but I didn't,
sorry.

This draft cites RFC4862 (SLAAC) and mentions Router Advertisements
(without also citing RFC4861, which is possibly a mistake). Those
documents do not specify the subnet prefix length. So the draft
shouldn't assume a particular prefix length either. We all know that
it's usually 64 today, but that doesn't affect the argument made by
the draft. We need consistency with RFC 7608 (BCP 198).

Regards
   Brian Carpenter

On 24/05/2017 07:41, The IESG wrote:
> 
> The IESG has received a request from the IPv6 Operations WG (v6ops)
> to consider the following document: - 'Unique IPv6 Prefix Per Host' 
> <draft-ietf-v6ops-unique-ipv6-prefix-per-host-03.txt> 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 [email-masked] mailing lists by 2017-06-06.
> Exceptionally, comments may be sent to [email-masked] instead. In
> either case, please retain the beginning of the Subject line to allow
> automated sorting.
> 
> Abstract
> 
> 
> 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 
> 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.
> 
> 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)
> 
> 
> 
> _______________________________________________ v6ops mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops .
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 26 May 2017 20:24:28 -0700

On 26 May 2017 13:24, "Brian E Carpenter" <[email-masked]>
wrote:

So the draft
the draft.

It's always /64 for all addresses starting with binary 000, which cannot be
assigned to hosts in a real network because they are unallocated space.

We need consistency with RFC 7608 (BCP 198).

No, we don't. RFC 7608 is about forwarding, not address assignment.

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 30 May 2017 11:14:36 +0300

Le 27/05/2017 à 06:24, Lorenzo Colitti a écrit :
> On 26 May 2017 13:24, "Brian E Carpenter"
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>> So the draft shouldn't assume a particular prefix length either. We
>> all know that it's usually 64 today, but that doesn't affect the
>> argument made by the draft.
>
>
> It's always /64 for all addresses starting with binary 000, which
> cannot be assigned to hosts in a real network because they are
> unallocated space.
>

But forwarded packets reach assigned addresses.

Some situations can be unfortunate, such as forwarding a /65 to an 
address containing a 64bit IID.

Consistency is desirable.

Alex

> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: 神明達哉 <[email-masked]>
Date: Tue, 30 May 2017 11:51:17 -0700

At Sat, 27 May 2017 08:24:39 +1200,

> the draft. We need consistency with RFC 7608 (BCP 198).

It looks like this draft has the commonly seen confusion I tried to
clarify in my own draft: draft-jinmei-6man-prefix-clarify-00

Specifically, in Section 4 v6ops-unique-ipv6-prefix-per-host-03
states:

   This
   RA contains two important parameters for the EU/subscriber to
   consume: (1) a /64 prefix and (2) flags.
[...]
   o  A-flag = 1 (The UE/subscriber can configure itself using SLAAC)
[...]
   o  L-flag = 0 (The UE/subscriber is off-link, which means that the
      UE/subscriber will ALWAYS send packets to its default gateway,
      even if the destination is within the range of the /64 prefix)

Since A-flag=1 and L-flag=0, this /64 prefix is an "SLAAC subnet
prefix" but not an "on-link prefix" (using the terminology introduced
in draft-jinmei-6man-prefix-clarify-00).  And, in that sense, the
"which means..." part could even be misleading in that it might read
as if this (SLAAC subnet) prefix were somehow related to an on-link
prefix.

I'd also note that "The UE/subscriber is off-link" is not accurate.
When L=0 "the advertisement makes no statement about on-link or
off-link properties of the prefix" (RFC4861 Section 4.6.2).  See below
for a specific suggestion to fix it.

As for the reference to the specific number of 64, I think it's okay
with this clarification, the fact that that's the only possible SLAAC
subnet prefix length today in practice, and the intended status of
this document (BCP).

But I also tend to agree with Brian in that this document could be
more clarified to avoid confusing and/or misleading readers.  My high
level suggestion is:

- clearly state that the prefix in this document is a kind of "SLAAC
  subnet prefix" but not an "on-link prefix".  I understand "SLAAC
  subnet prefix" may not be the best choice since this document
  doesn't limit the address configuration method to SLAAC - hence "a
  kind of".  But the main point is that it's better to explicitly
  clarify the prefix is one and the only one of the two kinds of
  prefixes advertised via RA PIO.  With this clarification, and fixing
  the error I pointed out above, the description for the L-flag would
  look something like this:

   o  L-flag = 0 (the prefix is not an on-link prefix, which means
      that the UE/subscriber will NEVER assume destination addresses
      that match the prefix are on-link and will ALWAYS send packets
      to those addresses to its default gateway.)

- if it refers to a specific (SLAAC subnet) prefix length of 64,
  explain that it's the SLAAC subnet prefix length derived from the
  current addressing architecture for unicast IPv6 addresses starting
  with the binary value 000 (and those are only addresses used in
  production today).  It might also note that future specification may
  or may not introduce a different prefix length for different ranges
  of addresses, but that's out of scope of the document as a BCP.

--
JINMEI, Tatuya