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

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 4 Nov 2015 03:59:23 +0000

Minor updates related to Jinmei's comment and Okimoto's comment.

We are of course looking for working group review and comment.

> Begin forwarded message:
> 
> From: <[email-masked]>
> Subject: New Version Notification for draft-ietf-6man-multi-homed-host-02.txt
> Date: November 4, 2015 at 12:56:08 PM GMT+9
> To: "Brian E. Carpenter" <[email-masked]>, Fred Baker <[email-masked]>, Brian Carpenter <[email-masked]>
> 
> 
> A new version of I-D, draft-ietf-6man-multi-homed-host-02.txt
> has been successfully submitted by Fred Baker and posted to the
> IETF repository.
> 
> Name:		draft-ietf-6man-multi-homed-host
> Revision:	02
> Title:		Routing packets from hosts in a multi-prefix network
> Document date:	2015-11-03
> Group:		6man
> Pages:		13
> URL:            https://www.ietf.org/internet-drafts/draft-ietf-6man-multi-homed-host-02.txt
> Status:         https://datatracker.ietf.org/doc/draft-ietf-6man-multi-homed-host/
> Htmlized:       https://tools.ietf.org/html/draft-ietf-6man-multi-homed-host-02
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-multi-homed-host-02
> 
> Abstract:
>   This document 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.
> 
> 
> 
> 
> 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: Pierre Pfister <[email-masked]>
Date: Wed, 4 Nov 2015 16:33:08 +0900

Hello, 

Following the meeting this morning, I was asked to bring this point to the mailing list.

As a reminder, there are two issues with multi-homed hosts with multiple routers on the same link and redirects.

1. If the host does redirects in the RFC4861’s way: 
    We may end-up with 'redirect ping-pongs’. (c.f. archives. I think I explained it twice already).

2. If the host does not do redirects at all: 
    We have non-optimal routing.

The current document addresses this issue with the following text:

————
3.4.  Redirects

   There is potential for adverse interaction with any off-link Redirect
   (Redirect for a GUA destination that is not on-link) 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 may
   need to contain appropriate source-specific entries.
————

This text is correct and addresses the issue, **given that** the host implements that SHOULD.

Example:
Imagine WiFi station with a host (H) and 2 routers (A and B) connected as stations.
A and B are synchronized and thus advertise the same PIOs (HNCP, from homenet, works this way).
H wants to send a packet. Because there is ambiguity with PIOs, it picks one randomly (let’s say A).
Because A and B run a routing protocol, A redirects the packet to B and sends a redirect to the host.
If the host does not do redirects, then every single packet will do H -> A -> B -> Internet.

In this WiFi based setup, each sent packet is transmitted ** 4 TIMES ** on the same collision domain.

That is really bad.

Btw, here is the part of RFC4861 that matters too:
——
8.3 <https://tools.ietf.org/html/rfc4861#section-8.3>.  Host Specification

   A host receiving a valid redirect SHOULD update its Destination Cache
   accordingly so that subsequent traffic goes to the specified target.
   If no Destination Cache entry exists for the destination, an
   implementation SHOULD create such an entry.
——

In addition, RFC4861 says that routers MUST rate-limit redirects. Which means that depending on that ‘rate’,
some messages may not results in redirects. Which means that the scenario described before may even happen
when the host actually supports redirects… But genuinely sends packets to many different destinations.

So, I have two questions:

1. Will host actually implement this if this is only a ‘SHOULD’ (And here I speak about all hosts, from cheap to expensive ones).

2. Even though they do. I would like the group to understand that this solution *relies* on redirects to work.
    I therefore ask the question again: Do we really want this solution to **rely** on redirects to work ?

Thanks,

- Pierre    

> Le 4 nov. 2015 à 12:59, Fred Baker (fred) <[email-masked]> a écrit :
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Timothy Winters <[email-masked]>
Date: Wed, 11 Nov 2015 08:30:22 -0500

Hi Pierre,

Every host that has obtained the IPv6 Ready Logo support processing of
Redirect messages.  A host initially configuration might be to reject
redirects due for "security concerns" but for the most part this is widely
supported.

