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

Brian E Carpenter <> Sun, 13 March 2011 22:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9AD013A69CA for <>; Sun, 13 Mar 2011 15:31:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.15
X-Spam-Status: No, score=-103.15 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id C9d59GZqHT0z for <>; Sun, 13 Mar 2011 15:31:09 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 610AB3A6BCB for <>; Sun, 13 Mar 2011 15:31:09 -0700 (PDT)
Received: by ywi6 with SMTP id 6so2424260ywi.31 for <>; Sun, 13 Mar 2011 15:32:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=gJyHtZ9kF/pC1Oz9HUwUup41b44z7ep7dQAh/Ewwtmk=; b=GfP/XG/tYID0HLUbmhaTXDQ4dzd2z/rpAInsKMWXRTLJiGKVkUJv/hUSegPohaRZKF AHUv0gcVNVrBbT5MvZIDUsqqeQ1tGEuYS2vXpfDWo/pgcLkvNLkTIf1yYqJzJQR6gPcC pKUsFYMol5gboeduleISwdZqCasJgQZu+7Bhk=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=bWHKqJmYrKJ7plfppIdRlHOPHRBHYEck7ks9uSSsQsPyn4INS2/PFuCD+c8eyp3+tg QExkdymFBS4QLmSdPh33j91cHg8wUopdEymoqd810xUqVdzNQ+HNRUu+otcTLpzi18y9 TcMxmpXkEVYOtvyx/Zu/M/pniTQhGLSP86m1A=
Received: by with SMTP id m26mr2445171agj.140.1300055550560; Sun, 13 Mar 2011 15:32:30 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id u20sm5497338anu.34.2011. (version=SSLv3 cipher=OTHER); Sun, 13 Mar 2011 15:32:29 -0700 (PDT)
Message-ID: <>
Date: Mon, 14 Mar 2011 11:32:25 +1300
From: Brian E Carpenter <>
Organization: University of Auckland
User-Agent: Thunderbird (Windows/20070728)
MIME-Version: 1.0
To: Geoff Huston <>
References: <20110228223003.13022.10464.idtracker@localhost> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "S.P.Zeidler" <>, shim6-wg <>, Scott Brim <>, 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 22:31:11 -0000

On 2011-03-14 10:14, Geoff Huston wrote:
> 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! :-)

If by "we" you mean the shim6 WG, I'm inclined to agree,
beyond documenting that this problem needs to be solved
generically for IPv6. I don't believe shim6 is really a
special case: once you have prefixes from and exits to several
different ISPs, you have a potential problem.

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

The host and the departmental router cannot know the answer to
that question, I fear, without erecting some very complicated

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

I fully agree. That would be baroque, and despite having started
this conversation, I am not in favour of a host-based or even
departmental-router-based 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? 

Well, it seems from other responses that both are real problems,
but not specific to shim6. draft-v6ops-multihoming-without-nat66
talks about this, and at first sight, a valid approach for
the problems described in that draft would work just fine for
shim6 too. Maybe shim6 people should read that draft carefully.


> 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
> Geoff
> _______________________________________________ shim6 mailing
> list