Subject: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC

From: [email-masked]
Date: Sun, 21 Feb 2016 11:00:08 -0800

This is to initiate a two week working group last call of
http://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem.  
Please read it now. If you find nits (spelling errors, minor suggested
wording changes, etc), comment to the authors; if you find greater
issues, such as disagreeing with a statement or finding additional
issues that need to be addressed, please post your comments to the
list.

We are looking specifically for comments on the importance of the
document as well as its content. If you have read the document and
believe it to be of operational utility, that is also an important
comment to make.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 22 Feb 2016 21:42:52 -0300

> believe it to be of operational utility, that is also an important

I support the publication of this document as an RFC. I believe it
contains valuable information.

Detailed comments have been posted in a separate thead, and I expect
most of such comments to be addresses before the document is shipped to
the IESG.

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 24 Feb 2016 15:58:23 +0900

> http://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem.

Hi,

technical review follows. For the avoidance of doubt: the intent of this
review is to ensure that if we publish this draft, it is correct; while I
do not particularly support this draft, I don't strongly oppose it either.

Substantive points:

1. I disagree with the statement "It is unclear whether hosts should
initiate DHCPv6 by themselves if there are no RAs at all." There is not
really point in using DHCPv6 without RAs. This is because DHCPv6 does not
configure prefixes, only addresses without prefix lengths, and therefore an
address assigned by DHCPv6 either has no prefix length or a prefix length
of /128. See dhcpv6bs ticket 68:
http://trac.tools.ietf.org/group/dhcpv6bis/ticket/68

So starting DHCPv6 without an RA is pointless because even if you get an
address, you can't use to talk to anything. Thus, I don't think there is
any ambiguity here, since one of the alternatives doesn't make sense. That
said, if we do still want to say this is ambiguous, then we should replace
"ambiguous" with "unspecified", and add something about the fact that
DHCPv6 without RAs is useless, such as:

===
It should be noted that DHCPv6 by itself only communicates address
information, not reachability information. The fact that an address was
received from DHCPv6 does not imply that that address can reach any
destination outside the host itself. Therefore, even if DHCPv6 succeeds
without an RA, the resulting configuration is not useful for network
communication.
===

The draft should also note that clients
following draft-ietf-dhc-anonymity-profile are not expected to start DHCPv6
without first receiving an RA, because draft-ietf-dhc-anonymity-profile
says that they SHOULD NOT do so.

2. Where the draft discusses changes in the M flag and says "it is clear
whether the host should start DHCPv6 or not", it should instead say that
the host is under no obligation to do so, first because implementing DHCPv6
is not a MUST, and second because the M flag is advisory.

3. Where the draft says "It could be reasonably deduced that M flag should
be independent from A flag" - again, the text should mention that for a
client following draft-ietf-dhc-anonymity-profile, that's not true.

4. "RDNSS" is used both to indicate the RDNSS option and to indicate DNS
server IP addresses. The two things should be called different names.

5. In several places, the draft says:

   (This divergence is only for those operations systems which
   support[RFC6106].)

Because RFC6106 is as much a SHOULD in the IPv6 node requirements as
DHCPv6, the draft should also tag everything related to DHCPv6 with:

   (This divergence is only for those operations systems which
   support[RFC3315].)

Or, if you prefer, note early on in the draft (e.g., in the introduction)
that DHCPv6 is a MUST and if hosts do not implement DHCPv6 then there is no
ambiguity.

6. The security considerations section is unrelated to the main purpose of
the draft, which is to "describe divergent host behaviours [and]
operational problems that the divergent behaviors might cause". These
security issues documented in this draft exist regardless of divergent
behaviour. They are security issues that address other unspecified parts of
the implementations, not the main issue in this draft, which is overlap
between DHCPv6 and SLAAC.

7. The draft makes no mention of Android. Perhaps it should say that
Android does not have this problem because it does not implement DHCPv6?

Minor issues:

1. In the introduction, but SLAAC first and DHCPv6 second, because in the
IPv6 node requirements, SLAAC is MUST and DHCPv6 is a SHOULD.

Regards,
Lorenzo

---

From: [email-masked]
Date: Wed, 24 Feb 2016 09:59:30 +0100 (CET)