Regards,
Tim

On Wed, Nov 4, 2015 at 2:33 AM, Pierre Pfister <[email-masked]> wrote:

> 1. Will host actually implement this if this is only a ‘SHOULD’ (And here
> I speak about all hosts, from cheap to expensive ones).
>
> To: "Brian E. Carpenter" <[email-masked]>, Fred Baker <
> [email-masked]>, Brian Carpenter <[email-masked]>
>
>
> URL:
> https://www.ietf.org/internet-drafts/draft-ietf-6man-multi-homed-host-02.txt
> Status:
> https://datatracker.ietf.org/doc/draft-ietf-6man-multi-homed-host/
> Htmlized:
> https://tools.ietf.org/html/draft-ietf-6man-multi-homed-host-02
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-multi-homed-host-02
>
> Abstract:

-- 

Timothy Winters
UNH-IOL Senior Executive, Software and IP Networking
603-421-4987
IOL INTACT <https://www.iol.unh.edu/solutions/test-tools/intact>, an IPv6
test tool, helped participants verify products and prototypes at the CEA’s
IPv6 plugfest.
Read more at: http://bit.ly/1IOKePo

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Nov 2015 11:40:12 +1300

Pierre,

> I speak about all hosts, from cheap to expensive ones).

I would have no problem changing it to a MUST. But it remains conditional
- it's only relevant if the router happens to send a redirect. If there is
no redirect, the host can only contniue to assume that a router that announces
a prefix is capable of forwarding towards that prefix.

> solution *relies* on redirects to work.

Why? If a router does not send a redirect, that means either the router is
broken, so we can do nothing, or it is happy to forward to the destination,
so everything is fine.

   Brian

> **rely** on redirects to work ?

Regards
   Brian Carpenter
   http://orcid.org/0000-0001-7924-6182

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 11 Nov 2015 22:47:11 +0000

> On Nov 12, 2015, at 7:40 AM, Brian E Carpenter <[email-masked]> wrote:
> 

I'm actually not even sure it relies on redirects. If the router sends a redirect and the host ignores it, the router obviously knows where to forward the packet to. This has been true with IPv4 redirects since the dawn of time (or 1981, whichever came first).

I guess my question is what the real issue is. As someone else noted, hosts that have IPv6-ready logos have been tested and do operate on redirects, and even if they didn't, it would not be the end of the world. Elaborate on the concern?

---

From: Pierre Pfister <[email-masked]>
Date: Thu, 12 Nov 2015 07:27:12 +0100

Brian, and Fred,

In the absence of redirects, or when the host does not support redirects, the packet would be routed correctly.
What I am saying, is that redirection is not a viable option. As indicated, on wifi, this could end-up with a throughput
divided by 4.
That situation is what makes me say it relies on redirects, as the absence of redirects create dramatic scenarios.

> Le 11 nov. 2015 à 23:40, Brian E Carpenter <[email-masked]> a écrit :
> 
> Pierre,
>

---

From: Mark Smith <[email-masked]>
Date: Thu, 12 Nov 2015 18:42:15 +1100

On 12 Nov 2015 5:28 PM, "Pierre Pfister" <[email-masked]> wrote:
> What I am saying, is that redirection is not a viable option. As
indicated, on wifi, this could end-up with a throughput
> divided by 4.

So the only way to avoid redirects and avoid double hops on the first link
layer hop, is for hosts to have complete and accurate knowledge of all
networks upstream of the candidate first hop routers. How would you propose
to achieve that without running a fully fledged routing protocol on the
hosts like OSPF or BGP in the case of the Internet?

Regards,
Mark.

> That situation is what makes me say it relies on redirects, as the
absence of redirects create dramatic scenarios.
> >>    I therefore ask the question again: Do we really want this solution
to
> >> **rely** on redirects to work ?
> >
> >
> >
> > Regards
> >   Brian Carpenter
> >> As a reminder, there are two issues with multi-homed hosts with
multiple routers on the same link and redirects.
> >> In addition, RFC4861 says that routers MUST rate-limit redirects.
Which means that depending on that ‘rate’,
> >> some messages may not results in redirects. Which means that the
scenario described before may even happen
> >> 1. Will host actually implement this if this is only a ‘SHOULD’ (And
here I speak about all hosts, from cheap to expensive ones).

