Re: [homenet] source routing requirements for routing protocols

David Lamparter <equinox@diac24.net> Mon, 29 July 2013 14:33 UTC

Return-Path: <equinox@diac24.net>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 200DE21F9B4D for <homenet@ietfa.amsl.com>; Mon, 29 Jul 2013 07:33:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJV2cpHQlygn for <homenet@ietfa.amsl.com>; Mon, 29 Jul 2013 07:33:10 -0700 (PDT)
Received: from spaceboyz.net (spaceboyz.net [IPv6:2001:8d8:870:1000::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B57221F9D33 for <homenet@ietf.org>; Mon, 29 Jul 2013 07:32:40 -0700 (PDT)
Received: from [2001:8d8:81:5c2::] (helo=jupiter.n2.diac24.net) by spaceboyz.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1) (envelope-from <equinox@diac24.net>) id 1V3oUq-0003Ed-6i; Mon, 29 Jul 2013 16:32:24 +0200
Received: from equinox by jupiter.n2.diac24.net with local (Exim 4.80.1) (envelope-from <equinox@diac24.net>) id 1V3oUb-000yem-AE; Mon, 29 Jul 2013 16:32:13 +0200
Date: Mon, 29 Jul 2013 16:32:09 +0200
From: David Lamparter <equinox@diac24.net>
To: Lorenzo Colitti <lorenzo@google.com>
Message-ID: <20130729143209.GL901145@jupiter.n2.diac24.net>
References: <6856.1375095717@sandelman.ca> <10806.1375097238@sandelman.ca> <CAKD1Yr1E3ai9bP4OXbNCH=v_uCXpK_Yf2_cccAYwAv2b8v7e8A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAKD1Yr1E3ai9bP4OXbNCH=v_uCXpK_Yf2_cccAYwAv2b8v7e8A@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, "homenet@ietf.org" <homenet@ietf.org>, David Lamparter <equinox@diac24.net>
Subject: Re: [homenet] source routing requirements for routing protocols
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/homenet>
List-Post: <mailto:homenet@ietf.org>
List-Help: <mailto:homenet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homenet>, <mailto:homenet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Jul 2013 14:33:22 -0000

On Mon, Jul 29, 2013 at 03:35:41PM +0200, Lorenzo Colitti wrote:
> On Mon, Jul 29, 2013 at 1:27 PM, Michael Richardson
> <mcr+ietf@sandelman.ca>wrote:
> 
> > 1) if we are going to introduce a new route to deal with the
> >    conflict, then the routing protocol must be able to express
> >    what might appear to be multiple routes to the same dest/prefix.
> >
> 
> I believe the routes only need to be local and do not need to appear on the
> wire and in the routing protocol (in fact, they don't even need to be
> stored locally; the draft claims that they can be recalculated when adding
> / removing real routes from the FIB).
> 
> As regards the reason for existence of the routes themselves, David
> Lamparter tells me that he has in fact gotten the Linux IPv6 source routing
> code (the mythical CONFIG_IPV6_SUBTREES?) to work on 3.8. Attempting to CC
> a randomly-found email address I have for him so he can comment directly.
> David?

(warning: wall of text.  skip down to last paragraph for results.)

I've tested the following setup:

host A - router
# system: Linux 3.8.3
# CONFIG_IPV6_SUBTREES=y
# ip utility, iproute2-ss130221

# (0) enable ipv6 forwarding (...)

# (1) set routes

ip link add name test0 type dummy
ip link add name test1 type dummy
ip link add name test2 type dummy
ip link add name test3 type dummy
ip link set test0 up
ip link set test1 up
ip link set test2 up
ip link set test3 up
ip -6 route add 2001:db8::/32 via fe80::1 dev test0
ip -6 route add 2001:db8:dead::/48 from 2001:db8:cafe:1::/64 via fe80::1 dev test1
ip -6 route add 2001:db8:dead::/48 from 2001:db8:cafe:2::/64 via fe80::1 dev test2
ip -6 route add 2001:db8:dead::/48 from 2001:db8:cafe:2::f00d/128 via fe80::1 dev test3
ip -6 route add 2001:db8:dead:beef::/64 dev test3

# (2) connection to packet source - fix as needed
ip -6 link set veth0 up
ip -6 addr add fe80::1/64 dev veth0
ip -6 addr add 2001:db8:cafe:0::1/64 dev veth0
ip -6 addr add 2001:db8:cafe:1::1/64 dev veth0
ip -6 addr add 2001:db8:cafe:2::1/64 dev veth0

# (3) now start 4 tcpdumps/wiresharks/... on test0..3


host B - packet source

# - interlude: shortcut to virtualise host B, skip if appropriate -
#   unshare -n /bin/bash
# you now have a shell in a separate network namespace. now do:
#   ip link set lo up
#   ip link add name veth0 type veth peer name veth0 netns 1
# you now have a "veth0" interface on both your host and your network
# namespace shell session.  don't forget to set them "up".
# - end interlude -

# (0) default route over linklocal, persistent over tests
ip -6 route add ::/0 via fe80::1 dev veth0

# (1) source 2001:db8:cafe:0::2, does not match sources
ip -6 addr add 2001:db8:cafe:0::2/64 dev veth0
ping6 -c 3 2001:db8::1		 # => test0 on router
ping6 -c 3 2001:db8:dead::1	 # => unreachable, no route [*]
ping6 -c 3 2001:db8:dead:beef::1 # => test3 on router
ip -6 addr del 2001:db8:cafe:0::2/64 dev veth0

# (2) source 2001:db8:cafe:1::2, matches "test1" source spec
ip -6 addr add 2001:db8:cafe:1::2/64 dev veth0
ping6 -c 3 2001:db8::1		 # => test0 on router
ping6 -c 3 2001:db8:dead::1	 # => test1 on router
ping6 -c 3 2001:db8:dead:beef::1 # => test3 on router
ip -6 addr del 2001:db8:cafe:1::2/64 dev veth0

# (3) source 2001:db8:cafe:2::2, matches "test1" source spec
ip -6 addr add 2001:db8:cafe:2::2/64 dev veth0
ping6 -c 3 2001:db8::1		 # => test0 on router
ping6 -c 3 2001:db8:dead::1	 # => test2 on router
ping6 -c 3 2001:db8:dead:beef::1 # => test3 on router
ip -6 addr del 2001:db8:cafe:2::2/64 dev veth0

# (4) source 2001:db8:cafe:2::2, matches more-specific /128 source
ip -6 addr add 2001:db8:cafe:2::f00d/64 dev veth0
ping6 -c 3 2001:db8::1		 # => test0 on router
ping6 -c 3 2001:db8:dead::1	 # => test3 on router
ping6 -c 3 2001:db8:dead:beef::1 # => test3 on router
ip -6 addr del 2001:db8:cafe:2::f00d/64 dev veth0


so, for the 2001:db8:dead::1 destination, the following happens:
- source 2001:db8:cafe:0::2 - no source match - icmp unreachable
- source 2001:db8:cafe:1::2 - matches ...1::/64 dev test1
- source 2001:db8:cafe:2::2 - matches ...2::/64 dev test2
- source 2001:db8:cafe:2::f00d - matches ...2::f00d/128 dev test3


RESULT  (stop skipping here)
======

The non source specific routes keep working as intended.  The source
specific routes work as intended, doing a longest-match on the source.
The lookup also is "final", i.e. after not finding a route with a source
match (=> first test case), Linux returns an "unreachable".

As far as I've been following, this is the desired effect?

Cheers,


-David