Re: [shim6] Exit selection

Rémi Després <remi.despres@free.fr> Mon, 14 March 2011 09:31 UTC

Return-Path: <remi.despres@free.fr>
X-Original-To: shim6@core3.amsl.com
Delivered-To: shim6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53CB13A6C5E for <shim6@core3.amsl.com>; Mon, 14 Mar 2011 02:31:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.158
X-Spam-Level:
X-Spam-Status: No, score=0.158 tagged_above=-999 required=5 tests=[AWL=-0.793, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_33=0.6, MANGLED_PAIN=2.3, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPlP6dGmTkag for <shim6@core3.amsl.com>; Mon, 14 Mar 2011 02:31:37 -0700 (PDT)
Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.81]) by core3.amsl.com (Postfix) with ESMTP id BA1EF3A6AEE for <shim6@ietf.org>; Mon, 14 Mar 2011 02:31:29 -0700 (PDT)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2419.sfr.fr (SMTP Server) with ESMTP id CB2807000094; Mon, 14 Mar 2011 10:32:52 +0100 (CET)
Received: from [192.168.0.14] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2419.sfr.fr (SMTP Server) with ESMTP id 2AC7D7000092; Mon, 14 Mar 2011 10:32:52 +0100 (CET)
X-SFR-UUID: 20110314093252175.2AC7D7000092@msfrf2419.sfr.fr
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= <remi.despres@free.fr>
In-Reply-To: <733F86F7-54F7-4544-B139-5F534F143DA6@apnic.net>
Date: Mon, 14 Mar 2011 10:32:51 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <2CA07AD5-8FFE-4E21-A7DE-E3116082252A@free.fr>
References: <20110228223003.13022.10464.idtracker@localhost> <845A4F08-46E7-48EE-B294-0C8368BAD1CB@cisco.com> <20110302072822.GA20321@serpens.de> <5AC61190-49B0-49B5-ACB1-1FA5082C0380@cisco.com> <20110302203006.GI23030@serpens.de> <4D6EB08E.9000109@gmail.com> <20110302214913.GG20321@serpens.de> <4D6EC293.90608@gmail.com> <20110303065132.GH20321@serpens.de> <4D6FF098.6010600@gmail.com> <A3C0405F-F5E1-4911-A67B-CB3FCD153B29@free.fr> <4D7689CC.7060409@gmail.com> <4D76A5FF.2020704@uclouvain.be> <4D76C461.30506@gmail.com> <C3AC5E50-1E3F-4381-A0A4-B5023EBA529B@free.fr> <AANLkTi=Yej0=a1q7GejBGBCjXJQrLA90J9+xpcimTuXr@mail.gmail.com> <D7244E10-B305-45F3-9395-1C8C701D7A08@free.fr> <733F86F7-54F7-4544-B139-5F534F143DA6@apnic.net>
To: Geoff Huston <gih@apnic.net>
X-Mailer: Apple Mail (2.1082)
Cc: "S.P.Zeidler" <spz@serpens.de>, shim6-wg <shim6@ietf.org>, Scott Brim <scott.brim@gmail.com>, Ralph Droms <rdroms.ietf@gmail.com>
Subject: Re: [shim6] Exit selection
X-BeenThere: shim6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SHIM6 Working Group Mailing List <shim6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/shim6>, <mailto:shim6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/shim6>
List-Post: <mailto:shim6@ietf.org>
List-Help: <mailto:shim6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/shim6>, <mailto:shim6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Mar 2011 09:31:38 -0000

Le 13 mars 2011 à 22:14, Geoff Huston a écrit :

