Subject: Re: I-D Action: draft-baker-6man-multi-homed-host-03.txt

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 8 Oct 2015 22:22:39 +0000

> On Sep 23, 2015, at 4:45 PM, David Farmer <[email-masked]> wrote:
> 
> 5. Should default routes with GUA PIOs associate them be preferred over default routes with only ULA PIOs associate them?
> 
> This is somewhat related to, but different from, the core issue of this document.  So if it's felt to be out of scope, I can accept that. However, since we are talking about changes to default route selection, I thought I should at least mention it here to see how people feel about including it.
> 
> If this additional rule is not included, the current changes will catch many of the most common situations adding a rule like this would catch anyway.  However, there are some corner cases that adding a rule like this would catch that the current changes wouldn't.

My personal view, to my knowledge not shared by many, is that a GUA and a ULA are both IPv6 unicast prefixes. If two hosts each have GUA and ULA addresses, the latter in the same /48 prefix, either should work in a properly designed network. When we make recommendations that differ between them, we are not making a technical comment; we are imposing a policy. That may be OK, but... I would far rather that address management policy were in the hands of the administrator, not tables of stone carried from Mount Olympus or wherever it is that RFCs derive.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 9 Oct 2015 12:15:33 +1300

On 09/10/2015 11:22, Fred Baker (fred) wrote:
> My personal view, to my knowledge not shared by many, is that a GUA and a ULA are both IPv6 unicast prefixes. 

Not only that, but a ULA *is* a GUA. Its formal scope is global. The only difference
is that border routers are not supposed to forward packets address to a ULA
outside their domain. If you want to talk only about GUAs that are not ULAs, you need
a new name for them (maybe GRGUAs, globally routable GUAs).

Therefore I fully agree with Fred as far as this draft is concerned.

   Brian

> If two hosts each have GUA and ULA addresses, the latter in the same /48 prefix, either should work in a properly designed
network. When we make recommendations that differ between them, we are not making a technical comment; we are imposing a policy.
That may be OK, but... I would far rather that address management policy were in the hands of the administrator, not tables of
stone carried from Mount Olympus or wherever it is that RFCs derive.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 9 Oct 2015 00:41:25 +0000

Apologies. I have been on vacation, and am catching up with this thread. Comments inline. I have been thinking about this email, and doing what might turn out to be a -04 update to the individual draft or a -01 update to the working group draft as that turns out.

> On Sep 23, 2015, at 12:07 AM, David Farmer <[email-masked]> wrote:
> 
> 
>> On Sep 3, 2015, at 20:39, Brian E Carpenter <[email-masked]> wrote:
>> 
>> Hi,
>> 
>> We've updated this as a result of the recent discussions - maybe
>> not all commenters will find their proposed fix here, but we think
>> that all the points within scope have been addressed.
>> 
>> Brian + Fred
> 
> I forget where are we at on this one?  Overall this version looks good to me, if it's not already adopted by the WG yet, I think it should be.

Thanks. Yes, the working group is asking itself that question.

> A few additional things;
> 1.  In the first sentence of the abstract and section 1 the draft refers to itself as "this note", but in section 6, and later in the abstract and section 1, it refers to itself as "this document".  Not a big deal, but it caught my eye.

OK

> 2. Isn't this basically a variation of the strong host model from RFC1122 section 3.3.4, but focused only on outbound traffic?  Maybe a historic reference to the strong host model and a little discussion how this varies from it might be appropriate in the Introduction.

Well, let me insert the host model text I wrote this afternoon. Tell me how to make it perfect - suggest text:

1.1.  Host Model

   It could be argued that the proposal of this document, which is to
   send messages using a source address in a given prefix to the router
   that advertised the prefix in its RA, is a form of [RFC1122]'s Strong
   ES (e.g.  Host) Model, discussed in section 3.3.4.2 of that document.
   In short, [RFC1122] identifies two basic models, in which the "strong
   host" model models the host as a set of hosts in one chassis, each of
   which uses a single address on a single interface, and always both
   sends and receives on that interface, and the "weak host" model
   treats the host as one system with zero or more addresses on every
   interface, and capable of using any interface for any communication.
   As noted there, neither model is completely satisfactory.  For
   example, a host with an addressless interface and a default route
   pointing to the interface will necessarily send packets using any
   address using that interface, and therefore be a de facto weak host.
   However, if the router upstream from the host implements BCP 38
   Ingress Filtering [RFC2827], such as by implementing uRPF on each
   interface, the router is configured to only permit communication by
   strong hosts.

              +-----------------+
              |                 |
              |     MIF Router  +---/--- other interfaces
              |                 |
              +---+---------+---+
                  |         | Two interfaces sharing a prefix
                --+-+--   --+-+--
                    |         |
                 +--+---------+--+
                 |   MIF Host    |
                 +---------------+

                Figure 1: Hypothetical MIF interconnection

   The proposal also differs slightly from [RFC1122]'s language of the
   Strong Host Model.  The statement is that the packet will go to the
   router that advertised a given prefix, but doesn't state what
   interface that might happen on.  Hence, if the router is a MIF router
   and is using the same prefix on two or more LANs shared by the host
   (as in Figure 1), the host might use each of those LANs and meet the
   requirement.  The Strong Host Model is not stated in those terms, but
   in terms of the interface used, and would find a MIF router quite
   confusing:

      (A) A host [MUST] silently discard an incoming datagram whose
      destination address does not correspond to the physical interface
      through which it is received.

      (B) A host [MUST] restrict itself to sending (non-source- routed)
      IP datagrams only through the physical interface that corresponds
      to the IP source address of the datagrams.

   However, comparing the presumptive route lookup mechanisms in each
   model, this proposal is indeed most similar to the Strong Host Model,
   as is any source/destination routing paradigm.

   Strong:  route(src IP addr, dest IP addr, TOS) -> gateway

   Weak:  route(dest IP addr, TOS) -> gateway, interface

   In the hypothetical MIF model suggested in Figure 1, the address
   fails to identify a single interface, but it does identify a single
   gateway.

> 3. I think there should be some discussion of this feature in the presence of RAs with the RFC4191 default router preference set.  I believe this feature SHOULD override such preference, but the preference SHOULD be honored between RAs originating the same PIO.

That seems like a reasonable thing. I might go a step further and reinterpret the default router advertisement as the default router for prefixes it advertises in a PIO. I'll have to think about that one, though. It seems like a router might advertise two prefixes and only want to be the default router for one, which is an end case that would also need guidance.

> 4. Also similarly, there should be discussion of this feature and RFC4191 RIOs.

Here I might follow logic similar to what I suggested for a PIO, but potentially with a twist. The RIO basically says that the announcing router is the appropriate router to use for a given destination prefix. I could argue that this affects only forwarding, and if the host is using a source prefix the router isn't announcing (such as if it is responding to a packet from some remote system), the host should follow the rules for packets using that source prefix and ignore the RIO. If the host has carte blanche on what source address to use - it is initiating a TCP SYN for example - I could also imagine it as giving guidance in source address selection. E.g., if the host has two prefixes and therefore addresses and announcing routers, and it is initiating a session to an address in a prefix one of those routers announced in an RIO, I could imagine the host selecting as a source address the one in the prefix announced by the router that announced the RIO, and as a result send the packet in a manner consistent with the expectations imposed by the RIO.

What's going through my mind right now is a variant on the words on a claymore mine. "Front Toward [Heretic]".