Subject: [homenet] Redirect and source-specific routing

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 12 Jul 2015 16:30:36 +0200

I'm wondering if there isn't some interaction between Redirect messages 
and source-specific routing that we're overlooking.  RFC 4861 Section 8.3 
says the following:

    Redirect messages apply to all flows that are being sent to a given
    destination.  That is, upon receipt of a Redirect for a Destination
    Address, all Destination Cache entries to that address should be
    updated to use the specified next-hop, regardless of the contents of
    the Flow Label field that appears in the Redirected Header option.

It does not speak of the source address, so I assume that this applies to 
all sources.  Consider the following topology:

    ---- A ---+--- B ----
              |
              H

If A and B advertise non-overlapping source-specific default routes and 
H is multiplexing its traffic over source addresses in both source 
prefixes (say, it's using MP-TCP), its Destination Cache entry will flap 
between A and B.

If I'm right, that argues in favour of an update to RFC 4861.

-- Juliusz

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 13 Jul 2015 08:41:22 +1200

On 13/07/2015 02:30, Juliusz Chroboczek wrote:
> I'm wondering if there isn't some interaction between Redirect messages and source-specific routing that we're overlooking. 
> RFC 4861 Section 8.3 says the following:
> 
> It does not speak of the source address, so I assume that this applies to all sources. 

It definitely should not, since in some topologies that might send packets
directly to a BCP38 filter. I think that's a 6man issue. I might even have to
modify my slides for 6man.

    Brian

> Consider the following topology:
> 
>    ---- A ---+--- B ----
>              |
>              H
> 
> If A and B advertise non-overlapping source-specific default routes and H is multiplexing its traffic over source addresses in
> both source prefixes (say, it's using MP-TCP), its Destination Cache entry will flap between A and B.
> 
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet
>

---

From: Ole Troan <[email-masked]>
Date: Mon, 13 Jul 2015 09:23:23 +0200

Juliusz,

> I'm wondering if there isn't some interaction between Redirect messages and source-specific routing that we're overlooking.  RFC 4861 Section 8.3 says the following:
> 
> It does not speak of the source address, so I assume that this applies to all sources.  Consider the following topology:
> 
>   ---- A ---+--- B ----
>             |
>             H
> 
> If A and B advertise non-overlapping source-specific default routes and H is multiplexing its traffic over source addresses in both source prefixes (say, it's using MP-TCP), its Destination Cache entry will flap between A and B.
> 

you are right. these issues are currently being discussed in 6man.
see http://tools.ietf.org/html/draft-sarikaya-6man-sadr-overview-07

we haven’t reached a conclusion if a source aware redirect is needed or not (if that’s what you had in mind). by the way, there is also ICMP unreachable code 5 (Source address failed ingress/egress policy), which I would think the router should send, rather than the redirect in this case.

cheers,
Ole

---

From: Pierre Pfister <[email-masked]>
Date: Mon, 13 Jul 2015 10:18:14 +0200

Hello Juliusz,

Indeed, RFC 4861 is pretty clear and Redirects seem to have a flow when used with sadr.
<gratuitous-ad-for-own-draft>
Updating RFC 4861 is one way to do it, we could also make hosts sadr-aware. 
</gratuitous-ad-for-own-draft>

Brian is going to lead a discussion in 6man about the whole hosts&sadr problem.

One interesting fact though is that Open-Source does not wait for IETF to fix IETF’s bugs.
http://lxr.free-electrons.com/source/net/ipv6/route.c#L1285
It looks like Linux looks at the IPv6 header within the redirect and 
only applies the redirect to the given source+dest pair.

- Pierre

> Le 13 juil. 2015 à 09:23, Ole Troan <[email-masked]> a écrit :
> 
> Juliusz,
>