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

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 13 Aug 2015 20:44:40 +0000

Jinmei and others: Brian and I have updated the draft in response to public and private email. Thanks, Jinmei, for proposing text; that is a helpful way to get to a rational conclusion.

The diff from -00 may be found at https://tools.ietf.org/rfcdiff?url2=draft-baker-6man-multi-homed-host-01.txt.

We still would appreciate comments from the community.

> Begin forwarded message:
> 
> From: <[email-masked]>
> Subject: New Version Notification for draft-baker-6man-multi-homed-host-01.txt
> Date: August 13, 2015 at 1:40:14 PM 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-01.txt
> has been successfully submitted by Fred Baker and posted to the
> IETF repository.
> 
> Name:		draft-baker-6man-multi-homed-host
> Revision:	01
> Title:		Host routing in a multi-prefix network
> Document date:	2015-08-13
> Group:		Individual Submission
> Pages:		7
> URL:            https://www.ietf.org/internet-drafts/draft-baker-6man-multi-homed-host-01.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-01
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-baker-6man-multi-homed-host-01
> 
> 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, when the host has multiple routers to
>   choose from.
> 
> 
> 
> 
> 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: Behcet Sarikaya <[email-masked]>
Date: Thu, 13 Aug 2015 17:28:13 -0500

> The diff from -00 may be found at https://tools.ietf.org/rfcdiff?url2=draft-baker-6man-multi-homed-host-01.txt.

Wait a minute.
I think the draft should have a reference to the SADR Overview draft
because it IS the reason d'etre of your draft.

Regards,

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

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 14 Aug 2015 10:59:44 +0200 (CEST)

Hi,

I have some proposed text:

2. first paragraph, last sentence, replace with:
--
In the latter case it will be generally the case that the configured 
DHCPv6 based addresses are within one of the prefixes advertised 
in a Router Advertisement as being on-link in that subnet.
--

5.x I would like to add text here, perhaps called 5.1, or take existing 5 
and make it 5.1, and make this text 5.2:

5.2
--
There are certain deployment scenarios where the network administrator do 
not want hosts to directly communicate with each other within the same L2 
network, for instance by deploying L2 forwarding rules so that each device 
only can communicate with the router, and any traffic even within one IPv6 
subnet, need to traverse the router and back again. For this deployment 
scenario, the expectation on the router is that it'll advertise PIOs for 
the prefix matching addresses configured by the host, but use L=0 to 
indicate that this subnet is off-link and shouldn't be used for direct 
communication to another destination address within the subnet. This 
enables the host to choose the correct router for the source address of 
the packet in question since it SHOULD treat PIOs with L=0 and L=1 the 
same way when it comes to forming list of next-hop for packets with a 
certain source address prefix.
--

This text should go somewhere, perhaps in 3?

-- 
If a router has been delegated a larger subnet by an ISP for instance a 
DHCPv6 IA_PD /56 prefix, it MAY announce this as a an Router Advertisement 
message containing PIO /56 with L=0. When the host receives PIOs that are 
overlapping, it SHOULD install all of them, and perform longest prefix 
matching when deciding what next-hop to use.
--

So I also think that the rules we're creating doesn't only match hosts, 
but also matches routers or hosts that have been given addresses using 
IA_PD. So perhaps some text about this somewhere:

-- 
Addresses refered in this document as "assigned by DHCPv6" may include 
IA_NA, IA_TA and IA_PD or other future methods of assigning single or 
multiple addresses to a host.
--

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: 神明達哉 <[email-masked]>
Date: Mon, 17 Aug 2015 11:31:42 -0700

At Fri, 14 Aug 2015 10:59:44 +0200 (CEST),

I'd be curious about what if this deployment scenario is used while
disabling SLAAC (so DHCPv6 is the likely method for address
configuration, but it doesn't have to be so for the scope of this
discussion).  Should we expect the router to advertise the prefix with
L=0 and A=0 in this case?

--
JINMEI, Tatuya

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 18 Aug 2015 06:52:43 +0200 (CEST)

> L=0 and A=0 in this case?

Yes.

---

From: Mark Smith <[email-masked]>
Date: Tue, 18 Aug 2015 17:42:42 +1000

Hi,

> subnet, need to traverse the router and back again.

So in my recent draft, "Indicating Link-Local Unicast Destinations are
Off-Link", draft-smith-6man-link-locals-off-link,
I called these types of networks "Constrained Broadcast Multi-Access"
or CBMA networks, as a more general term for TR-101 N:1 VLANs, Wifi
with station isolation enabled and "Private VLANs". I think it would
be useful to have a generic name for them, and though of CBMA as a
variation on NBMA.

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Tue, 18 Aug 2015 17:56:23 +1000

Hi,

Some thoughts/comments while reading through it.

2.  Expectations the host has of the network

"When no prefixes are usable for SLAAC, the
   Router Advertisement would normally signal the availability of DHCPv6
   [RFC3315] and the host would use it to configure its addresses."