---

From: Pierre Pfister <[email-masked]>
Date: Thu, 12 Nov 2015 09:05:09 +0100

Hello Mark,

You asked for it. ;-)
https://tools.ietf.org/html/draft-pfister-6man-sadr-ra-01

Regards,
- Pierre

> Le 12 nov. 2015 à 08:42, Mark Smith <[email-masked]> a écrit :
> 
> 
> On 12 Nov 2015 5:28 PM, "Pierre Pfister" <[email-masked] <mailto:[email-masked]>> wrote:
> >
> > Brian, and Fred,
> >
> So the only way to avoid redirects and avoid double hops on the first link layer hop, is for hosts to have complete and accurate knowledge of all networks upstream of the candidate first hop routers. How would you propose to achieve that without running a fully fledged routing protocol on the hosts like OSPF or BGP in the case of the Internet?
> 
> Regards,
> Mark.
> 
> > > Le 11 nov. 2015 à 23:40, Brian E Carpenter <[email-masked] <mailto:[email-masked]>> a écrit :
> > >
> > > Pierre,
> > >
> > >   http://orcid.org/0000-0001-7924-6182 <http://orcid.org/0000-0001-7924-6182>
> > >
> > >
> > >
> > >> 8.3 <https://tools.ietf.org/html/rfc4861#section-8.3 <https://tools.ietf.org/html/rfc4861#section-8.3>>.  Host Specification
> > >>
> > >>> Le 4 nov. 2015 à 12:59, Fred Baker (fred) <[email-masked] <mailto:[email-masked]>> a écrit :
> > >>>
> > >>>> From: <[email-masked] <mailto:[email-masked]>>
> > >>>> To: "Brian E. Carpenter" <[email-masked] <mailto:[email-masked]>>, Fred Baker <[email-masked] <mailto:[email-masked]>>, Brian Carpenter <[email-masked] <mailto:[email-masked]>>
> > >>>>
> > >>>>
> > >>>> URL:            https://www.ietf.org/internet-drafts/draft-ietf-6man-multi-homed-host-02.txt <https://www.ietf.org/internet-drafts/draft-ietf-6man-multi-homed-host-02.txt>
> > >>>> Status:         https://datatracker.ietf.org/doc/draft-ietf-6man-multi-homed-host/ <https://datatracker.ietf.org/doc/draft-ietf-6man-multi-homed-host/>
> > >>>> Htmlized:       https://tools.ietf.org/html/draft-ietf-6man-multi-homed-host-02 <https://tools.ietf.org/html/draft-ietf-6man-multi-homed-host-02>
> > >>>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-multi-homed-host-02 <https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-multi-homed-host-02>
> > >>>>
> > >>>> Abstract:
> > >>>> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
> > >>>>
> > >>>> The IETF Secretariat
> > >>>>
> > >>>
> > >>> [email-masked] <mailto:[email-masked]>
> > >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
> > >> [email-masked] <mailto:[email-masked]>
> > >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
> > [email-masked] <mailto:[email-masked]>
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 12 Nov 2015 19:30:44 +0000

> On Nov 12, 2015, at 12:05 AM, Pierre Pfister <[email-masked]> wrote:
> 
> Hello Mark,
> 
> You asked for it. ;-)
> https://tools.ietf.org/html/draft-pfister-6man-sadr-ra-01 <https://tools.ietf.org/html/draft-pfister-6man-sadr-ra-01>
Of course, right, wrong, or indifferent, the working group hasn't adopted that.

> Regards,
> - Pierre
> 
> 
>> Le 12 nov. 2015 à 08:42, Mark Smith <[email-masked] <mailto:[email-masked]>> a écrit :
>> 
>>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 13 Nov 2015 08:44:25 +1300

> That situation is what makes me say it relies on redirects, as the absence of redirects create dramatic scenarios.

