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

From: Brian E Carpenter <[email-masked]>
Date: Fri, 4 Sep 2015 13:39:39 +1200

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

-------- Forwarded Message --------
Subject: I-D Action: draft-baker-6man-multi-homed-host-03.txt
Date: Thu, 03 Sep 2015 18:25:49 -0700
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : Host routing in a multi-prefix network
        Authors         : Fred Baker
                          Brian Carpenter
	Filename        : draft-baker-6man-multi-homed-host-03.txt
	Pages           : 9
	Date            : 2015-09-03

Abstract:
   This note describes expected IPv6 host behavior in a network that has
   more than one prefix, each allocated by an upstream network that
   implements BCP 38 ingress filtering, when the host has multiple
   routers to choose from.  It also applies to other scenarios such as
   the usage of stateful firewalls that effectively act as address-based
   filters.

   This host behavior may interact with source address selection in a
   given implementation, but logically follows it.  Given that the
   network or host is, or appears to be, multihomed with multiple
   provider-allocated addresses, that the host has elected to use a
   source address in a given prefix, and that some but not all
   neighboring routers are advertising that prefix in their Router
   Advertisement Prefix Information Options, this document specifies to
   which router a host should present its transmission.  It updates RFC
   4861.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-baker-6man-multi-homed-host/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-baker-6man-multi-homed-host-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-baker-6man-multi-homed-host-03

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: David Farmer <[email-masked]>
Date: Wed, 23 Sep 2015 02:07:50 -0500

> On Sep 3, 2015, at 20:39, Brian E Carpenter <[email-masked]> wrote:
> 
> Hi,
> 

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.

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.

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.

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.

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

-- 
===============================================
David Farmer                          Email: [email-masked]
Office of Information Technology
University of Minnesota    
2218 University Ave SE         Phone: +1-612-626-0815
Minneapolis, MN 55414-3029   Cell: +1-612-812-9952
===============================================

---

From: David Farmer <[email-masked]>
Date: Wed, 23 Sep 2015 18:45:00 -0500

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

Forgot another one I was thinking of;

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.

-- 
================================================
David Farmer               Email: [email-masked]
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================

---

From: Mark Smith <[email-masked]>
Date: Thu, 24 Sep 2015 10:08:22 +1000

> On 9/23/15 02:07 , David Farmer wrote:

<snip>

> default routes with only ULA PIOs associate them?

So per the latest src/dst addr. selection RFC, if a host has a choice
of the use of ULA and a GUA address, it'll select the smaller scoped
ULA.

I think the a similar sort of preference would apply to internal
verses external routing - prefer more optimal internal routing over
more optimal external routing. Actually, come to think of it, this has
been a convention for a long time, with e.g., OSPF routes being
preferred by many (all?) implementations over BGP versions of the
routes, or internal SPF calculated routes being preferred over
external imported routes within OSPF.

So I'd say in your scenario, the default router announcing the ULA
PIOs should be preferred over the default router announcing the GUA
PIOs, making the assumption that the ULA router can also forward
towards GUA destinations.

In the context of this draft though, I think the host would remember
both default routers, and use the GUA PIO one for GUA srcs and/or
dests, and the ULA PIO one for ULA srcs and/or dests.

Regards,
Mark.

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

---

From: David Farmer <[email-masked]>
Date: Wed, 23 Sep 2015 20:16:25 -0500

>> On Sep 23, 2015, at 19:08, Mark Smith <[email-masked]> wrote:

What, where does it say that?  I read it as prefer GUA over ULA, here is what I'm going by;

From RFC 6724, section 10.6. Configuring ULA Preference;

> towards GUA destinations.

I'm assuming it would have to go through NAT66 or there is a much higher risk it would then a default route that has GUA PIOs associated with it.
 
> dests, and the ULA PIO one for ULA srcs and/or dests.

This was the point I was making why this is only necessary for some corner cases.

---

From: Mark Smith <[email-masked]>
Date: Thu, 24 Sep 2015 12:14:24 +1000

Hi David,

> What, where does it say that?  I read it as prefer GUA over ULA, here is

So here was the text that set my expectation, specifically the prefer
smaller scopes text,

