Skip to main content

Multiple Interfaces and Provisioning Domains Problem Statement
RFC 6418



(Jari Arkko)

No Objection

(Alexey Melnikov)
(Ron Bonica)
(Sean Turner)
(Stewart Bryant)

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

Lars Eggert
Discuss (2010-08-23)
Section 3., paragraph 1:
>        2.  Interfaces of a MIF host can provide different
>            characteristics (e.g. round-trip time, least cost, better
>            bandwidth, etc....).  So, user, applications or network
>            provider may wish to influence routing to take benefit of
>            this heterogeneity.  However, with current host
>            implementations, neither the Type-of-Service nor path
>            characteristics can be taken into account in the routing
>            table.

  DISCUSS: I don't think MIF can solve this problem. Yes, interfaces are
  the first hops into *paths* of different characteristics, but what
  service quality an application sees across a path depends on the
  destination, the transport protocol in use and the communication
  patterns of the application. There is nothing here that can be
  optimized without taking these into account.
Comment (2010-08-23)
INTRODUCTION, paragraph 4:
>    of its provisioning domain.  Some configuration objects are global to

  Nit: s/domain/domains/

Section 1., paragraph 1:
>    A multihomed host have multiple provisioning domains (via physical

  Nit: s/have/has/

Section 1., paragraph 4:
>    values from each provisioning domains, such as different DNS servers

  Nit: s/from/for/

Section 3.1., paragraph 1:
>    [RFC5113] is out of scope of this document.  Moreover, lower layer

  Nit: s/is/are/

Section 3.2., paragraph 2:
>    The host maintains a route cache table where each entry contains the
>    local IP address, the destination IP address, Type-of-Service and
>    Next-hop gateway IP address.  The route cache entry would have data
>    about the properties of the path, such as the average round-trip
>    delay measured by a transport protocol.

  Modern stacks don't store transport info in the route cache anymore.
  Suggest to remove the last sentence.

Section 3.2., paragraph 3:
>    As per [RFC1122], two models are defined:
>    o  The "Strong" host model defines a multihomed host as a set of
>       logical hosts within the same physical host.  In this model a
>       packet must be sent on an interface that corresponds to the source
>       address of that packet.

  And it will only be received on that interface, too.

Section 3.2., paragraph 4:
>    o  The "Weak" host model describes a host that has some embedded
>       gateway functionality.  In the weak host model, the host can send
>       and receive packets on any interface.

  This doesn't really make the distinction clear. A weak host can send
  and receive packets ***addressed to or from any of its source
  addresses on any of its interfaces***.

Section 3.5., paragraph 2:
>    Some application protocols do referrals of IP addresses and port
>    numbers for further exchanges.

  A referral also includes the transport protocol to be used.

Section 2., paragraph 0:
>    2.  For the IP1 address family, H1 has one default route (R1, R2) per
>        network (N1, N2).  IP1 is reachable by both networks, but N2 path
>        has better characteristics, such as better round-trip time, least
>        cost, better bandwidth, etc....  These preferences could be
>        defined by user, by the provider, by discovery or else.  H1 stack
>        uses R1 and tries to send through I1.  IP1 is reached but the
>        service would be better by I2.

  Note that "better" here is entirely dependent on what kind of traffic
  is to be exchanged with the destination, i.e., it is transport
  protocol and application dependent. General preferences of any sort
  are therefore likely to be wrong.

Section 11., paragraph 23:
>    [RFC4477]  Chown, T., Venaas, S., and C. Strauf, "Dynamic Host
>               Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack
>               Issues", RFC 4477, May 2006.

  Nit: Unused Reference: 'RFC4477'
Jari Arkko Former IESG member
Yes ()

Adrian Farrel Former IESG member
(was Discuss) No Objection
No Objection (2011-04-21)
Thank you for the series of revisions to this I-D which I believe go far enough to allow me to clear my Discuss.
Alexey Melnikov Former IESG member
No Objection
No Objection ()

Dan Romascanu Former IESG member
No Objection
No Objection (2010-08-25)
This is an useful document. The comments below are not blocking, but in case they are considered they could improve readability: 

1. In section 3.1 the following statement is made: 

>  Network discovery and selection on lower layers as defined by
   [RFC5113] is out of scope of this document.  Moreover, lower layer
   interaction such as IEEE 802.21 is also out of scope.

It would be good to be more exact about what is IEEE 802.21 - for example 

s/lower layer interaction such as IEEE 802.21/handover and interoperability between lower layer networks such as the mechanisms defined in IEEE 802.21/

An informative reference to IEEE 802.21 would also be in place. 

2. Expanding acronyms at their first occurance would be useful.

3. The OPS-DIR review performed by Menachem Dodge also included a number of useful editorial comments which I suggest to consider.
Ralph Droms Former IESG member
(was Discuss) No Objection
No Objection (2010-08-25)
Some of the symptoms don't derive from the stated operational environments.  For example, in section 4.1:

   3.  H1 keeps only one set of DNS server addresses from the received
       configuration objects and kept S2 address.  H1 sends the DNS
       query for to S2.  S2 asks its upstream DNS
       and gets an IP address for  However, the
       IP address is not the same one S1 would have given.  Therefore,
       the application tries to connect to the wrong destination host,
       or to the wrong interface of the latter, which may imply security
       issues or result in lack of service.

seems to be in conflict with the constraint at the top of the section that 'name "" [...] is within the private namespace of S1 and only resolvable by S1'; that is, if the constraint holds, H1 would not get a resolution for by sending a resolution query to S2.

Also in section 4.1:

   5.  H1 has resolved an FQDN to locally valid IP address when
       connected to N1.  After movement from N1 to N2, the host tries to
       connect to the same IP address as earlier, but as the address was
       only locally valid, connection setup fails.  Similarly, H1 may
       have received NXDOMAIN for an FQDN when connected to N1.  After
       movement from N1 to N2, the host should not assume the FQDN
       continues to be nonexistent.

what does "movement from N1 to N2" mean?

Still in section 4.1:

   A MIF host may also be provisioned with a Interface-specific suffix
   search list ([I-D.ietf-mif-current-practices]).  In this situation,
   if H1 sends DNS query on I1 using the search list tied to I2, the
   namespace could be not valid on I1 and the name could be not

isn't the described host behavior clearly a bug in the host stack?

From Andrew Sullivan, dns-directorate review:

 First, this is an implicit recognition that the DNS namespace is not
 actually a single, unified namespace.  I think that's just
 acknowledging the facts in the world, but I know there are people
 opposed to that.

 Second, it seems to be setting up the mif WG to be trying to "solve"
 the DNS split-views problem.  I think this effectively means that
 we're (i.e. the dns-dir crowd) will need to keep on top of MIF.
Robert Sparks Former IESG member
No Objection
No Objection (2010-08-24)
Some very minor editorial suggestions:

Is there a missing word (I think "may" at "may have") in the first sentence of
the introduction?

Should the first sentence of 3.6 start with "An Application"?
Ron Bonica Former IESG member
No Objection
No Objection ()

Russ Housley Former IESG member
No Objection
No Objection (2010-08-26)
  My concern is already captured in DISCUSS posiotns held by Ralph,
  so I am not going to pile on.  However, I do want to make it known
  that I also have the same concern.  (Note the same concern was
  raiseed by Roni Even in his Gen-ART Review dated 24-Aug-2010.)
Sean Turner Former IESG member
(was Discuss) No Objection
No Objection ()

Stewart Bryant Former IESG member
No Objection
No Objection ()