Subject: Fwd: New Version Notification for draft-baker-6man-multi-homed-host-00.txt

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 7 Aug 2015 14:42:22 +0000

As promised at IETF 93

> Begin forwarded message:
> 
> From: <[email-masked]>
> Subject: New Version Notification for draft-baker-6man-multi-homed-host-00.txt
> Date: August 7, 2015 at 7:40:43 AM PDT
> To: "Brian E. Carpenter" <[email-masked]>, Fred Baker <[email-masked]>, Fred Baker <[email-masked]>, Brian Carpenter <[email-masked]>
> 
> 
> A new version of I-D, draft-baker-6man-multi-homed-host-00.txt
> has been successfully submitted by Fred Baker and posted to the
> IETF repository.
> 
> Name:		draft-baker-6man-multi-homed-host
> Revision:	00
> Title:		Host routing in a multi-prefix network
> Document date:	2015-08-05
> Group:		Individual Submission
> Pages:		6
> URL:            https://www.ietf.org/internet-drafts/draft-baker-6man-multi-homed-host-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-baker-6man-multi-homed-host/
> Htmlized:       https://tools.ietf.org/html/draft-baker-6man-multi-homed-host-00
> 
> 
> Abstract:
>   This note describes expected host behavior in a network that has more
>   than one prefix, each allocated by an upstream network that
>   implements BCP 38 filtering.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: Philip Homburg <[email-masked]>
Date: Mon, 10 Aug 2015 15:23:16 +0200

>> A new version of I-D, draft-baker-6man-multi-homed-host-00.txt

My few cents:

- Ideally the routers coordinate among each other, hosts can pick any of the
  default routers on the LAN and routers send a host redirects if the host
  picked the wrong default for the source address. 

  The nice thing is that this works with existing stacks. I think
  we should make the approach a very strong SHOULD and encourage homenet
  to make this model a MUST.

Absent this, we can try to use RAs to tell hosts which default routers
to use for which source address.

>From my point of view this a change from the current model. So any RFC about
this has to spell out the details.

For address configuration based on SLAAC it is relatively simple:
- require that hosts prefer default routers that announce the PIO that was
  used for address generation over default routers that don't.

  Note that we should say something about how this interacts with the default
  router preference value (I assume that this check has a higher priority)

- hosts that receive their address from DHCPv6 should check if the the address
  they receive is covered by any prefix announced by a default router.

  Note that usally there should be such a prefix to indicate what addresses
  are considered on-link

  However, in a network where this is not the case, default router would have
  to be configured to announce the prefix with a zero flags field.

So there are two changes required:
- hosts have to keep track of which default routers are available for each of
  the hosts IPv6 addresses. This is essentially a MUST if we want to support
  this model

- Routers that operate in a DHCPv6 context: they have to be configured to
  announce PIO options for the DHCPv6 range even if the prefix is not
  considered on-link.

  For routers that applies only if the admin wants the model where routers
  can't forward traffic to each other. Otherwise, all default routers are
  equivalent and redirects can be used to optimize traffic.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 Aug 2015 15:23:33 +1200

>   the hosts IPv6 addresses. This is essentially a MUST if we want to support

<rant>
I've thought this since the first two minutes I spent thinking about
the MIF problem, and I'm very sad that the MIF WG didn't quickly reach
that conclusion and then close itself down.
</rant>

>   announce PIO options for the DHCPv6 range even if the prefix is not

Yes, if and only if they know how to forward the corresponding packets to
their correct egress.

   Brian

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

---

From: Ole Troan <[email-masked]>
Date: Tue, 11 Aug 2015 19:09:24 +0200

> Yes, if and only if they know how to forward the corresponding packets to

and I don’t think the rule need to take the off-link/on-link property into consideration.
if there is no PIO, there is no association between SA and NH.

cheers,
Ole

---

From: 神明達哉 <[email-masked]>
Date: Wed, 12 Aug 2015 11:17:44 -0700

>> Title:                Host routing in a multi-prefix network

I've read the draft.  My comments follow:

- General
  By mentioning the "simplest multihomed network" in Section 2, does
  this document exclude cases like a multi-subnet network where a host
  is attached to a single router that provide multiple prefixes, each
  belong to a different upstream network?  Like this one:

  Upstream1----R1---+
                    +---R3---hosts
  Upstream2----R2---+

- Section 2

   A host receives on-link prefixes in a Router Advertisement [RFC4861],
   which goes on to identify preference order among them and whether
   they are usable by SLAAC [RFC4862] [RFC4941] [RFC7217], or whether
   they must be assigned using DHCPv6 [RFC3315].

  What does "they must be assigned using DHCPv6" mean?  I'm not even
  sure about what "they" mean.  Could you elaborate?

- Section 3

   A host SHOULD include the prefix it used in a successful exchange
   with a remote address or prefix in such history.

  I'm afraid the concept of "the prefix it used" is not clearly
  defined.  I guess it intends to mean: a prefix is considered to be
  "used" by a host in communication when the host's source address in
  that communication matches the prefix (whether the address is
  generated by SLAAC or by DHCPv6 or manually).  If so, it makes sense
  to me, but I think it's better to be defined clearly and explicitly.