Perhaps a bit trivial, however I read this as implying that SLAAC and
DHCPv6 are mutually exclusive on a link. I think commonly it would be,
however during a transition between SLAAC and DHCPv6 or vice-versa,
they could co-exist, and it is also valid (and implemented in OpenWRT
by default) to have both.

"Since the host derives fundamental default routing information from
   the Route Advertisement, this implies that, in any network with hosts
   using multiple prefixes, each prefix SHOULD be advertised via on-link
   Prefix Information Options [RFC4861] by one of the attached routers,"

I think it would be good to delete "on-link" as it has a loaded
meaning in RAs and in particular in PIOs, and I don't think this is
saying to switch on the on-link/L bit in the PIOs (or if it is, that
should be clearer.)

3.  Reasonable expectations of the host

"When a host makes a successful exchange with a remote address or
   prefix using a particular source address, and the host has received a
   prefix that matches that source address in an RA, then the host
   SHOULD include the prefix in such history. On subsequent attempts to
   communicate with that remote address, if it has an address in that
   prefix at that time, a host MAY use an address in the remembered
   prefix for the session."

I was a little confused by which prefix is being referred to in the
last part of the sentence. I think clarifying source or
remote/destination prefixes and adding where they came from in the
text would make it clearer e.g.,

"When a host makes a successful exchange with a remote address or
   *remote* prefix using a particular source address, and the host has
received a
   *source* prefix that matches that source address in an RA *Prefix
Information Option*, then the host
   SHOULD include the *source* prefix in such history. On subsequent attempts to
   communicate with that remote address, if it has an address in that
   *source* prefix at that time, a host MAY use an address in the remembered
   *source* prefix for the session."

I'm also a little confused as to how a host would be aware that it is
successfully sending a "remote prefix". How has it learned the size of
the prefix, or would it be assuming that they're always /64s e.g.,
RFC7136? Or is this remote prefix information only available if
they're prefixes that have been advertised in RA PIOs?

"A host SHOULD select a "default gateway" for each source prefix it
   uses to form an address or is assigned an address in.  That router
   SHOULD be one of the routers advertising the prefix in its RA.  As a
   result of doing so, when a host emits a datagram using a source
   address in one of those prefixes and has no history directing it
   otherwise, it SHOULD send it to the indicated "default gateway"."

RFC4311 allows load-sharing between equivalent routers, so I think an
alternative suggestion would be for a host to remember the set of
routers advertising a source prefix and perform load-sharing between
them.

Regards,
Mark.

---

From: 神明達哉 <[email-masked]>
Date: Tue, 18 Aug 2015 14:57:41 -0700

At Tue, 18 Aug 2015 06:52:43 +0200 (CEST),

> > L=0 and A=0 in this case?

Okay, in that case I think it's better to note explicitly that the
host has to keep maintaining the prefix even if it's not used for
address configuration or on-link determination.  Any host
implementation will need to be modified to support the proposal of
this draft anyway, but in this case it'll be even more non-trivial
since I suspect today's implementation simply ignores a prefix with
L=0 and A=0.

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Tue, 18 Aug 2015 16:48:25 -0700

At Tue, 18 Aug 2015 17:56:23 +1000,

> by default) to have both.

The sentence in question was largely based on my proposed text, so I
clarify my intent: I was aware the possibility of mixed use of SLAAC
and DHCPv6 (or even manual configuration), but I thought this section
talks about common expectations of common scenarios, so I didn't
bother to be too verbose by exercising every corner case scenario.  I
intended to indicate this is not *the* only use case by the phrase
"would normally", and I also thought it's quite clear that this
section only talks about some common subset of possible scenarios.
But if we can make it more generic without sacrificing brevity, I have
no problem with doing so.

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Wed, 19 Aug 2015 10:32:17 -0700

At Wed, 19 Aug 2015 05:17:46 +0000,
"Fred Baker (fred)" <[email-masked]> wrote:

> Before I post this, I want to collect any remaining comments on
> it. Your thoughts?

> 3.  Reasonable expectations of the host
[...]
>    When a host makes a successful exchange with a remote address or
>    PIO that matches that source address in an RA, then the host SHOULD
>    include the prefix in such history, whatever the setting of the L and
>    A flags in the PIO.  On subsequent attempts to communicate with that
>    remote address, if it has an address in that prefix at that time, a
>    host MAY use an address in the remembered prefix for the session.

As I commented in the relevant discussion on this list, I think
"whatever the setting of the L and A flags in the PIO" will need some
explicit note about the unusual case of L=0 and A=0.  For example, we
might add the following paragraph to the above one:

   Note that the PIO used this way may have both L and A flags
   cleared.  Although this does not violate the existing standard,
   such a PIO has made no sense in practice, and it is possible that
   existing host implementations simply ignore such a PIO or that a
   router implementation rejects such a PIO as a configuration error.
   Newer implementations that support this proposal will need to be
   update: a host SHOULD NOT ignore a PIO simply because both L and A
   flags are cleared; a router SHOULD be able to send such a PIO.