I'm not a logician, but I really cannot parse your argument as far as the current
draft is concerned. We say that if there are redirects they SHOULD/MUST be interpreted
per prefix, and memorised.

IMHO, whether redirects should or should not be sent is out of scope for this
document.

   Brian

> .

---

From: David Farmer <[email-masked]>
Date: Thu, 12 Nov 2015 15:59:30 -0600

So, I think I see the disconnect here.

This draft doesn't need redirects to accomplish its intent, sending 
traffic out the right provider when there are two or more providers. So 
traffic isn't blocked by a BCP38 type filter, if sent out the wrong 
provider.  That is why Brian says redirects are out of scope.

However, within a complicated local topology with multiple local routers 
for the same delegated prefix, on the same subnet with the host, one of 
the multiple routers will likely be more optimal than the others within 
the topology.  Among these routers redirects are necessary or there 
could be performance impacts, by choosing a sub-optimal exit router from 
the local subnet.

But, this is true with a complicated local topology and only one 
upstream provider. This draft only ensures that a host picks the correct 
router associated with the prefix delegated by a provider within the 
local topology.  It doesn't ensure the optimal exit router is chosen 
within a complicated local topology, just that the traffic will exit the 
local topology using the correct provider.

Choosing the optimal subnet exit router within a complicated local 
topology is a different problem and I don't think this draft should 
tackle it.

Maybe the best way to illustrate and discuss this issue (clarifying that 
it is out of scope) is to add an example with a more complicated local 
topology than the current two simple examples in figure two.

Thanks.

-- 
================================================
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: Pierre Pfister <[email-masked]>
Date: Fri, 13 Nov 2015 08:21:27 +0100

> Le 12 nov. 2015 à 20:30, Fred Baker (fred) <[email-masked]> a écrit :
> 
> 
>> On Nov 12, 2015, at 12:05 AM, Pierre Pfister <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hello Mark,
>> 
>> You asked for it. ;-)

It hasn’t been given the opportunity to do so.
But my point is just to make clear the pros and cons of the adopted solution.
If the working group decides suboptimal routing, or optimal routing using redirects, are fine options,
my mission is done here.

---

From: [email-masked]
Date: Fri, 13 Nov 2015 08:49:52 +0100

Pierre, et al,

> If the working group decides suboptimal routing, or optimal routing using redirects, are fine options,

The basis for this work is outlined here:
https://www.ietf.org/proceedings/93/slides/slides-93-6man-6.pdf

See especially slide 9 for what's considered a failure or not.

if you look at the general problem of host-based routing, then a new RA SADR option wouldn't really solve that. you could easily have more than 17 routes in the system.
the simple operational choice here is to just build smaller L2 links.

Best regards,
Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 13 Nov 2015 20:24:39 +0900

> See especially slide 9 for what's considered a failure or not.

"Suboptimal performance is an application issue."

Translation: "we don't want to solve this problem, so we're going to give
up and blame applications when things are slow".

Routing is hard. Let's go shopping?

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 13 Nov 2015 12:30:50 +0000

> On Nov 12, 2015, at 1:59 PM, David Farmer <[email-masked]> wrote:
> 
> Maybe the best way to illustrate and discuss this issue (clarifying that it is out of scope) is to add an example with a more complicated local topology than the current two simple examples in figure two.

I agree that it would help respond to the question. However, in my opinion, even that is beyond our scope.

We clearly expect, and say that we expect, the network that the host is in to have some solution for source/destination routing. That might be as simple as having a single LAN and expecting the host to send packets to one of several routers depending on the PIOs that they themselves emit, and it might be as complex as someone wants to make it.

The discussion of this draft has shown that every word we add on the topic begs for a paragraph more to "clarify" it. The paragraphs are in fact needed - but in a draft on source/destination routing, which is in development in homenet and rtgwg, and potentially in ospf and isis. I, speaking for myself, would rather leave them there.

That is also the guidance that the chairs have given us. They want us to not change the bits on the wire, with a view to advancing 2460bis and is cousins to STANDARD status, and instead give guidance on how to use what is there to address this issue. Brian and I are trying very hard to cooperate with that guidance.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 14 Nov 2015 07:55:46 +1300

