Subject: Re: [v6ops] Letting apps select outbound path

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 15 Aug 2016 12:06:17 +0200 (CEST)

On Fri, 22 Jul 2016, Brian E Carpenter wrote:

> Sure. But nobody ever proposed that - all the host can do is select a 
> source/destination address pair. That impacts where the packets flow but 
> doesn't touch routing policy itself.

I never understood this claim, but I've heard it multiple times. In my 
world, the source address chosen, and what outgoing router is chosen, are 
two completely different things.

It's only lately (past few years) with src/dst routing being mentioned, 
that this is now potentially changing.

Example:

R1 - H1 - R2

R1 is sending RAs with prio high. R2 is sending RAs with prio low. Host 
application chooses address from H1-R2 link. As far as I know, "all" hosts 
today will send out H1-R2 address sourced packet via R1.

What am I missing?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Philip Homburg <[email-masked]>
Date: Mon, 15 Aug 2016 14:13:27 +0200

>today will send out H1-R2 address sourced packet via R1.

I modified my stack to do full src/dst routing for the router part, but not the
host part (i.e. hosts get told by routers where to send packets using
redirects).

In some deployment situations where routers don't talk to each other it makes
sense for hosts to do src/dst routing as well.

There are many IPv4 deployments where a NAT box transparently handles multiple
upstreams that perform BCP38 ingress filtering.

Obviously, you want to support multiple independent upstreams in IPv6 as well,
preferably without having to introduce a single central routing box.

So that leads to a model where hosts have to be aware of which default router
to use for a particular source prefix.

I don't see the issue here. With redirects, routers are still in full control
of where packets go. Also in RAs, all routers can mark themselves as available
for all prefixes. 

So it is a feature, that in my opinion hosts should implement, that makes it
easiers to have multiple upstreams in an IPv6 enviroment, while still allowing
routers to be in control of how hosts behave.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 15 Aug 2016 21:28:55 +0900

On Fri, Jul 22, 2016 at 2:20 AM, Gert Doering <[email-masked]> wrote:

> In a fully controlled environment, you don't want the hosts to make
> decisions (unless directed by configured policy).  I just wanted to
> point out that "enterprise" and "SOHO" are really totally different
> problem spaces regarding multihoming and "who makes decisions?".

A fully controlled environment is one where the enterprise controls the
hosts.
An environment where the enterprise controls the network but not the hosts
is not a controlled environment.
Which one are you talking about here?

---

From: Joe Touch <[email-masked]>
Date: Mon, 15 Aug 2016 09:03:50 -0700

On 8/15/2016 3:06 AM, Mikael Abrahamsson wrote:
> Example:
>
> R1 - H1 - R2
>
> R1 is sending RAs with prio high. R2 is sending RAs with prio low.
> Host application chooses address from H1-R2 link. As far as I know,
> "all" hosts today will send out H1-R2 address sourced packet via R1.
>
> What am I missing? 

I'm missing it too.

In this case, H1 apps MUST be able to select the source address (either
based on R1 or R2 RAs).

Where the packet goes after that depends on the forwarding tables on H1,
redirects from R1 and R2, etc.

I.e., source IP MUST be application-selectable, but path might not.

Joe

---

From: Gert Doering <[email-masked]>
Date: Mon, 15 Aug 2016 20:35:45 +0200

Hi,

> Which one are you talking about here?

I think it was quite clear from the part that you did not quote what
the distinction was about.

"Decisions made by host / application" vs. "decisions made by the policy
administrator".

I'm not going to enter a hair-splitting contest on the wording of this.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 16 Aug 2016 08:28:54 +1200

> I.e., source IP MUST be application-selectable, but path might not.

Hence https://tools.ietf.org/html/draft-ietf-6man-multi-homed-host
which is in IESG review.

    Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 16 Aug 2016 08:44:58 +0900

> "Decisions made by host / application" vs. "decisions made by the policy

So are you just saying that whatever mechanism we defined for apps to
influence what path is taken by their traffic must include the ability for
the host administrator to configure and disable it? Or are you saying
something else?

---

From: Gert Doering <[email-masked]>
Date: Tue, 16 Aug 2016 11:57:28 +0200

Hi,

On Tue, Aug 16, 2016 at 08:44:58AM +0900, Lorenzo Colitti wrote:
> the host administrator to configure and disable it? 

No.

> Or are you saying something else?

I'm saying that there are two fairly distinct types of networks, with
different requirements.

Giving a simple example: in the "managed enterprise network" case, in
most cases, your machine would have ONE network interface, GUAs from ONE
network prefix, and ONE (redundant) gateway.  No need to influence anything 
on the host, because traffic will always go to the gateway, and all policy
happens on routers and/or firewalls.

In the homenet case, with addresses from multiple providers available 
on the host, what the application does makes a difference.

Gert Doering
        -- NetMaster

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 16 Aug 2016 20:59:16 +0900

> I'm saying that there are two fairly distinct types of networks, with

I don't think we can cleanly device all networks into to distinct types,
and I think it would be unwise to design a solution that made such an
assumption.

> happens on routers and/or firewalls.

That's the trivial case of a multihomed host with only one path.

---

From: Gert Doering <[email-masked]>
Date: Tue, 16 Aug 2016 14:49:20 +0200

Hi,

> and I think it would be unwise to design a solution that made such an

I'm not sure what the point of this thread is, especially referring to
a mail sent by me in a specific context some weeks(!) ago.

My experience in dealing with IETF is that there is quite a lot of people
that have tunnel vision.  

Networks differ, and while there are overlaps, you can't really dispute
that the majority clearly belongs in exactly one of the two categories
I've mentioned:

 - "no administrator on site, or no administrator at all" - SoHo / homenet
 - "network administrator on site, policy enforced by network devices"

the whole point of mentioning the *TWO* categories of networks regularily
is that those with the tunnel vision remember that there is a whole different
world from what they think "a network should be" - namely, the other camp.

> That's the trivial case of a multihomed host with only one path.

Indeed, for the *host*, it's the trivial case - and that is part of my 
point.  A network can be multihomed in many different ways, and *some*
of these variants are visible to the host, and would benefit from 
intelligence in the host, while others look like single-homed networks
to the host.

Gert Doering
        -- NetMaster