FCFS SAVI: First-Come, First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses
draft-ietf-savi-fcfs-14

There are plenty of Discuss points already raised with which I agree.

---

Section 1
"The proposed mechanism..."
It is no longer a proposal.

---

The figure on page 9 has a misalignment.

---

The writeup says:
   There are existing implementations of a very similar feature for
   IPv4.
This is fair enough, but I am surprised to see no reference to this in
the document and no description of the differences.

I cleared. Thanks for addressing my discuss.

Section 2 title - I would prefer to strike "non-normative". I see
no reason for it and the use of this expression is turning into an
IETF fetish. Instead, you can add on to the the Introduction:
"Section 2 gives the background and description of FCFS SAVI,
and Section 3 specifies the FCFS SAVI protocol."

Section 2.6:

   Before creating a SAVI
   binding in the local SAVI database, the SAVI device will send a NSOL
   message querying for the address involved.  Should any host reply to
   that message with a NADV message, the SAVI device that sent the NSOL
   will infer that a binding for that address exists in another SAVI
   device and will not create a local binding for it.  If no NADV
   message is received as a reply to the NSOL, then the local SAVI
   device will infer that no binding for that address exists in other
   SAVI device and will create the local SAVI binding for that address.
   (NOTE that the description included here is overly simplified to
   illustrate the mechanism used to preserve the coherency of the
   binding databases of the different SAVI devices.  The actual SAVI
   mechanism normative specification as described in Section 3 varies in
   the fact that in some cases it is the SAVI device that generates the
   NSOL while in other cases it simply forwards the NSOL generated by
   the end host, and that the SAVI device will send multiple copies of
   the NSOL in order to improve the reliability of the message exchange,
   among other things).

Start with the words, "As a simplified example of how this might work:",
and then strike the parenthetical NOTE entirely.

Section 3 title - strike "normative"

Please expand "DoS" on first use and add an informational reference to RFC 4732.

I cleared my Discuss.  Thank you for addressing my Discuss points.

I support the DISCUSS positions offered by Ralph and Dan.

(1) I don't understand the sentence at the end of 2.1 " Manually
configured IPv6 addresses can be supported by FCFS SAVI, but manual
configuration of the binding on the SAVI device provides higher
security and seems compatible with manual address management."

(2) 2.2 says that "non-compliant" packets can be dropped - there's no
IESG write-up so I'm wondering if this is safe or if there's any
evidence that this would be safe? Has this been implemented and if so
have any results of its effects been published? (I know that's not a
requirement for PS, but in this case, I think it would be very useful
information.)

(3) 2.3 "prove address ownership" is too strong and I think ownership
is the wrong phrase in any case.

(4) I don't understand "FCFS SAVI function relies on state information
binding the source address used in data packets to the binding anchor
that contained the first packet that used that source IP address."
Seems like it needs re-phrasing - "contained the first packet" is the
wrong bit.

(5) The "it" in "CFS SAVI function relies on state information binding
the source address used in data packets to the binding anchor that
contained the first packet that used that source IP address" seems
ambiguous. I'm fairly sure it refers to each SAVI instance rather than
the set of instances in a SAVI perimeter but that should be made
clear.

(6) State machine ascii art - expanding T.O. to timeout (I guess)
would be clearer.

(7) "MLD considerations" - should you s/relay/rely/?

(8) From section 4 on there are more English language errors that
should be fixed, e.g "The attacks against the SAVI device basically
consist on making the SAVI device to consume its resources until it
runs out of them" has two (and maybe 3) errors.  There are also some
similar problems in Appendix A. (I have some marked up on paper so
easiest will be if I try to list any that remain if you rev. the I-D.)

(9) [secdir review nits]
Editorial nits:

- p10: s/because the connect/because they connect/  (twice)
- p10: s/through validating port/through validating ports/
- p11: s/prefixes.A/prefixes. A/
- p13: s/may due/may be due/
- p13: s/packets has been/packets have been/
- p18: s/relay/rely/
- p24: s/coalition/collision/
- p26: s/case fixed/case of fixed/

I support the discusses raised against this document.