Subject: comments on draft-ietf-6man-ipv6-subnet-model-03

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Wed, 29 Apr 2009 17:09:51 -0700

Upon request from the author, I've reviewed the I-D, and here are my
comments.

I have one top level comment: I'm okay with removing the following two
bullets from the original "on-link" definition of RFC4861

          - a Neighbor Advertisement message is received for the
          (target) address, or
          - any Neighbor Discovery message is received from the address.

to address security concerns.  But then I'd like to further simplify
the rule of processing incoming NSes by discarding ones if the source
address is not on-link.  Removing the above bullets while allowing
accepting incoming NSes from a non-on-link address (and responding to
them) could make implementation very tricky for very little benefit.

Some implementations have already adopted this "simplification" to
address the security concern, and, realistically, I don't think we can
convince the maintainer to cancel the change and introduce a
trickier patch to support the very minor case.  The end result would
be the same: we'll lose interoperability.  Of course, we could blame
such implementations for being "non compliant", but IMO it's more
productive to plug the tricky corner case as we'll probably never need
it in practice.

Other technical comments:

- Section 1 doesn't explain the motivation of removing the last two
  bullets of on-link definition.  I actually expected such
  incompleteness because it was not in the original goal of this
  draft.  That's why I insisted that this part is in a separate
  document.

- Section 1:
  Due to the tricky implication on on-link vs being neighbor (see
  above), if we wanted to keep it (note that I'm against it) the
  following cannot hold:

     A host only performs address resolution for IPv6 addresses that are
     on-link.

  because the host would have to perform address resolution for a
  "neighbor" but not necessarily an on-link node.  (if we also remove
  the tricky implication, this can be automatically solved:-)

- Section 2: the section title "Host Behavior" is not very indicative
   to me.

- Section 2: I simply didn't understand the following paragraph at
  all.  Please elaborate (I guess I asked the same thing before and it
  hasn't improved)

   2.  Note that Redirects cannot signal that an address is off-link.
   [...]

- Section 3, bullet 3.  I disagree with this bullet as stated above.
  I won't go into further details on this at the moment because it's a
  rather meta level issue.

- Section 3, bullet 6: I don't understand this at all.  Why is this
  mentioned?  Why only multicast?

- Section 3, bullet 7: this rule isn't enforceable.  I thought I
  already pointed it out before (please google it).

- Section 4, last para:

   Using cached on-link determination information without first
   [...]

  This doesn't address my previous concern.  Besides, this is not
  really a "rule" even if it's in the "host rules" section.

- Section 6: I guess there should be a reference to the security
  problem (cert advisory or something).

Editorial comments:

- Section 1 first para
  s/a address/an address/
- Some of the acronyms should be expanded beforehand (ND, RA, etc)
- there are some redundant white spaces, e.g. "on- link" (should be
  on-link)
- Section 3, bullet 4, there seems to be an indentation problem:

          Similarly, the following text from section 6.2.5 of [RFC4861]

  I suspect it's not part of citation.
  
---
JINMEI, Tatuya
Internet Systems Consortium, Inc.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 30 Apr 2009 13:58:18 -0400

Jinmei,

Thanks much for the review.  I think you have some section numbers mixed up from our draft in your review.  I have snipped below all of your comments where I believe section numbers could be wrong.  Could you please go thru the section numbers below and fix them for us and then we'd be happy to respond to your comments.  I think where you say "Section 4" it is Section 3. Likewise for "Section 3, bullet 7" and "Section 3 bullet 6" should be "Section 2, bullet 6 and 7". We really weren't sure about "Section 3, bullet 3" because both sections 2 and 3 in our document have a bullet 3.

- Section 4, last para:

Thanks,

Hemant

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 30 Apr 2009 12:15:12 -0700

At Thu, 30 Apr 2009 13:58:18 -0400,
"Hemant Singh (shemant)" <[email-masked]> wrote:

> Thanks much for the review.  I think you have some section numbers
> mixed up from our draft in your review.  I have snipped below all of
> your comments where I believe section numbers could be wrong.  Could
> you please go thru the section numbers below and fix them for us and
> then we'd be happy to respond to your comments.  I think where you
> say "Section 4" it is Section 3. Likewise for "Section 3, bullet 7"
> and "Section 3 bullet 6" should be "Section 2, bullet 6 and 7". We
> really weren't sure about "Section 3, bullet 3" because both
> sections 2 and 3 in our document have a bullet 3.

Oops, my bad.  I've fixed the reference error below.

>   I won't go into further details on this at the moment because it's a

I meant Section 2, bullet 3 here.

>   mentioned?  Why only multicast?

I meant Section 2, bullet 6 here.

>   already pointed it out before (please google it).

I meant Section 2, bullet 7 here.

> - Section 4, last para:

I meant Section 3 here.

---
JINMEI, Tatuya