"The
   combined effect is to prefer destination/source address pairs for
   which the two addresses are of equal scope or type, prefer smaller
   scopes over larger scopes for the destination address,"

I might have been caught out by how I conceptually think of the scopes
of ULA and GUAs.

I've thought of ULAs having a smaller scope than GUAs, because ULAs
are local network addressing rather than global network addressing (so
while ULAs and GUAs have global (near-) uniqueness, the scope of the
network domain a ULA is applied to is much smaller than the scope of
the network domain GUAs addresses are applied to). Although it is
fairly if not completely theoretical, as a network  operator you have
more control over the availability of your locally administered and
assigned address space compared to global address space that is
supplied by an external party. So by preferring ULAs for internal
applications over GUAs you are reducing an external dependency, and I
think reducing external dependencies is a good robustness principle.

More practically, if your local network applications are presented
with a choice of a ULA and GUA address for an internal destination,
and they chose the ULA in preference to the GUA, then if it is
necessary to renumber the GUA space, only applications accessing
external destinations would be impacted during the renumbering event.

I'll have to look at RFC5220, however if GUAs are preferred over ULAs
when there is a choice, it starts to mean that to avoid the external
GUA dependency for internal applications you need to make sure
internal applications only have GUA addresses (which may cause
operational issues e.g., the host can't directly access the Internet
to download operating system patches, so you'll need to set up proxy
infrastructure or have two interfaces, one with a ULA, one with a GUA,
etc.), or another idea I've been thinking about recently - that
applications should be using Multipath TCP or SCTP with all the local
source and destination addresses so that they can survive an address
expiry/renumbering event.

Regards,
Mark.

> Sections 2.1.4, 2.2.2, and 2.2.3 of RFC 5220 [RFC5220] describe
>    address selection problems related to Unique Local Addresses (ULAs)
>    [RFC4193].  By default, global IPv6 destinations are preferred over
>    ULA destinations, since an arbitrary ULA is not necessarily
>    reachable:
>
> I'm assuming it would have to go through NAT66 or there is a much higher
> risk it would then a default route that has GUA PIOs associated with it.
>
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 24 Sep 2015 14:56:50 +1200

ULAs are GUAs, as far as scope is concerned. I honestly think
that's irrelevant to the present draft.

   Brian

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 24 Sep 2015 11:47:53 +0000

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of David Farmer
> Sent: Wednesday, September 23, 2015 7:45 PM
> To: Brian E Carpenter
> Cc: 6man
> Subject: Re: I-D Action: draft-baker-6man-multi-homed-host-03.txt
> 
> >> 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.
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> 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.
> 
> --

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 24 Sep 2015 11:51:56 +0000

[Darned twitchy finger... Sorry about the previous email.]

> default routes with only ULA PIOs associate them?

I know of many applications designed to operate inside the LAN that prefer ULA over GUA. This is seen as providing a layer of protection, because traffic that isn't supposed to escape to the outside Internet can't escape.
Barbara

---

From: "Turner, Randy" <[email-masked]>
Date: Thu, 24 Sep 2015 11:58:38 +0000

Hi Barbara,

When you say "applications", do you mean actual applications are performing address selection, or are the underlying stacks have an address selection policy that favors ULAs ?

Thanks!
Randy

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of STARK, BARBARA H
Sent: Thursday, September 24, 2015 7:52 AM
To: David Farmer; Brian E Carpenter
Cc: 6man
Subject: RE: I-D Action: draft-baker-6man-multi-homed-host-03.txt

> 5. Should default routes with GUA PIOs associate them be preferred
> over default routes with only ULA PIOs associate them?

P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.

This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you.

---

From: David Farmer <[email-masked]>
Date: Thu, 24 Sep 2015 08:19:37 -0500

> On Sep 24, 2015, at 06:51, STARK, BARBARA H <[email-masked]> wrote:
> 

I recognize that, but personally I'd recommend the better way is to ensure the right routing behavior on such LANs by including a RIO in the RA for the ULA prefix used within the site and adding the site ULA Prefix into the src/dest address selection policy table as discussed in 10.6 of RFC6724.  If you are using ULA because of some perceived security advantage then leaving the routing behavior to the default policy table and the default route seems counterproductive to those security goals anyway.

