Early Review of draft-ietf-6man-multi-homed-host-06

Request Review of draft-ietf-6man-multi-homed-host
Requested rev. no specific revision (document currently at 10)
Type Early Review
Team Internet Area Directorate (intdir)
Deadline 2016-08-02
Requested 2016-05-20
Authors Fred Baker, Brian Carpenter
Draft last updated 2016-06-08
Completed reviews Secdir Last Call review of -07 by Ben Laurie (diff)
Intdir Early review of -06 by Carlos Bernardos (diff)
Intdir Early review of -06 by Zhen Cao (diff)
Assignment Reviewer Zhen Cao 
State Completed
Review review-ietf-6man-multi-homed-host-06-intdir-early-cao-2016-06-08
Reviewed rev. 06 (document currently at 10)
Review result Ready
Review completed: 2016-06-08



I am an assigned INT directorate reviewer for draft-ietf-6man-multi-
homed-host-06.txt. These comments were written
primarily for the benefit of the Internet Area Directors. Document
editors and shepherd(s) should treat these comments just like they
would treat comments from any other IETF contributors and resolve them
along with any other Last Call comments that have been received. For
more details on the INT Directorate, see 



Thank authors for this work.

Overall, this is a well-written draft. It clearly specifies what a
multi-homed host needs to take into account while making default route
and source address selections, especially when a certain in-path
filter/middleboxes may prevent successful communication.

One cent for discussion as below:

>3.2.  Default Router Selection
>Default Router Selection is modified as follows: A host SHOULD select
>default routers for each prefix it is assigned an address in.
>Routers that have advertised the prefix in its Router Advertisement
>message SHOULD be preferred over routers that do not advertise the

If both routers have not advertised the prefix, how will the host make
the decision?

A normal daily example is a host being connected to the Internet via
one router, and at the same time connected to a VPN to a private
domain which is further connected to global Internet.  If the host
initiates communication with some public internet address(not
advertised by either link), it is sometimes undefined which route to
take because both links connect to that destination.  From my
understanding, route metric will be take into account in this case.  I
do experience different VPN clients behave differently because their
assignment of the VPN link metric.  A note to this case might be
useful for readers.

Many thanks,