- Section 3

   A host SHOULD select a "default gateway" for each prefix it uses to
   obtain one of its own addresses.

  Similar to the previous point, this "obtain" sounds a bit vague to
  me, especially in the case where the address is assigned via DHCPv6.

- Section 5

   The assumption that packets will be forwarded to the appropriate
   egress by the local routing system might cause at least one extra hop
   in the local network (from the host to the wrong router, and from
   there to another router on the same LAN but in a different subnet).

  I felt I was lost here.  Doesn't this draft assume that the routers
  don't speak routing protocols between them (e.g., as noted in
  Section 2)?  Or does this correspond to the "Even if" case of the
  next to the last paragraph of Section 2?

   [...] Even if there was, it would be an indirect route, rather
   than a direct route originating with the host.  Therefore the host
   needs to select the appropriate router itself.

- Section 7: there might be a small privacy implication (in a way that
  this proposal improves it): with the current practice, a multihomed
  host could disclose the prefix of one upstream to the other upstream
  network more easily.  The proposed practice will make it less likely
  to happen.

--
JINMEI, Tatuya

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 12 Aug 2015 18:35:54 +0000

> On Aug 12, 2015, at 11:17 AM, 神明達哉 <[email-masked]> wrote:
> 

That could be simpler, from the host's perspective - it only has one router it is talking with. There is an even simpler version - R3 is talking to both upstreams. However, in such a case, the host really has no decisions - it speaks or it doesn't, but if it chooses to speak, there is only one party for it to talk with regardless of its source address choice.

Brian's statement of the problem at IETF 93 had to do with cases where the host has to make a choice. To have a choice, it has to have two options to choose among. Having the host speak directly with R1 and R2 is the simplest such case I can think of offhand. The question before the house is - so what should the host do in such a case?

It also has the interesting component that there is no guarantee that R1 and R2 talk with each other. They may be precluded from doing so physically (they aren't connected, but connect to the host on different media or media types) or by policy. But if they can't or won't forward packets to each other (BCP 84) but instead drop offending packets (BCP 38), it is in the host's interest to avoid the question.

>  sure about what "they" mean.  Could you elaborate?

The RA tells the host whether it may use SLAAC with a prefix. If it is not permitted to, which is probably because the network administration has made an administrative choice, do you have another suggestion of how the address would be assigned?

>  to me, but I think it's better to be defined clearly and explicitly.

Ack

>  me, especially in the case where the address is assigned via DHCPv6.

Ack

>  next to the last paragraph of Section 2?

Well, the routers might. However, if they are associated with different upstreams, they may not even be physically connected (think LTE and WiFi for example) much less in a routing exchange.

>  network more easily.  The proposed practice will make it less likely

True.

Thanks.

---

From: 神明達哉 <[email-masked]>
Date: Thu, 13 Aug 2015 10:04:21 -0700

At Wed, 12 Aug 2015 18:35:54 +0000,

> >  belong to a different upstream network?  Like this one:
[...]
> Brian's statement of the problem at IETF 93 had to do with cases
> where the host has to make a choice. To have a choice, it has to
> have two options to choose among. Having the host speak directly
> with R1 and R2 is the simplest such case I can think of offhand. The
> question before the house is - so what should the host do in such a
> case?

Limiting the scope to the simplest case is fine for me.  I just tried
to confirm that, and now that I understand that appears to be the
intent, I'd suggest clarifying that in the draft.

> The RA tells the host whether it may use SLAAC with a prefix. If it
> is not permitted to, which is probably because the network
> administration has made an administrative choice, do you have
> another suggestion of how the address would be assigned?

I'm afraid my point wasn't clear...it was purely about how to
interpret "whether they must be assigned using DHCPv6 [RFC3315]" since
I simply didn't get it.  Based on your response above, I guess the
whole sentence tries to say that a host would use SLAAC or DHCPv6
depending on the A flag of advertised prefixes in RAs.  I have no
objection to the idea that these will be common scenarios, but I have
several concerns with the original sentence if that was the intent.
First, technically, whether a prefix is on-link or not is irrelevant
to whether the prefix is to be configured using SLAAC, so the term
"on-link" seems to be misleading.  Secondly, RA's PIO has nothing to
do with DHCPv6 from protocol point of view.  Thirdly, at very least
prefixes are not "assigned using DHCPv6" in any case.

And, on re-reading the entire sentence, I also noticed I don't get
what "identify preference order among them" means.

I'd probably need to know what you are actually trying to say here to
address these points, but with guessing the intent I'd rephrase the
whole sentence (e.g.) as follows:

   A host receives prefixes in a Router Advertisement [RFC4861],
   which goes on to identify whether they are usable by SLAAC
   [RFC4862] [RFC4941] [RFC7217].  When no prefixes are usable for
   SLAAC, the Router Advertisement would normally signal the
   availability of DHCPv6 and the host would use it to configure its
   addresses.  In the latter case it will be generally the case that
   the configured addresses match one of the prefixes advertised in a
   Router Advertisement that are supposed to be on-link in that subnet.

> Well, the routers might. However, if they are associated with
> different upstreams, they may not even be physically connected
> (think LTE and WiFi for example) much less in a routing exchange.

I still don't get it...what you said in your response is true, but I
don't understand how it's related to the draft text I mentioned
above.  The point of my comment here was that I didn't understand how
this block of text is related to the entire context of the draft.

--
JINMEI, Tatuya