Furthermore, if we blindly prefer a ULA based default route for some perceived security local advantage, I'm worried that will lead to the proliferation of NAT66. Which is counterproductive to the overall goals of IPv6.

Thanks

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 24 Sep 2015 13:50:42 +0000

> When you say "applications", do you mean actual applications are performing
> address selection, or are the underlying stacks have an address selection
> policy that favors ULAs ?

Applications can and often do their own address selection. For example, browsers these days pretty much all take care of their own address selection, and each does its own version of Happy Eyeballs. DLNA applications (which are expected to satisfy very specific and limited use cases) that do IPv6 are definitely not expected to use default platform policies.

RFC 6724 does identify a default (underlying stack) policy for address. This RFC is very explicit about (1) this is a default policy recommendation and "IPv6 implementations SHOULD support configurable address selection" and (2) "The selection rules specified in this document MUST NOT be construed to override an application or upper layer's explicit choice of a legal destination or source address". I think I'd like to leave default address selection policy to RFC 6724. It really does a great job.
Barbara

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 24 Sep 2015 14:08:44 +0000

> I think I'd like to leave default address selection policy to
> RFC 6724. It really does a great job.

But I guess there is an interesting question of whether we would want to recommend route selection precede address selection, or vice versa. This draft right now seems to be assuming address is selected first and then the correct next hop based on the address. I think there may be good reasons for suggesting picking the desirable route first, and then the addresses from among those that are usable for that route (according to whatever address selection policy applies).
Barbara

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 25 Sep 2015 08:23:03 +1200

> I know of many applications designed to operate inside the LAN that prefer ULA over GUA. This is seen as providing a layer of protection, because traffic that isn't supposed to escape to the outsid…

Sure. That's common sense really. I still don't see what ULAs have to do with a draft
that is concerned with choosing the right egress to global routing.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 25 Sep 2015 08:29:08 +1200

On 25/09/2015 02:08, STARK, BARBARA H wrote:
> But I guess there is an interesting question of whether we would want to recommend route selection precede address selection, or vice versa. This draft right now seems to be assuming address is selected first and then the correct next hop based on the address. 

s/address/address pair/

> I think there may be good reasons for suggesting picking the desirable route first, and then the addresses from among those
that are usable for that route (according to whatever address selection policy applies).

I think that requires the host to run a routing protocol and to be guided by a routing
policy, which I would regard as way out of scope for this draft. Or possibly a
connection manager, as discussed on the v6ops-host-addr-availability thread, which
I would also regard as way out of scope here.

   Brian

---

From: David Farmer <[email-masked]>
Date: Thu, 24 Sep 2015 17:58:05 -0500

> that is concerned with choosing the right egress to global routing.

As I said when brought this up, I'm fine with this being out of scope 
for this draft.  In fact selecting the default route associated with the 
PIO of the source prefix will help equally in the case of GUA or ULA 
sources.

On 9/23/15 18:45 , David Farmer 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.

I was trying to think if there are any corner cases where additional 
rules might be helpful.  And the only case I could think of is if DHCPv6 
server assigned a host an address that there isn't an associated PIO 
being announced.  To be functional the prefix would have to be 
configured on a router, but maybe it isn't announcing a PIO or even a 
RA.  In such as case would it be better to select default route with a 
GUA PIO associated with it, over a default route with only a ULA PIO 
associated with it.

This is admittedly a manufactured corner case, it may not be worth too 
much more thought.  As most normal cases there would be a PIO and the 
default route could be selected based on it, and the right thing should 
just happen.

Sorry for the diversion.

---

From: james woodyatt <[email-masked]>
Date: Mon, 28 Sep 2015 10:31:36 -0700

>> default routes with only ULA PIOs associate them?

No.

> I know of many applications designed to operate inside the LAN that prefer ULA over GUA. This is seen as providing a layer of protection, because traffic that isn't supposed to escape to the outsid…

This perception is wrong. All the ULA really means is that the public default-free zone can’t forward it, and it has to be routed over paths established under bilateral agreement. There is no protection inherent in ULA that prevents traffic from “escaping" to the “outside" Internet.

—james