> DHCPv6 without RAs is useless, such as:

I can absolutely see this point of view. On the other hand - given that
the M-bit is only a hint: If I were a CPE manufacturer, I might find it
perfectly rational to *always* start DHCPv6 (for simplicity's sake). I
believe we've seen more than one CPE model doing exactly that.

Steinar Haug, AS2116

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 24 Feb 2016 18:32:59 +0000

CPE are both hosts and routers. Their specification is defined in RFC 7084.

With respect to the host (address assignment) side:

   WAA-6:   If the IPv6 CE router receives a Router Advertisement
            message (described in [RFC4861]) with the M flag set to 1,
            the IPv6 CE router MUST do DHCPv6 address assignment
            (request an IA_NA option).

With respect to the router (prefix delegation) side:

   WPD-4:  By default, the IPv6 CE router MUST initiate DHCPv6 prefix
           delegation when either the M or O flags are set to 1 in a
           received Router Advertisement (RA) message.  Behavior of the
           CE router to use DHCPv6 prefix delegation when the CE router
           has not received any RA or received an RA with the M and the
           O bits set to zero is out of scope for this document.

Though for the PD case, it doesn't say what to do if there is no RA (out of scope!).

So, for the CPE (with respect to the host side, which is what draft-ietf-v6ops-dhcpv6-slaac-problem is about), it agrees with Lorenzo's analysis.

- Bernie

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, February 24, 2016 4:00 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC

> initiate DHCPv6 by themselves if there are no RAs at all." There is 
> not really point in using DHCPv6 without RAs. This is because DHCPv6 
> does not configure prefixes, only addresses without prefix lengths, 
> and therefore an address assigned by DHCPv6 either has no prefix 
> length or a prefix length of /128. See dhcpv6bs ticket 68:
> So starting DHCPv6 without an RA is pointless because even if you get 
> an address, you can't use to talk to anything. Thus, I don't think 
> there is any ambiguity here, since one of the alternatives doesn't 
> make sense. That said, if we do still want to say this is ambiguous, 
> then we should replace "ambiguous" with "unspecified", and add 
> something about the fact that

I can absolutely see this point of view. On the other hand - given that the M-bit is only a hint: If I were a CPE manufacturer, I might find it perfectly rational to *always* start DHCPv6 (for simplicity's sake). I believe we've seen more than one CPE model doing exactly that.

Steinar Haug, AS2116

_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Thu, 25 Feb 2016 00:11:48 +0000

I agree that starting DHCPv6 without an RA is pointless / useless. And the draft should just state that. 

But if the draft is referring to any existing RFC, then it is reasonable to say the behavior not being specified (or unclear). Just avoid hair-splitting. 

Cheers,
Rajiv Asati
Distinguished Engineer, Cisco Services

> On Feb 24, 2016, at 1:33 PM, Bernie Volz (volz) <[email-masked]> wrote:
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 25 Feb 2016 00:50:59 +0000

On some links, invoking DHCPv6 immediately without waiting for an RA is
natural and provides all the configuration information needed by the client.

Thanks - Fred
[email-masked]

> From: v6ops [mailto:[email-masked]] On Behalf Of Rajiv Asati (rajiva)
> Sent: Wednesday, February 24, 2016 4:12 PM
> To: Bernie Volz (volz)
> Cc: [email-masked]
> > I can absolutely see this point of view. On the other hand - given that the M-bit is only a hint: If I were a CPE manufacturer, I might
> find it perfectly rational to *always* start DHCPv6 (for simplicity's sake). I believe we've seen more than one CPE model doing exactly
> that.
> >
> > Steinar Haug, AS2116
> >

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 25 Feb 2016 10:13:24 +0900

Which links? Even on point-to-point links such as PPP interfaces or 3GPP
networks, routing requires an RA.

On Thu, Feb 25, 2016 at 9:50 AM, Templin, Fred L <[email-masked]>
wrote:

> > But if the draft is referring to any existing RFC, then it is reasonable
> to say the behavior not being specified (or unclear). Just avoid hair-
> > splitting.
> >
> > Cheers,
> > Rajiv Asati
> > > So, for the CPE (with respect to the host side, which is what
> draft-ietf-v6ops-dhcpv6-slaac-problem is about), it agrees with
> > Lorenzo's analysis.
> > >
> > > - Bernie
> > >
> > > I can absolutely see this point of view. On the other hand - given
> that the M-bit is only a hint: If I were a CPE manufacturer, I might
> > find it perfectly rational to *always* start DHCPv6 (for simplicity's
> sake). I believe we've seen more than one CPE model doing exactly
> > that.
> > >
> > > Steinar Haug, AS2116
> > >

---

From: <[email-masked]>
Date: Thu, 25 Feb 2016 08:25:19 +0100

If I remember right, then I ‘ve seen CPE implementations which fired DHCPv6 Solicits and RS in parallel just to speed up the provisioning process.
OBo

From: v6ops [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: Donnerstag, 25. Februar 2016 02:13
To: Templin, Fred L
Cc: [email-masked]
Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC

Which links? Even on point-to-point links such as PPP interfaces or 3GPP networks, routing requires an RA.

On Thu, Feb 25, 2016 at 9:50 AM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:
On some links, invoking DHCPv6 immediately without waiting for an RA is
natural and provides all the configuration information needed by the client.

Thanks - Fred
[email-masked]<mailto:[email-masked]>

> From: v6ops [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Rajiv Asati (rajiva)
> Cc: [email-masked]<mailto:[email-masked]>
> > On Feb 24, 2016, at 1:33 PM, Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>> wrote:
> >
> > From: v6ops [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
> > To: [email-masked]<mailto:[email-masked]>
> > Cc: [email-masked]<mailto:[email-masked]>
> > [email-masked]<mailto:[email-masked]>
> > [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
v6ops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Fernando Gont <[email-masked]>
Date: Thu, 25 Feb 2016 04:57:38 -0300

Hi, Lorenzo,

On 02/24/2016 03:58 AM, Lorenzo Colitti wrote:
> really point in using DHCPv6 without RAs. This is because DHCPv6 does
> not configure prefixes, only addresses without prefix lengths, and
> therefore an address assigned by DHCPv6 either has no prefix length or a
> prefix length of /128. See dhcpv6bs ticket 68:
> address, you can't use to talk to anything.

Yes, we should close that gap. Sad that a religious war essentially ends
up with *two* mandatory protocols. Because in many scenarios, you need both.

> Thus, I don't think there is
> any ambiguity here, since one of the alternatives doesn't make sense.
> That said, if we do still want to say this is ambiguous, then we should
> replace "ambiguous" with "unspecified", and add something about the fact
> that DHCPv6 without RAs is useless, such as:
> 
> ===

This is fine, although "reachability" can be misleading.

> 3. Where the draft says "It could be reasonably deduced that M flag
> should be independent from A flag" - again, the text should mention that
> for a client following draft-ietf-dhc-anonymity-profile, that's not true.

Which again brings the question of why such document is not updating the
corresponding spec.

> Android does not have this problem because it does not implement DHCPv6?

That's kind of misleading ;-).  That could be read to mean that it's
actually a good thing that android does not support ipv6.
(FWIW, Nodes that don't do v6 don't have this problem, either.)

> Minor issues:
> 
> 1. In the introduction, but SLAAC first and DHCPv6 second, because in
> the IPv6 node requirements, SLAAC is MUST and DHCPv6 is a SHOULD.

+1 (after s/but/put/)

Cheers,

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 25 Feb 2016 17:04:55 +0900

> up with *two* mandatory protocols. Because in many scenarios, you need

Well, that's not something we can do in this WG.

> Which again brings the question of why such document is not updating the

I think you'll have to take that up with the IESG at this point. Obviously
they took the position that doing so was not necessary; I suspect that
position is far from conteroversial.

> (FWIW, Nodes that don't do v6 don't have this problem, either.)

We can say whatever we can get WG consensus on, but I think we have to say
something about Android, because there are more Android devices than most
of the platforms that you do say something about.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 25 Feb 2016 15:27:44 +0000

Hi Lorenzo,

On AERO links, the default router and DHCPv6 server are always one and the same.
So, when the DHCPv6 server delegates a prefix, the client already knows that it is
the default router without having to receive an RA.

Thanks – Fred

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Wednesday, February 24, 2016 5:13 PM
To: Templin, Fred L
Cc: Rajiv Asati (rajiva); Bernie Volz (volz); [email-masked]
Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC

Thanks - Fred

---

From: Mark Smith <[email-masked]>
Date: Fri, 26 Feb 2016 05:56:06 +1100

> the default router without having to receive an RA.

Which I suppose means:

- default router redundancy is achieved by having multiple DHCPv6 servers

- DHCPv6 servers MUST be on the same link as the AERO clients, in
other words, there is no place in the AERO for DHCPv6 relays

One concern I have with binding DHCPv6 server and default router
functionality is that upgrading the DHCPv6 server software (e.g., to
support a new option) will typically also disrupt all of the clients
traffic being forwarded by the co-located router, including clients
that will get no benefit from the new option.

I've thought that one of the benefits of decoupling application
protocol understanding from the network (i.e., application protocol
traffic rides over the top of the Internet to between the edges) is
that upgrading applications and their protocols doesn't require
upgrading the network to support them.

I've subsequently thought that the same model should be applied to and
deployed for higher layer and application configuration, not just the
application protocols themselves. It has been to DHCPv6, in the sense
that DHCPv6 relays are DHCPv6 option transparent. However, when a
DHCPv6 client and server are colocated as an alternative to a DHCPv6
relay, then the DHCPv6 option transparency has gone.

https://tools.ietf.org/html/draft-smith-v6ops-ce-dhcpv6-transparency-00#section-2

Regards,
Mark.

>> > the M-bit is only a hint: If I were a CPE manufacturer, I might

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 25 Feb 2016 19:24:07 +0000

Hi Mark,

> From: Mark Smith [mailto:[email-masked]]
> Sent: Thursday, February 25, 2016 10:56 AM
> To: Templin, Fred L
> Cc: Lorenzo Colitti; [email-masked]

Actually, I mis-spoke. It is the client's relationship with the DHCPv6 relay that
matters. It just so happens in the AERO design that Lightweight DHCPv6 Relay
Agent per RFC6221 is used. So, from the client's perspective it looks like the
DHCPv6 server is on the same link but in fact there is a LDRA as bump-in-the-
stack in the path. So, to answer your first question, default router
redundancy is achieved by having multiple DHCPv6 relays which in the
case of AERO usually results in multiple DHCPv6 servers (one for each relay).
 
> that will get no benefit from the new option.

It is the IA_PD lifetime of the delegated prefix from the DHCPv6 server
that the client uses to determine the default router lifetime. If the
DHCPv6 server needs to be upgraded, won't it issue a Reconfigure
or something like that? And, then the client will once again receive
a valid IA_PD lifetime.

> upgrading the network to support them.

Not sure what you mean by that, but wouldn't rebooting the hybrid
router/relay/server amount to the same thing as rebooting and
ordinary IPv6 router?

> relay, then the DHCPv6 option transparency has gone.

Right, and see above for my revised explanation. The DHCPv6 relay
is indeed included even when it is just a bump-in-the-stack.

> https://tools.ietf.org/html/draft-smith-v6ops-ce-dhcpv6-transparency-00#section-2

I see what you mean. With AERO, the DHCPv6 server maintains only the
IA_PD lease database the same as any ordinary DHCPv6 server, and the
relay is transparent in the network. If the DHCPv6 server needs to be
restarted, then the lease database needs to be retained but the
clients and router will continue to function normally until the server
comes back online. Or, if the router/relay/server crashes altogether,
the clients can simply fail over to another router/relay/server.

Thanks - Fred

---

From: 神明達哉 <[email-masked]>
Date: Fri, 26 Feb 2016 14:18:13 -0800

> issues that need to be addressed, please post your comments to the

I've read the 06 version of the draft.  I don't think this document is
ready for publication, yet.  (I'm feeling dejavu of repeating the same
comments I made many months ago...) while I see potential of this doc
to be useful, it seems to have many issues in its current form such as
technically inaccurate (to me at least) statements or the mixture of
possibly useful information and very minor and operationally
unrealistic/hypothetical nit picking.  IMO, publishing it with these
issues would rather introduce confusion and/or misunderstanding.  More
specific comments follow.

- General: it's true that there's spec ambiguity regarding the M/O
  flags.  I also see different implementations can behave differently,
  possibly because of such ambiguity.  But simply because there's some
  ambiguity or behavior difference doesn't immediately mean these
  should be officially described in a document like an RFC (whose
  publication cost is expensive).  IMO, the ambiguity and/or behavior
  difference must lead to actual operational issues that matter in
  practice.  In that sense most of the points described in this
  document seem to be too minor (see specific discussions below).  I
  see at least a couple of points that may have real operational
  impact, such as Divergence 1-3 in Section 4.1 (which would make
  coexistence of SLAAC and DHCPv6-based address allocation impossible
  for some implementations, and I heard some operators want this type
  of operation).  My personal suggestion is to focus on such real
  issues, removing all minor points.  The resulting document might
  become very thin, but could be much more useful and readable.

- Abstract

   [...]  These are
   the M, O, and A flags, which by definition are advisory, not
   prescriptive.

  I don't think the A flag is "advisory", and I believe it's pretty
  clear from the specification (even if there might be an
  implementation that misunderstands it).  Will discuss this in more
  detail below.

- Section 1

   (A flag is
   also advisory by definition in standard, but it is quite prescriptive
   in implementations according to the test results in the appendix.)

  I'd like to know exactly what "advisory by definition in standard"
  means since IMO A flag is perfectly "prescriptive".  Section 5.5 of
  RFC4862 states:

   [...] Creation of
   global addresses as described in this section SHOULD be locally
   configurable.  However, the processing described below MUST be
   enabled by default.

  and subsection 5.5.3 specifies:

    a)  If the Autonomous flag is not set, silently ignore the Prefix
      Information option.

  and how to configure a global address from the prefix (the
  corresponding PIO should have the A flag on because of "a)").

  And, in fact, the draft itself seems to admit it's actually
  prescriptive and well understood by implementors accordingly.

- Section 3, item 1)

      [...]  More specifically, it is
      unclear whether RA (with M=1) is required to trigger DHCPv6; in
      other words, It is unclear whether hosts should initiate DHCPv6 by
      themselves if there are no RAs at all.

  The latter half of this looks a bit awkward.  "in other words"
  suggests rephrasing the same thing, but "whether hosts should
  initiate DHCPv6 without RA" is not really the same thing as
  "whether RA (with M=1) is required for DHCPv6".  perhaps "for
  example" or "in particular" might be a better phrase here.

  And, one minor nit: s/It is/it is/

- Section 3, item 3)

         When flags are in transition, e.g. the host is already SLAAC-
         configured, then M flag changes from FALSE to TRUE, it is not
         clear whether the host should start DHCPv6 or not; or vise
         versa, the host is already configured by both SLAAC and DHCPv6,
         then M flag change from TRUE to FALSE, it is also not clear
         whether the host should turn DHCPv6 off or not.

  I don't understand why we need the condition of "the host is already
  SLAAC-configured".  With or without, it's already (intentionally)
  clear per RFC4861/4862 whether the host should start DHCPv6 or not.
  Same for the latter part (regarding SLAAC).

  I'd also note that the very original intent of RFC2461/2462 was
  clear on this point: a change of M flag from FALSE to TRUE means the
  host should start DHCPv6; a change of M flag from TRUE to FALSE
  should not affect ongoing DHCPv6 sessions.  While it's true that
  RFC4861/4862 are (again, intentionally) silent on these, I'd say if
  an implementor actually wants to use this flag it's most natural to
  follow what 2461/2462 stated.

- Section 3, item 3)

         When one address configuration method is off, that is, the A
         flag or M flag changes from TRUE to FALSE, it is not clear
         whether one host should immediately release the corresponding
         address or just retain it until the lifetime expires.

  At least for the A flag, I'd say it's pretty obvious that host MUST
  NOT do that.  Otherwise the two-hour rule introduced in RFC4862
  would simply be pointless; an on-link attacker could easily force
  hosts to invalidate addresses by sending forged RAs with the PIO
  clearing the A flag.  True, it's not explicitly documented in the
  RFCs, but that doesn't immediately mean "it's not clear".  Is there
  actually an implementation that invalidates SLAAC-configured address
  on receiving a corresponding PIO with the A flag being 0?

- Section 3, item 4)

      But for A flag and O flag, ambiguity could possibly happen.  For
      example, when A is FALSE (when M is also FALSE) and O is TRUE, it
      is not clear whether the host should initiate a stand-alone
      stateless DHCPv6 session.

  Personally, I would consider a mere implementation defect.  I don't
  think any of the spec ambiguity can lead to this awkward behavior.
  For some kind of information document especially in the O&M area, it
  might note there is such a broken implementation.  But in this
  particular case I don't see it very useful in a practical sense
  either, since if both A and M are FALSE this network is almost
  unusable anyway.  This topic rather seems to be an artificial
  nitpicking.  (I vaguely recall we discussed this point on an earlier
  version of the draft, but I don't remember the conclusion, if any)

- Section 4.2, Divergence 2-1: same as the previous point.

- Section 4.2, Divergence 2-2

         1) Getting RDNSS from both the RAs and the DHCPv6 server, and
         the RDNSS obtained from the router has a higher priority.

  This doesn't seem to be very relevant to the main subject of this
  draft, i.e, it doesn't seem to be related to the M/O/A flags.  And,
  as this draft itself points out, RFC6106 (and its bis) clearly
  specifies the precedence on this point; this implementation is
  simply and clearly broken in terms of the spec conformance, and I
  don't see much value in pointing it out in this document.

- Section 4.2, Divergence 2-2

  It's not clear to me whether this is really about DNS
  configuration.  Isn't it just a variant of Divergence 1-3 of Section
  4.1, i.e., some implementation doesn't start DHCPv6 if it
  receives/has received PIO with A being TRUE?

- Section 5.2

   Ideally, these steps could be initiated by multicasting RA messages
   onto the link that is being renumbered.  Sadly, this is not possible,
   because the RA messages may elicit a different behavior from each
   host.

  This description is vague to me.  Can the problem(s) be more
  specific?

- Section 6

  Overall, I don't understand how this is specific to the main subject
  of this document (unclear specification of M/O flags, and some
  deviant implementation behavior regarding these, sometimes also
  related to the value of the A flag).  The security considerations in
  this section generally seem to be applicable with or without the
  M/O/A issues.  That is, an on-link attacker can do many bad things
  when RA or DHCPv6 isn't protected.

- Section 6

   If an attacker wants to perform MiTM (Man in The Middle) using a
   rogue DNS while legitimates RAs with the O flag set are sent to
   enforce the use of a DHCPv6 server, the attacker can spoof RAs with
   the same settings with the legitimate prefix (in order to remain
   undetectable) but advertising the attacker's DNS using RDNSS.

  I'm not sure if this is explicitly worth noting in the context of
  this document (see also the previous general point).  This type of
  attacker could also spoof DHCPv6 responses, so with or without the
  ambiguity of the RA flags and implementation variation, the attacker
  can force victim hosts to use forged RDNSS.

- Section 6

   Fedora 21 and Centos 7 behaviour cannot be explored for a MiTM attack
   using a rogue DNS information either, since the one obtained by the
   RAs of the first router has a higher priority.

  I don't understand this sentence (btw, I guess s/explored/exploited/).

- Appendix: to be honest I've not closely read the appendices.  But
  I guess that could actually be a point to be addressed: the
  information provided here seemed to be too unorganized, just listing
  random things, possibly including many duplicates.  I hope this
  section will be more well-organized and readable.  Also, even though
  I understand it doesn't have to be a comprehensive implementation
  list, I would consider it biased (and even possibly misleading) that
  it doesn't include any of open source BSD variants, while it talks
  about result of multiple flavors of Linux.  BSDs are also widely
  deployed IPv6 implementation developed differently from Linux, and
  anyone can examine the behavior at source-code level (like Linux,
  but not like Windows or MacOS or iOS).  If we keep this appendix,
  I'd strongly suggest including at least one open-source BSD variant.

--
JINMEI, Tatuya

---

From: joel jaeggli <[email-masked]>
Date: Sat, 27 Feb 2016 20:29:01 -0800

On 2/25/16 12:04 AM, Lorenzo Colitti wrote:
> On Thu, Feb 25, 2016 at 4:57 PM, Fernando Gont <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> I think you'll have to take that up with the IESG at this point.
> Obviously they took the position that doing so was not necessary; I
> suspect that position is far from conteroversial.
>  
> 
> We can say whatever we can get WG consensus on, but I think we have to
> say something about Android, because there are more Android devices than
> most of the platforms that you do say something about.

implemntors are under no obligation to do anything in particular by the
IETF. if a citation of differences is useful then by all means add it.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 29 Feb 2016 09:32:34 +0900

On Sat, Feb 27, 2016 at 7:18 AM, 神明達哉 <[email-masked]> wrote:
>
> (I'm feeling dejavu of repeating the same comments I made many months
> ago...)

That's does tend to happen when a document is resubmitted without
substantial changes.

while I see potential of this doc to be useful, it seems to have many
> issues in its current form such as technically inaccurate (to me at least)
> statements or the mixture of possibly useful information and very minor and
> operationally
> unrealistic/hypothetical nit picking.  IMO, publishing it with
> these issues would rather introduce confusion and/or misunderstanding.
> More specific comments follow.
>

What Jinmei said.

More concerningly - as Jinmei points out, these comments were exactly the
same on previous versions of the draft, and nothing was done to address
them. I think this is not the first time, either. It's like a
merry-go-round: the draft gets submitted, gathers the same substantial
objections, goes away, gets resubmitted with minor changes. What's the plan
here? Keep doing that until folks get tired of objecting?

Cheers,
Lorenzo

---

From: "Liubing (Leo)" <[email-masked]>
Date: Mon, 29 Feb 2016 09:32:16 +0000

Hi Lorenzo,

Replies inline.

From: v6ops [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: Monday, February 29, 2016 8:33 AM
To: 神明達哉
Cc: [email-masked]
Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC

On Sat, Feb 27, 2016 at 7:18 AM, 神明達哉 <[email-masked]<mailto:[email-masked]>> wrote:
(I'm feeling dejavu of repeating the same comments I made many months ago...)

That's does tend to happen when a document is resubmitted without substantial changes.

while I see potential of this doc to be useful, it seems to have many issues in its current form such as technically inaccurate (to me at least) statements or the mixture of possibly useful information and very minor and operationally
unrealistic/hypothetical nit picking.  IMO, publishing it with these issues would rather introduce confusion and/or misunderstanding.  More specific comments follow.

What Jinmei said.

More concerningly - as Jinmei points out, these comments were exactly the same on previous versions of the draft, and nothing was done to address them. I think this is not the first time, either. It's like a merry-go-round: the draft gets submitted, gathers the same substantial objections, goes away, gets resubmitted with minor changes. What's the plan here? Keep doing that until folks get tired of objecting?
[Bing] We paid lot of effort on the last couple of revisions. We added more tests on DNS configuration (RFC6106) as well as more OSes, and not a few editorial work.
I admit these revision isn’t what you expected, but since your suggestion was a huge modification to the draft, I’m not very sure it’s safe/good to do that as a WG document.

Let me quote some of substantial objections that made during the last WGLC of this draft Oct. 2014.
"In its current form, the described problems seem to be too artificial, hypothetical, or minor to be important to me.  And that's why I didn't regard this draft as that important."
"Actually, I guess there should be more pragmatic examples of operational issues because of the described divergence and I wonder whether these minor cases are really the only things we can imagine (although I don't have a specific idea right now).  If these sections can be revised with more convincing examples, I would be more supportive about publishing it." – by Jinmei
"Given that, it would seem to make more sense for this document to focus only on the results of the investigation (i.e., only the appendix), and a concluding statement that notes that implementations differ in their behaviour, and that renumbering behaviour is substantially different." – by you (Lorenzo).

In this WGLC, Jinmei provided more suggestion:
“In that sense most of the points described in this  document seem to be too minor (see specific discussions below).  I  see at least a couple of points that may have real operational  impact, such as Divergence 1-3 in Section 4.1 (which would make  coexistence of SLAAC and DHCPv6-based address allocation impossible for some implementations, and I heard some operators want this type of operation).  My personal suggestion is to focus on such real issues, removing all minor points. The resulting document might become very thin, but could be much more useful and readable.”

Say, if I revise as you and Jinmei suggested, a very thin document, I concern a bit on the following things:

-        The divergence we observed should be only part of the potential problems. So, if we remove the ambiguity analysis content, people might think the documented problems are all the problems.

-        How can we judge the current reported problems as “minor” in the future? My original thought was, just reported all the problems we have found, we don’t select them for the readers. Readers would decide by themselves.

I’d like to hear your further opinions. Thanks.

Bing

Cheers,
Lorenzo

---

From: 神明達哉 <[email-masked]>
Date: Mon, 29 Feb 2016 11:00:28 -0800

At Mon, 29 Feb 2016 09:32:16 +0000,

> "In its current form, the described problems seem to be too
> artificial, hypothetical, or minor to be important to me.  And
> that's why I didn't regard this draft as that important."

> "Actually, I guess there should be more pragmatic examples of
> operational issues because of the described divergence and I wonder
> whether these minor cases are really the only things we can imagine
> (although I don't have a specific idea right now).  If these
> sections can be revised with more convincing examples, I would be
> more supportive about publishing it." – by Jinmei

These two still seem to stand (to me, at least).  The first one is
almost exactly the same as what I said this time.

> “In that sense most of the points described in this  document seem
> to be too minor (see specific discussions below).  I  see at least a
> couple of points that may have real operational  impact, such as
> Divergence 1-3 in Section 4.1 (which would make  coexistence of
> SLAAC and DHCPv6-based address allocation impossible for some
> implementations, and I heard some operators want this type of
> operation).  My personal suggestion is to focus on such real issues,
> removing all minor points. The resulting document might become very
> thin, but could be much more useful and readable.”

This is a kind of text that rephrases the second point in my 2014
comment.  Note that the result may not necessarily be "very thin";
there may be many practical issues than I originally and currently
thought/think.  My general point is that it's not useful very much to
just arbitrarily list spec ambiguity and implementation divergence;
for them to be useful, it should come with explanations why that
matters in a practical sense.

> -        How can we judge the current reported problems as “minor” in the future? My original thought was, just reported all the problems we have found, we don’t select them for the readers. Reader…

You basically seem to argue that arbitrarily listing the ambiguity and
implementation divergence may still be useful for some reason (that I
don't understand).  I simply disagree on that, but that's probably up
to WG decision in the end.

--
JINMEI, Tatuya

---

From: Enno Rey <[email-masked]>
Date: Mon, 29 Feb 2016 22:27:35 +0100

Hi,

jumping in as one of the guys who contributed some of the material & analyses.

> > whether these minor cases are really the only things we can imagine

I don't have the impression these cases are "minor". Actually the - from my observations being involved in IPv6 deployments in large organizations for some years - main reason for the lack of IPv6 in enterprise space is this exact spec ambiguity and implementation divergence. If you can't enforce a homogeneous (and at least somewhat predictable) behavior in a sufficiently large scale network with (OS-wise) heterogenous nodes most ops people just won't deploy $PROTOCOL.

Documenting this ambiguity on the base of practical samples seems hence a very valid approach to me, as (this is what we hope) most readers will pretty much immediately understand the (vast) operational ramifications.

best

Enno

---

From: 神明達哉 <[email-masked]>
Date: Mon, 29 Feb 2016 18:04:01 -0800

At Mon, 29 Feb 2016 22:27:35 +0100,

> I don't have the impression these cases are "minor". Actually the -
> from my observations being involved in IPv6 deployments in large
> organizations for some years - main reason for the lack of IPv6 in
> enterprise space is this exact spec ambiguity and implementation
> divergence. If you can't enforce a homogeneous (and at least
> somewhat predictable) behavior in a sufficiently large scale network
> with (OS-wise) heterogenous nodes most ops people just won't deploy
> $PROTOCOL.

> Documenting this ambiguity on the base of practical samples seems
> hence a very valid approach to me, as (this is what we hope) most
> readers will pretty much immediately understand the (vast)
> operational ramifications.

In a sense I think we are on the same page.  I already stated there's
at least one case where I see the operational point.  For cases I
thought minor I basically tried to leave comments on why I thought
they were minor, unrealistic, or too hypothetical.  If you, the
authors, and someone else can show practical cases to explain why they
matter, I'm happy to see it ship.  That's all what I've been asking
for these periods.

--
JINMEI, Tatuya