> On 13/03/2011, at 3:32 AM, Rémi Després wrote:
> 
>> 
>> Le 11 mars 2011 à 20:13, Scott W Brim a écrit :
>> 
>>> Shim6 itself cannot select an exit.  In all but trivial cases the network has the intelligence and must be involved (e.g. the exit points).  Given that one has to involve the network, then an exit selection mechanism is not just for Shim6 but for anything that can take advantage of multiple src+dst pairs, and it should not be Shim6-specific.  
>> 
>>> Therefore whatever needs doing, I recommend that it not be done in Shim6 but somewhere more general -- IntArea WG looks like a good place.
>> 
>> +1
>> 
> 
> wg co-chair hat OFF
> 
> I appreciate that in the context of the IETF saying "we should not do this" is invariably like standing in front of a bulldozer, and like the bulldozer, it rarely has any effect - but nevertheless I want to share with you a personal opinion that we should not do this! :-)


> I have two problems with this issue of "exit selection". 
> 
> Firstly, I recall the demise of the site-local scoped address in IPv6. The compelling argument for me was one of inability of self-awareness of context. i.e. it was never clear where the edge of a site actually lay. So let me replay the same problem statement here - what is an "exit" and how does a packet know when it has gone through it?

The problem that needs a solution (be it called "exit selection" or otherwise) is that of a domain where:
- several global PA prefixes are assigned to several independent border nodes
- routing is done across several links in an address family other than global IPv6 (e.g. with ULA's to avoid renumbering in case of a change in the set of PA prefixes)
- some hosts need e2e address transparency (e.g. for SHIM6)

> And how does a router "know" its the exit router and not an interior router? In the context of nested sites (e.g. workgroup, department, faculty) whats _the_ exit?

Let "border node" replace "exit router" as name of a node that is assigned a PA on upstream network and that also deals with the local address family.  
Now:
- e2e transparency can be preserved by encapsulating of e2e packets in locally routable packets.
- in addition to its local address, a SHIM6 host must know its (multiple) global addresses 
- if it also knows, for each PA appearing at the head of its global addresses, the local address of the border node to be used when transmitting with this PA in its source addresses, it can address encapsulating packets to the right border node using this address.

This is the approach I tried to introduce with SAM for multihoming (draft-despres-softwire-sam-01 sec 3.3), but, as SAM was presented as a generic tool, it was found to have too large a scope. 
Its applications have then progressed under different names:
- 4rd for stateless IPv4 across IPv6
- 6a44 for native IPv6 across NAT44-CPE's

Its application to global IPv6 across ULA's didn't receive a name yet because it didn't catch much attention so far. 
Let me propose "Geetalad" for Generic E2E Transparency Across Local Addressing Domains.

What about a bar bof in Prague?

 
> Secondly, its not just the problem of scope of a site here. Its also trying to clearly understand the nature of the problem and place that into juxtaposition with the various proposed "solutions." From memory the various exit selection solutions proposed in the context of shim6 were all various forms of source-address based forwarding, and for me its getting the cart well and truly before the horse.

> Hop-by-hop stateless destination-based forwarding is an incredibly powerful architectural concept in packet networks, and any other forwarding mechanism tends to invoke copious quantities of complexity and state, and should only be contemplated as a last resort of the desperate rather than the first line solution.

Full agreement that routing within the domain has to remain as is, hop-by-hop stateless (this is the case with SAM/Geetalad). 


> So why was exit selection an issue in shim6? Surely if routing is working, and shim6 does not assume broken routing, if a route to a destination is offered, then its a valid route. So why select exits that are not being offered by routing as being on the best path?

> From my memory I believe it was because some folk  thought that a) unicast reverse route filtering would be prevalent in IPv6 and that b) clients could not negotiate filters with their provider.  

> But is a) true?

I am not sure about what is actually done by various providers, but the fact is that ingress filtering is necessary to avoid source address spoofing.
It is therefore an elementary security tool.


> and is b) really true?

Even if possible, negotiating filters would be an operational burden, both for providers and for customers.
If the border node that has been assigned a PA is always traversed by packets leaving the domain with this PA in source addresses, there is no need for it.


> Frankly I'm pretty sceptical that this is the case and it concerns me that this is a case of over solving.

A solution that combines multihoming, local addressing independence, and shim6, is IMHO worth having, especially if it is stateless and straightforward.


> my 2c anyway

Thanks for your 2c.
I hope you will be interested in mine.

Regards,
RD