> Routing is hard. Let's go shopping?

Those were slides and the discussion in Prague was useful. The draft now
hopefully doesn't convey that message. But path optimisation is not
the goal of this draft; its goal is to eliminate certain failure modes.
See Fred's latest note for more.

   Brian

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 13 Nov 2015 19:09:04 +0000

On Nov 13, 2015, at 10:55 AM, Brian E Carpenter <[email-masked]> wrote:
> But path optimisation is not the goal of this draft; its goal is to eliminate certain failure modes.

Yes. If I have two routers on the same LAN and I send a packet to the wrong one, in the worst case that router spends a few microseconds, maybe a millisecond, getting it to the right router. That's not a failure. What I'm concerned about is scenarios in which a router gets picked that doesn't have the information to get the packet to the correct router, or perhaps doesn't have a path; those would be failures.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 17 Nov 2015 09:59:34 +0900

On Sat, Nov 14, 2015 at 4:09 AM, Fred Baker (fred) <[email-masked]> wrote:

> Yes. If I have two routers on the same LAN and I send a packet to the
> wrong one, in the worst case that router spends a few microseconds, maybe a
> millisecond, getting it to the right router. That's not a failure. What I'm
> concerned about is scenarios in which a router gets picked that doesn't
> have the information to get the packet to the correct router, or perhaps
> doesn't have a path; those would be failures.
>

Thinking about it some more, I think solving this problem by making
redirects source-specific is a bad idea.

The way I see it, we have two options:

   1. For every new source address / destination address combination, send
   a redirect to the host. The host needs to keep track of that.
   2. Tell the host in advance that certain source address prefixes should
   preferably go to certain routers.

I think #1 performs worse than #2, and it also involves a lot more state on
the host, because it needs to keep track of all source/dest pairs.

I posit that:

   1. We have to make host changes anyway, to make redirects
   source-specific.
   2. We have to make router changes anyway, to support src+dest routing.

Given that we have to change things anyway, wouldn't we just pick the
better solution, and just communicate to the hosts in advance that certain
source prefixes should prefer certain destinations? That's much better than
relying on redirects.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 17 Nov 2015 01:07:45 +0000

> On Nov 17, 2015, at 1:59 PM, Lorenzo Colitti <[email-masked]> wrote:
> 
> Given that we have to change things anyway, wouldn't we just pick the better solution, and just communicate to the hosts in advance that certain source prefixes should prefer certain destinations? That's much better than relying on redirects.

Isn't that what the draft says that a "default router option" does? When an RA is received indicating that a router wants to be a default router, we make it a/the default router for the prefixes in that RA's PIOs?

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 17 Nov 2015 14:52:57 +1300

> Isn't that what the draft says that a "default router option" does? When an RA is received indicating that a router wants to be a default router, we make it a/the default router for the prefixes in…

Exactly. That's where we started. We have no choice but to add what should happen
*if* redirects are received, but that is an *if* and the normal case is that
there are no redirects.

We agree, I think, that *if* you want to optimise routing, redirects are not
the best way, but that is explicitly not the problem the WG chairs asked us
to solve. When this draft is done and dusted, we've had proposals from Behcet
and Pierre to solve the other problem.

Can we please do one thing at a time?

    Brian

---

From: Pierre Pfister <[email-masked]>
Date: Tue, 17 Nov 2015 10:26:38 +0100

> Le 17 nov. 2015 à 02:52, Brian E Carpenter <[email-masked]> a écrit :
> 

So you consider Homenet architecture is not the normal case of home networks.
I don’t know if the problem comes from Homenet or 6man, but there certainly is an issue 
somewhere about that.

> Can we please do one thing at a time?

So you are solving half-a-problem, requiring both hosts changes
and routers changes, and that is for the sake of not changing bits on the wire.
And on the other hand you are telling that we should change bits on the wire in a further document,
which would again require hosts and routers changes, in order to solve the same problem all over again because
we knew the original solution was not sufficient.

Regards,

- Pierre

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 17 Nov 2015 18:36:58 +0900

