Re: [homenet] dst/src routing drafts (for IETF-91 rtgwg)

David Lamparter <> Thu, 30 October 2014 00:39 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3FF891ACE84; Wed, 29 Oct 2014 17:39:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id t7mUoPCyNoKy; Wed, 29 Oct 2014 17:39:40 -0700 (PDT)
Received: from ( [IPv6:2a02:238:f02a:8e2f:1::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1784A1ACE81; Wed, 29 Oct 2014 17:39:39 -0700 (PDT)
Received: from equinox by with local (Exim 4.84) (envelope-from <>) id 1Xjdm1-000DwA-SK; Thu, 30 Oct 2014 01:39:34 +0100
Date: Thu, 30 Oct 2014 01:39:33 +0100
From: David Lamparter <>
To: "Fred Baker (fred)" <>
Message-ID: <20141030003933.GS5186@eidolon>
References: <> <> <> <> <> <20141029062837.GH5186@eidolon> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
User-Agent: Mutt/1.5.22 (2013-10-16)
Cc: Ole Troan <>, Ray Hunter <>, David Lamparter <>, "" <>, "" <>, Mikael Abrahamsson <>
Subject: Re: [homenet] dst/src routing drafts (for IETF-91 rtgwg)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 30 Oct 2014 00:39:42 -0000

[plucking a paragraph from the middle]
On Wed, Oct 29, 2014 at 04:09:15PM +0000, Fred Baker (fred) wrote:
> I suspect the company you are discussing might have a number of small
> offices in as many cities, and as many PA prefixes as it takes. The
> company might also have a PI prefix, but I would be surprised if it
> used the PI prefix in all of its little offices; if it did, it would
> essentially use it for internal traffic, and have some sort of VPN
> connecting the offices on which it was used. It would, however, use
> the PA prefixes from the offices when they need to talk outside the
> house. If it is using the PI prefix plus a PA prefix in any given
> office, it would depend on RFC 6724’s Rule 8 (longest match) to prefer
> a PI address when talking to another address within the prefix, and a
> temporary address from PA space otherwise.

If there is an overlap of a company-wide numbering plan with local
connectivity, that might actually be use-case for a SADR route whose
destination isn't ::/0.  Though you could always do that with a simple
destination route for the company-wide prefix, what you can now do is
signal the correlations between routes.  (Except we don't have a
protocol to communicate this to the host yet.)

I'm imagining a route table like this:
(:cccc: being the company-wide PI)

::/0 from 2001:db8:1::/48 via PA-provider-1
::/0 from 2001:db8:2::/48 via PA-provider-2
::/0 from 2001:db8:cccc::/48 unreachable
2001:db8:cccc::/48 from 2001:db8:cccc::/48 via IPsec-gateway
2001:db8:cccc::/48 from ::/0 unreachable

Where the last route would prevent accidental leaking of packets onto
the internet in case the IPsec gateway malfunctions.  (The 3rd route is
redundant if there's no "::/0 from ::/0")

But - apart from ease of use for multiple prefixes, this can be done
without SADR just fine, the only advantage is that there's full
information regarding which source addresses work with which
destinations.  If we get that to hosts, and into their source address
selection, then we won something.

(And this is really the same as homenet walled-garden scenarios, where
an ISP uses a separate prefix for some [IPTV, whatever] service and
expects clients to use a distinct source prefix to get to that service.
Then again, "secret gardens are better than walled gardens.")