Re: draft-baker-6man-multiprefix-default-route-00.txt is a newdraft

Pekka Savola <pekkas@netcore.fi> Tue, 13 November 2007 05:27 UTC

Return-path: <ipv6-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IroIs-0002WL-JW; Tue, 13 Nov 2007 00:27:14 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IroIq-0002Ue-8z for ipv6@ietf.org; Tue, 13 Nov 2007 00:27:12 -0500
Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IroIp-00043J-Nu for ipv6@ietf.org; Tue, 13 Nov 2007 00:27:12 -0500
Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id lAD5R1NL009188; Tue, 13 Nov 2007 07:27:01 +0200
Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id lAD5R1WG009179; Tue, 13 Nov 2007 07:27:01 +0200
Date: Tue, 13 Nov 2007 07:27:00 +0200
From: Pekka Savola <pekkas@netcore.fi>
To: Havard Eidnes <he@uninett.no>
In-Reply-To: <20071112.172700.95023288.he@uninett.no>
Message-ID: <Pine.LNX.4.64.0711130721170.8801@netcore.fi>
References: <6A990F09-F0D4-43AA-BA1F-D81AB94628D6@cisco.com> <55C1E39E-7FE1-4912-B730-017C1C5CAC09@it.uc3m.es> <A4AE6069-5936-4C7E-AFD6-6100FB66A8EE@cisco.com> <20071112.172700.95023288.he@uninett.no>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
X-Virus-Scanned: ClamAV 0.91.2/4757/Mon Nov 12 19:20:27 2007 on otso.netcore.fi
X-Virus-Status: Clean
X-Spam-Status: No, score=-3.6 required=5.0 tests=ALL_TRUSTED, AWL, BAYES_00 autolearn=ham version=3.2.3
X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on otso.netcore.fi
X-Spam-Score: -1.4 (-)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Cc: marcelo@it.uc3m.es, ipv6@ietf.org, fred@cisco.com
Subject: Re: draft-baker-6man-multiprefix-default-route-00.txt is a newdraft
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
Errors-To: ipv6-bounces@ietf.org

On Mon, 12 Nov 2007, Havard Eidnes wrote:
> Instead, my inclination would be to "solve" this problem in a
> much simpler manner, simply by declaring it a configuration
> error.  A site which receives prefixes from more than a single
> provider is clearly multihomed, and needs to have its providers
> make appropriate exceptions to a strict "I will only accept
> packets with source addresses from within the prefix I delegate"
> rule.

Who's watching the watchers?

An architecture where you depend on the first hop ISP to do filtering 
and you cannot check that it has been done further down the network 
doesn't do enough to keep ISPs "honest".

   Either that, or the domain in question needs to ensure via
> a combination of address selection and routing policy that one
> avoids being subjected to (presumably unwanted) RPF failures.

I think Fred's solution is proposing a solution in (mostly) simpler 
scenarios which are typically unmanaged.  A default policy, if such 
could be created, shipping in smaller routers could fulfill this goal.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------