Subject: comments on draft-pioxfolks-6man-pio-exclusive-bit-01

From: 神明達哉 <[email-masked]>
Date: Tue, 28 Mar 2017 08:41:35 -0700

Some random comments and questions on
draft-pioxfolks-6man-pio-exclusive-bit-01:

- What should the host do if the X flag changes from on to off?

- Is there any intent to provide a larger prefix (i.e. smaller plen)
  than the prefix whose length is used for the traditional SLAAC?  For
  example, is it part of the intended usage to advertise a /56 with
  X=on when /64 is the length for SLAAC in that link?  If so, the
  following interpretation of Section 4.2.2 may not be really
  reasonable:
   o  interpret the A bit as it it were 1 (A=1)
  In fact, the X flag allows newer hosts that understand the flag to
  do more than the traditional A flag means: the host can generate an
  address on a different interface than the receiving interface of the
  RA, and it can even re-advertise the prefix in a "downstream" link.
  This is so even if we assume the traditional SLAAC prefix length.

- Perhaps this draft should say routers SHOULD NOT set the L flag of a
  PIO if it sets the X flag.

- I don't follow the following part of section 4.2.2.2:

   from an exclusive prefix to any available interface; it is not
   required to configure the address on the link over which the PIO-X RA
   was received (i.e. it is under no obligation to form addresses such
   that they would be classified as on-link (according to the definition
   in <RFC5942> section 4, item 1).

  The item of RFC5942 is this:

   1.  The assignment of an IPv6 address -- whether through IPv6
       stateless address autoconfiguration [RFC4862], DHCPv6 [RFC3315],
       or manual configuration -- MUST NOT implicitly cause a prefix
       derived from that address to be treated as on-link and added to
       the Prefix List.  A host considers a prefix to be on-link only
       through explicit means, such as those specified in the on-link
       definition in the Terminology section of [RFC4861] (as modified
       by this document) or via manual configuration.  Note that the
       requirement for manually configured addresses is not explicitly
       mentioned in [RFC4861].

  First off, this items is not a "definition" but a requirement.
  Secondly, my interpretation of the requirement is just that we
  cannot assume a particular prefix as on-link derived from an
  address.  I don't see a clear relationship between this and the
  draft text, which states that the host can configure an address on a
  different interface.

  BTW, there's a missing closing parenthesis in the text.

--
JINMEI, Tatuya

---

From: Philip Homburg <[email-masked]>
Date: Tue, 28 Mar 2017 19:20:33 +0200

In the context of DHCPv6 and RA, it is often brought up that there 
should (ideally) be only one way of doing something.

Given how much this looks like DHCPv6 PD, maybe this draft should have
a clearer section why this does not duplicate DHCPv6 PD.

In Section 1, if I mentally replace 'X bit' with DHCPv6 PD then just about
everything there is still true.

The draft doesn't seem to even try to describe why DHCPv6 PD doesn't work.

---

From: Erik Kline <[email-masked]>
Date: Tue, 28 Mar 2017 11:10:08 -0700

This was a piece of feedback we received in Seoul.  I hadn't updated the
document until last night (just posted now).

I've added a small section describing some of the differences in semantics
with 3633.

On 28 March 2017 at 10:20, Philip Homburg <[email-masked]>
wrote:

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: [email-masked]
Date: Tue, 28 Mar 2017 15:01:44 -0500

>  PIO if it sets the X flag.

I think this mechanism is fundamentally incompatible with a set L flag.
So that should be a MUST NOT set and MUST ignore on receive.

Cheers,
Ole