But...on seeing another discussion in this thread from implementor's
perspective, I now wonder whether we really need to remember a
"prefix" in this "history".  For the main purpose of this draft, the
most important thing is to choose the right default router for a given
source address, right?  In that sense, the more important part of
Section 3 is the third paragraph:

   A host SHOULD select a "default gateway" for each source prefix it
   uses to form an address or is assigned an address in.  [...]

and I suspect this is much easier to implement: this is basically just
about next hop determination, and what a host implementation should do
is to remember the sender(s) of RA for each advertised prefix, and to
choose a router (if any) that advertises a prefix matching the source
address.  The "history" thing may be an additional useful
optimization, but that's not the crucial part of the proposal.  If my
understanding so far is correct and we can agree that it wouldn't be
that hard to implement just the next hop selection, I'm willing to
provide more specific text to revise the whole section based on this
observation.

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Aug 2015 15:10:01 +1200

>    flags are cleared; a router SHOULD be able to send such a PIO.

Works for me.

> "prefix" in this "history".  

And I wonder whether it should be per-source-address rather than
per-source-prefix (just to avoid having to figure out which prefix
an address matches as part of the sending code). In fact it's like
a locally-synthesised redirect (see the code fragment that Pierre
pointed us to at http://lxr.free-electrons.com/source/net/ipv6/route.c#L1285).

> For the main purpose of this draft, the

Agreed.

    Brian

---

From: 神明達哉 <[email-masked]>
Date: Thu, 20 Aug 2015 13:17:11 -0700

[...]
> provide more specific text to revise the whole section based on this

So, this is an attempt of suggesting text (pasted at the end of this
message).  I've reorganized the entire Section 3, but I believe most
of the original points are preserved.  The major changes are:

- There's a SHOULD for a host to remember the relationship between PIOs
  and routers advertising the prefixes.
- The normative keyword for the optimization using communication
  history is weakened and is now a MAY.
- Instead of keeping a prefix in the history, the new text suggests
  keeping an address (as Brian mentioned).

The new SHOULD may sound too strong, in which case I can discuss how
to soften the wording.  But in my understanding this is an inevitable
sub-feature to realize this proposal, so I suspect we'll need to say
this should be done in some way.  I also know it's realistically
implementable and workable: BSD variants have been maintaining this
relationship for many years.

--
JINMEI, Tatuya

   A host SHOULD remember, for each prefix advertised in a PIO of RA,
   the routers that advertise the prefix, whatever the setting of the
   L and A flags in the PIO.  Such a host will be able to apply Rule
   5.5 of the default source address selection algorithm described in
   [RFC6724].  When this rule determines the source address for a
   given destination, the host will send a datagram to the destination
   using a source address in one of the prefixes the host uses to form
   the source address or is assigned the address in.  In the
   "simplest" network described in Section 2.1, that would get it to
   the only router that is directly capable of getting it to the right
   ISP.  This will also apply in more complex networks, even when more
   than one physical or virtual interface is involved.

   Note that the prefix maintained in the host for this purpose may
   have both L and A flags cleared.  Although this does not violate
   the existing standard, such a PIO has made no sense in practice,
   and it is possible that existing host implementations simply ignore
   such a PIO or that a router implementation rejects such a PIO as a
   configuration error.  Newer implementations that support this
   proposal will need to be updated: a host SHOULD NOT ignore a PIO
   simply because both L and A flags are cleared; a router SHOULD be
   able to be configured to send such a PIO.

   In more complex cases, wherein routers advertise RAs for multiple
   prefixes whether or not they have direct or isolated upstream
   connectivity, the host is dependent on the routing system already.
   If the host gives the packet to a router advertising its source
   prefix, it should be able to depend on the router to do the right
   thing.

   There is potential for adverse interaction with any off-link Redirect
   message sent by a router in accordance with Section 8 of [RFC4861].
   Hosts SHOULD apply off-link redirects only for the specific pair of
   source and destination addresses concerned, so the host's Destination
   Cache needs to contain appropriate source-specific entries.

   Modern hosts maintain a fair bit of history, in terms of what has
   historically worked or not worked for a given address or prefix and
   in some cases the effective window and MSS values for TCP or other
   protocols.  This includes a next hop address for use when a packet is
   sent to the indicated address.

   When a host makes a successful exchange with a remote address or
   prefix using a particular source address, then the host MAY include
   the address in such history.  On subsequent attempts to communicate
   with that remote address, if it has that address at that time, a
   host MAY use the address for the session.  It may help increase the
   chance of making successful communication faster.

---

From: 神明達哉 <[email-masked]>
Date: Thu, 20 Aug 2015 13:18:56 -0700

At Thu, 20 Aug 2015 15:10:01 +1200,
Brian E Carpenter <[email-masked]> wrote:

> an address matches as part of the sending code).

I was also getting to the same thought.  So I reflected that in my
latest suggested text that I sent to the list a few minutes ago.

--
JINMEI, Tatuya