> Can we please do one thing at a time?

Not if the solution to problem #2 will also solve problem #1, no.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 17 Nov 2015 09:40:16 +0000

> On Nov 17, 2015, at 10:26 PM, Pierre Pfister <[email-masked]> wrote:

Bluntly, I don't care whether Homenet architecture typifies residential networks. I'm trying to address IPv6 networks, and many of them are non-residential.

---

From: [email-masked]
Date: Tue, 17 Nov 2015 10:48:20 +0100

Lorenzo,

> Not if the solution to problem #2 will also solve problem #1, no.

What exactly are you proposing?

Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 17 Nov 2015 19:27:00 +0900

> What exactly are you proposing?

Better information to the hosts upfront.

As I understand it, the problem is as follows. Consider a link with prefix
A coming from router R1 and prefix B coming from router R2. Currently, if
an unmodified host H sends packet to with a source address in B through R1,
then R1 will send a redirect to R2. The problem is that if H now sends a
packet through R2 to the same destination, then R2 will send a redirect to
R1.

The current proposal is to keep the same behaviour in the network and
require that H remember redirects for source+destination pairs. But that is
inefficient, and requires changes to hosts. If we're already making changes
to hosts, then why don't we just tell the hosts upfront that packets to
off-link destinations sent from prefix B should be sent to R2?

In effect we're giving the hosts the same information as the redirects, but
more efficiently, because it's on the basis of a whole prefix instead of a
given source address.

I can see two ways to do this: source prefix information in RAs or source
prefix information in redirects.

---

From: [email-masked]
Date: Tue, 17 Nov 2015 11:34:06 +0100

Lorenzo,

> As I understand it, the problem is as follows. Consider a link with prefix A coming from router R1 and prefix B coming from router R2. Currently, if an unmodified host H sends packet to with a source address in B through R1, then R1 will send a redirect to R2. The problem is that if H now sends a packet through R2 to the same destination, then R2 will send a redirect to R1.

_may_ send redirects.

> The current proposal is to keep the same behaviour in the network and require that H remember redirects for source+destination pairs. But that is inefficient, and requires changes to hosts. If we're already making changes to hosts, then why don't we just tell the hosts upfront that packets to off-link destinations sent from prefix B should be sent to R2?

the proposal is not about redirects.
it is about making hosts act on the information they already have.

 I'm not sure what you are disagreeing with.

> In effect we're giving the hosts the same information as the redirects, but more efficiently, because it's on the basis of a whole prefix instead of a given source address.
> 
> I can see two ways to do this: source prefix information in RAs or source prefix information in redirects.

cheers,
Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 17 Nov 2015 19:48:25 +0900

> it is about making hosts act on the information they already have.

They don't already have that information.

Today, a redirect means "if you want to reach this address, prefer that
next-hop". That is the information they have. This document proposes
changing the meaning of the redirect packet to "if you want to reach this
address *from the address you just used*, prefer that next-hop".

In other words, the proposal specifies how to communicate new information
to the host. I disagree with how it proposes to do so. Communicating it in
redirects on a per-source-address basis is inefficient and consumes large
amounts of state on hosts.

---

From: [email-masked]
Date: Tue, 17 Nov 2015 11:54:43 +0100

Lorenzo,

> Today, a redirect means "if you want to reach this address, prefer that next-hop". That is the information they have. This document proposes changing the meaning of the redirect packet to "if you want to reach this address *from the address you just used*, prefer that next-hop".
> 
> In other words, the proposal specifies how to communicate new information to the host. I disagree with how it proposes to do so. Communicating it in redirects on a per-source-address basis is inefficient and consumes large amounts of state on hosts.

if you are referring to section 3.4, that's not the main purpose of the document.

Ole

---

From: Philip Homburg <[email-masked]>
Date: Tue, 17 Nov 2015 12:36:13 +0100

>source prefixes should prefer certain destinations? That's much better than

My home is setup such that I have multiple upstreams distributed over two 
routers. For extra fun, I usually give one router the highest priority
as default router and let another router handle the upstream of the currently
preferred source prefix.

