Subject: 6MAN WG Last Call - draft-ietf-6man-multi-homed-host-03.txt

From: Bob Hinden <[email-masked]>
Date: Wed, 3 Feb 2016 14:28:07 -0800

This message starts a two week 6MAN Working Group Last Call on advancing:

       Title           : Routing packets from hosts in a multi-prefix network
       Authors         : Fred Baker
                         Brian Carpenter
       Filename        : draft-ietf-6man-multi-homed-host-03.txt
       Pages           : 13
       Date            : 2015-12-16

   https://tools.ietf.org/html/draft-ietf-6man-multi-homed-host-03

as a Proposed Standard.  Substantive comments and statements of support for publishing this document should be directed to the mailing list.  Editorial suggestions can be sent to the authors.  This last call will end on 17 February 2016.

Best regards,
Ole & Bob

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 3 Feb 2016 23:06:40 +0000

> On Feb 3, 2016, at 2:35 PM, Bob Hinden <[email-masked]> wrote:
> 
> Brian, Fred,
> 
> I started the w.g. last call.  I read the draft again, looks fine overall.  I think it would helpful if it was clearer as to what the update is for RFC4861.  Having done some updates a few times recently, it better to be very clear what the change is.
> 
> I like the “Bob” and “Alice” host names.  Maybe it should be “Ole” and “Bob” :-)

The text in question is, at least,

   Note that, apart from ensuring that a message with a given source
   address is given to a first-hop router that appears to know about the
   prefix in question, this specification is consistent with [RFC4861].
   Nevertheless, implementers of Sections 5.2, 6.2.3, 6.3.4 and 8 of RFC
   4861 will need to extend their implementations accordingly.  This
   specification is fully consistent with [RFC6724] and implementers
   will need to add support for its Rule 5.5.  Hosts that do not support
   these features may fail to communicate in the presence of filters as
   described above.

Section 5.2 basically says that on-link prefixes should result in local traffic ("the next hop address is the destination address") and off-link prefixes operate as described in 6.3.6. Based on that, I think this draft is primarily proposing an inserted step in 6.3.6:

0) IF the source address is a member of a prefix being advertised to the host in an RA, the set of routers being considered as possible next hops is limited to the set of routers advertising the prefix, as opposed to "all neighboring routers".

(which there may be a better way of wording)

Regarding 6.2.3 and 6.2.4, I need to defer to my co-author; I'm not sure what he had in mind. It may have to do with the RIO/PIO/DIO considerations in the draft.

In Section 8, there is a limitation on the set of routers a router might redirect to: it MUST be among the set of routers advertising the indicated prefix in its RA, or the redirecting router must in some other way know that it has the information necessary for SADR routing.

If putting words directly into draft-ietf-6man-multi-homed-host would help you with a 4861bis, we can do that.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 4 Feb 2016 13:24:18 +1300

> 0) IF the source address is a member of a prefix being advertised to the host in an RA, the set of routers being considered as possible next hops is limited to the set of routers advertising the pr…

Yes, that seems right.

> Regarding 6.2.3 and 6.2.4, I need to defer to my co-author; I'm not sure what he had in mind. It may have to do with the RIO/PIO/DIO considerations in the draft.

The point is that solicited and unsolicited RAs should be sent and handled
even if both L and A are zero. I think it was Jinmei who pointed out that
some devices would not do this without a code update. That's the last paragraph
on https://tools.ietf.org/html/draft-ietf-6man-multi-homed-host-03#page-6

Do we need to add more?

    Brian

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: 神明達哉 <[email-masked]>
Date: Thu, 4 Feb 2016 11:35:01 -0800

At Wed, 3 Feb 2016 14:28:07 -0800,
Bob Hinden <[email-masked]> wrote:

> as a Proposed Standard.  Substantive comments and statements of
> support for publishing this document should be directed to the
> mailing list.  Editorial suggestions can be sent to the authors.
> This last call will end on 17 February 2016.

I think this version is basically good enough for publication.

I have some comments on the latest version.  I don't think they are
blocking issues but may be better addressed before sending it to the
IESG.

- Some of my previous comments seem to be still open.  Although I
  already stated I wouldn't insist, it's not clear whether they were
  rejected as a result or just overlooked, so I'm re-raising them
  here: https://mailarchive.ietf.org/arch/msg/ipv6/42QPrrvdShflkz06tn3vdw33iEo
  The seeming open points are:
  + whether to move the host-model discussion to an appendix
  + about the term "addressless"

