Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support
RFC 6089

Note: This ballot was opened for revision 11 and is now closed.

(Jari Arkko) Yes

(Ron Bonica) No Objection

(Stewart Bryant) (was Discuss) No Objection

Comment (2010-05-05)
No email
send info
"The receiver MUST quietly ignore and skip over the option" 

I think that the authors mean silently.

The abbreviations BU, HA, CN, MN and MAP should be expanded on first use.

(Gonzalo Camarillo) No Objection

(Ralph Droms) No Objection

(Adrian Farrel) (was Discuss) No Objection

(Russ Housley) No Objection

(Alexey Melnikov) (was Discuss) No Objection

(Tim Polk) No Objection

Comment (2010-05-06 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I support Sean's discuss issue:  The Security Considerations section should include explicit pointers to the Security Considerations sections in RFCs 3775, 3963, and 5555.

(Dan Romascanu) No Objection

(Peter Saint-Andre) No Objection

(Robert Sparks) No Objection

(Sean Turner) (was Discuss) No Objection

Comment (2010-05-06)
No email
send info
#1) I would like the authors to consider adding the following text (from Tina Tsou's SECDIR review) to the security considerations:

This specification does not open up new fundamental lines of attack on communications between the MN and its correspondent nodes. However, it allows attacks of a finer granularity than those on the basic binding update. For instance, the attacker can divert or replicate flows of special interest to the attacker to an address of the attacker's choosing, if the attacker is able to impersonate the MN or modify a binding update sent by the MN. Hence it becomes doubly critical that authentication and integrity services are applied to binding updates.

(Lars Eggert) (was Discuss) Abstain

Comment (2010-09-08)
No email
send info
Section 2., paragraph 5:
>    Note that per-packet load balancing may have negative impacts on TCP
>    congestion avoidance mechanisms as it is desirable to maintain order
>    between packets belonging to the same TCP connection.  This behaviour
>    is specified in [RFC2702].  Other negative impacts are also foreseen
>    for other types of real time connections due to the potential
>    variations in round trip time between packets.  Moreover, per-packet
>    load-balancing will negatively affect traffic with anti-replay
>    protection mechanisms.  Hence, per-packet load balancing is not
>    envisioned in this specification.

  It'd be even stronger here and say that packet-based load balancing
  causes severe performance issues for almost all kinds of Internet
  transports and applications, and that this specification SHOULD NOT be
  used in this way.


Section 3., paragraph 2:
>       Flow: A flow is a sequence of packets for which the MN desires
>       special handling either by the Home Agent (HA), the Corresponding
>       Node (CN) or the (Mobility Anchor Point) MAP.

  Isn't a flow for the purposes of this specification something more
  restrictive, i.e., a sequence of packets *that can be matched by a
  common traffic selector*?


Section 3., paragraph 5:
>       Flow Identifier: A flow identifier uniquely identifies a flow
>       binding associated with a mobile node.  It is generated by a
>       mobile node and is cached in the table of flow binding entries
>       maintained by the MN, HA, CN or MAP.

  "uniquely identifies a flow" in what scope? I assume not
  Internet-wide.


Section 4.2., paragraph 9:
>          The Flow Identifier field is a 16-bit unsigned integer that
>          includes the unique identifier for the flow binding.  This
>          field is used to refer to an existing flow binding or to create
>          a new flow binding.  The value of this field is set by the
>          mobile node.  FID = 0 is reserved and MUST NOT be used.

  This means a node can have at most 64K flow bindings. It's a large
  number, but not so large that I can see it being sufficient in all
  future corner cases.


Section 5.3.3., paragraph 2:
>    and one or mobe Binding Identifier mobility options identifying

  Nit: s/mobe/more/


Section 6., paragraph 2:
>    Section 4.2.1.4.  Implementations are encouradged to keep binding

  Nit: s/encouradged/encouraged/


Section 8., paragraph 10:
>          identifiction format.

  Nit: s/identifiction/identification/