In my own implementation, the destination cache also includes the source
address. That's no big deal. You have pass an extra parameter every now and
then. I don't think the extra traffic will show up (or extra memory usage)

My routers do src+dest routing and they send redirects. Experience shows that 
this is fully compatible with Linux, FreeBSD, OSX as host operating systems. 

Obviously, those systems would ping-pong between routers if they would
randomly pick source addresses. It requires more study if operating
systems really do that, or if they sort of pick a preferred source address
(at least per destination).

(I like the concept that hosts should take the PIO option into account when
selecting a default router, though I have no idea yet of the complexity of
actually implementing that feature)

---

From: Pierre Pfister <[email-masked]>
Date: Tue, 17 Nov 2015 13:06:51 +0100

> Le 17 nov. 2015 à 11:54, [email-masked] a écrit :
> 
> Lorenzo,
> 

You say it is not the point of that document, but it is exactly that piece which makes it work in some scenarios,
e.g., the one detailed in the first mail of this thread.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 17 Nov 2015 08:53:57 -0500

> As I understand it, the problem is as follows. Consider a link with
    > prefix A coming from router R1 and prefix B coming from router
    > R2. Currently, if an unmodified host H sends packet to with a source
    > address in B through R1, then R1 will send a redirect to R2. The
    > problem is that if H now sends a packet through R2 to the same
    > destination, then R2 will send a redirect to R1.

    > require that H remember redirects for source+destination pairs. But
    > that is inefficient, and requires changes to hosts. If we're already
    > making changes to hosts, then why don't we just tell the hosts upfront
    > that packets to off-link destinations sent from prefix B should be sent
    > to R2?

    > In effect we're giving the hosts the same information as the redirects,
    > but more efficiently, because it's on the basis of a whole prefix
    > instead of a given source address.

I'm with Lorenzo: if hosts need to learn about any new tricks let, them learn
listening to routing protocol tricks.
*MIF* stuff already pushes them to know this stuff anyway.

In the meantime, R1/R2 are going to have to make up for hosts that don't get
it right.

(My office LAN has been transitioning [more than 1 year] from a sixxs tunnel on
router R1, to native IPv6 on R2, and we have *exactly* this problem.  There
are an awful lot of corner cases on R1 and R2, particularly since both of
them have multiple other interfaces....  Since R1 and R2 have different
outside connectivity, we mostly are leaving R1 on, because it's good to have
backup)

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: [email-masked]
Date: Tue, 17 Nov 2015 16:43:36 +0100

Michael,

> outside connectivity, we mostly are leaving R1 on, because it's good to have

What changes are you proposing to this draft?

Best regards,
Ole

---

From: 神明達哉 <[email-masked]>
Date: Tue, 17 Nov 2015 09:16:04 -0800

At Tue, 17 Nov 2015 19:27:00 +0900,

> packet through R2 to the same destination, then R2 will send a redirect to

I don't understand why R2 could send a redirect in this scenario...if
the assumption is that H is an unmodified host, wouldn't it (quite
likely) use the same source address from prefix B?  If so, the
redirect from R2 shouldn't be because of the prefix-source mismatch.
Does this scenario perhaps assume that the next hop to the
destination for R2 is R1 (i.e., R2 sends a redirect because of the
destination address, not because of the source address)?  Or does it
assume that H now uses the source address from prefix A and sends it
to R2?

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 18 Nov 2015 07:55:13 +1300

> amounts of state on hosts.

Yes. It's a bad idea. It's not what the draft proposes or recommends. But
if it happens stacks need to do somethinng. That's the only reason  we added
any mention of redirects. But they are a side-show as far as this draft
is concerned.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 18 Nov 2015 08:00:15 +1300

> In the meantime, R1/R2 are going to have to make up for hosts that don't get

Well yes, if you haven't noticed the draft also wants routers to do sadr.
If you put a sadr routing protocol into every host too, the whole problem
is solved. But that doesn't seem very likely to happen.

BTW, the subject of this thread is confusing. draft-ietf-6man-multi-homed-host
does not rely on redirects. It just says what to do *if* a host receives a
redirect.

   Brian