Re: [shim6] Exit selection [New Version Notification - draft-mrw-nat66-08.txt]

Geoff Huston <> Sun, 13 March 2011 21:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 793413A6BAF for <>; Sun, 13 Mar 2011 14:13:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.185
X-Spam-Status: No, score=-101.185 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bhPALlsm9OMW for <>; Sun, 13 Mar 2011 14:13:00 -0700 (PDT)
Received: from ( [IPv6:2001:dc0:2001:11::199]) by (Postfix) with ESMTP id 0DFEA3A6BA8 for <>; Sun, 13 Mar 2011 14:12:59 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTP id 57CCDB66C9; Mon, 14 Mar 2011 07:14:19 +1000 (EST)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=iso-8859-1
From: Geoff Huston <>
In-Reply-To: <>
Date: Mon, 14 Mar 2011 08:14:14 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <20110228223003.13022.10464.idtracker@localhost> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
To: Scott Brim <>
X-Mailer: Apple Mail (2.1082)
Cc: shim6-wg <>, "S.P.Zeidler" <>, Ralph Droms <>
Subject: Re: [shim6] Exit selection [New Version Notification - draft-mrw-nat66-08.txt]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SHIM6 Working Group Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 13 Mar 2011 21:13:01 -0000

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? 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?

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. 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? and is b) really true? Frankly I'm pretty sceptical that this is the case and it concerns me that this is a case of over solving.

my 2c anyway