- Section 3.1

   As described in [RFC4191] and [RFC4861], a Router Advertisement may
   contain zero or more Prefix information Options (PIOs), zero or more
   Route Information Options (RIOs), or a Default Router List.

  I'm not sure if I can understand the "or a Default Router List"
  part.  If it means 'Router Advertisement may contain...a Default
  Router List', it doesn't make sense since an RA (or any of its
  options) doesn't contain such a list (Default Router List is
  something that a host maintains based on the content of RA).

- Section 3.1: likewise, the use of 'a default router list' in the
  following sentence is confusing, too:

   [...]  In a multi-
   homed network implementing source/destination routing, the
   interpretation of a default router list or an RIO has to be modified
   with the words "if the source address is in one of the prefixes I
   advertise in a PIO".

- Section 3.1

   Bob's first hop routers are Bob-A (to upstream ISP A advertising
   prefix A') and Bob-B (to upstream network B and advertising prefix
   B').

  I'd suggest something like PA and PB instead of A' and B'.  It may
  be a matter of taste, but to me X and X' refer to different
  instances of the same kind of concept (like both are addresses or
  both are prefixes), so the current notation is confusing.

- Section 3.4

   There is potential for adverse interaction with any off-link Redirect
   (Redirect for a GUA destination that is not on-link) message sent by

  Is there any particular intent about why we specially say "GUA" here
  instead of, e.g., just "a global destination"?  For example, does it
  intend to exclude ULAs?  If so, why?  In case of ULAs, while the
  proposed host behavior may be less critical with ULAs in practice, I
  don't see any technical reason why we can't use it for ULAs.

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 5 Feb 2016 11:46:23 +1300

Jinmei-san,

Thanks for the review. I guess we will not update draft until the WGLC
expires, but my personal comments are below.

>   + whether to move the host-model discussion to an appendix

My personal choice is not to move it, but I would certainly do so
if that was the WG's preference.

Ah, you said:

>> BTW, "an addressless interface" may not be the best term, since in
>> IPv6 any interface should have at least a link-local address.
>> Something like "a link-local-only interface" would be more accurate.

Yes, that is better in an IPv6 document.

>   something that a host maintains based on the content of RA).

I think you're correct.

>    with the words "if the source address is in one of the prefixes I

This is correct, isn't it? It applies to what the host has stored in
its default router list and to any new RIOs that it receives. It could
be phrased more carefully, I agree.

>   both are prefixes), so the current notation is confusing.

OK

>   don't see any technical reason why we can't use it for ULAs.

To me it's clear that both "GUA" and "global" include ULAs, because ULAs
are defined to have global scope. Do you think there is a formal
difference between "GUA" and "global"? If so, is it documented?

Thanks
     Brian

---

From: 神明達哉 <[email-masked]>
Date: Fri, 5 Feb 2016 09:06:53 -0800

At Fri, 5 Feb 2016 11:46:23 +1300,

> if that was the WG's preference.

Okay.

> >   something that a host maintains based on the content of RA).

Then I guess the sentence will have to be revised, but I can't suggest
anything specific as I don't understand the original intent.  Does
this "Default Router List" perhaps actually means the source IPv6
address of the RA (which will be maintained in the Default Router List
of the receiving host)?

> be phrased more carefully, I agree.

Maybe one source of confusion comes from the fact that this paragraph
starts talking about the content of an RA.  So one possible way to
improve the text would be to revise it focusing on hosts' conceptual
data structures rather than RAs that populate these structures.

On re-reading the text again, I've also noticed a few more glitches:

   [...] In their
   original intent, these indicate general information to a host: [...]
   "you might create or be configured with an address in this prefix", ...

Technically, "you might create an address in this prefix" is a matter
of RFC4862, so I think it should be referenced with RFC4191 and
RFC4861.

Also, I'm not sure if "you might be configured with an address in this
prefix" is part of the "original intent".  While it would be usually
the case that a global address manually configured or by DHCPv6 is in
a prefix advertised in a PIO (and normally with L=1), I would rather
consider it operational reality rather than an "original intent" of
these RFCs.

I think I can suggest alternate text to address some or all of these
points, but to do so I'd like to know the answer to the previous
point.

> difference between "GUA" and "global"?  If so, is it documented?

It's probably not so clearly documented, but, for example, RFC4193 has
this text:

   It is expected that they would share the same Subnet IDs with
   provider-based global unicast addresses, if they were being used
   concurrently [GLOBAL].

(Here "they" means local IPv6 addresses) To me this sounds like if you
explicitly say a "global unicast address" it can implicitly indicates
the address is not a local addresses.

On the other hand, I (personally) don't feel such ambiguity about the
term "a global IPv6 address" since, as you noted above, ULAs have the
global scope.

Going back to my original comment, I now see there was no specific
intent in the use of GUA.  Then I suggest revising this

to

   (Redirect for a global destination that is not on-link) message sent by

to avoid possible confusion.  The latter doesn't explicitly say it's a
unicast destination, but I believe it's obvious from the context (the
destination of a redirect cannot be a multicast address).

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 6 Feb 2016 08:22:28 +1300

> address of the RA (which will be maintained in the Default Router List

I think we should simply delete ", or a Default Router List". That list
is created and maintained by the host, as you say.

    Brian

---

From: 神明達哉 <[email-masked]>
Date: Tue, 9 Feb 2016 11:13:59 -0800

At Sat, 6 Feb 2016 08:22:28 +1300,

> is created and maintained by the host, as you say.

Okay, then my personal suggestion for the entire paragraph would be:

   As described in [RFC4191] and [RFC4861], a Router Advertisement may
   contain zero or more Prefix information Options (PIOs), or zero or more
   Route Information Options (RIOs).  In their
   original intent, these indicate general information to a host: "this
   is your default router", "you might create an address in this
   prefix", or "this router would be a good place to
   send traffic directed to a given destination prefix".  In a multi-
   homed network implementing source/destination routing, the
   interpretation of default router or an RIO has to be modified
   with the words "if the source address is in one of the prefixes I
   advertise in a PIO".  Additionally, the PIO must be reinterpreted to
   also imply that the advertising router would be a reasonable first
   hop for any packet using a source address in any advertised prefix.

--
JINMEI, Tatuya

---

From: Mark Smith <[email-masked]>
Date: Wed, 10 Feb 2016 11:40:44 +1100

On 10 February 2016 at 06:13, 神明達哉 <[email-masked]> wrote:
>    is your default router",

Actually, only the router lifetime field indicates that the RA is
coming from a default router or not.

>"you might create an address in this

---

From: 神明達哉 <[email-masked]>
Date: Wed, 10 Feb 2016 09:49:49 -0800

At Wed, 10 Feb 2016 11:40:44 +1100,

> coming from a default router or not.

Right, and "this" in "this is your default router" is actually (or
more accurately) the source IPv6 address of the Router Advertisement,
rather than something "contained" in it (as an option).  So the above
suggested text could still sound a bit awkward, but to me it seemed
just good enough and trying to make it super accurate wouldn't be
worth the resulting verbosity.  If you want to make it perfect,
though, I'm not opposed to it - feel free to suggest your own text.

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 11 Feb 2016 08:30:11 +1300

> though, I'm not opposed to it - feel free to suggest your own text.

It is tricky to make this text perfect, because the phrase "default router"
is a little bit strange. Logically, there can only be one default at a given
instant, but we have the concept of a list of "defaults", which really
means a list of valid routers in the absence of a specific route for
the destination address. Or maybe "a default router" is a router that
claims to be able to route to any destination, but "the default router"
is the router the host is currently using in the absence of a specific
route.

This confusion seems to go back to RFC 1122, where these boxes are called
"default gateways".

    Bfian

---

From: 神明達哉 <[email-masked]>
Date: Thu, 11 Feb 2016 08:54:47 -0800

At Thu, 11 Feb 2016 08:30:11 +1300,

> is the router the host is currently using in the absence of a specific

To be clear, I don't think my suggestion is about making text of
"default router" perfect.  I just tried to correct the obvious error
of referring to the default router list as content of RA, and adjust
the rest of the paragraph accordingly.

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 12 Feb 2016 08:06:17 +1300

> the rest of the paragraph accordingly.

Yes, I understand and agree. We will correct the text. But one thought
leads to another, and I was quite surprised to discover that we seem to
have no document that defines "default router" except for the slightly
confusing "default gateway" discussion in RFC 1122.

   Brian