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

Geoff Huston <> Sun, 13 March 2011 23:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F01553A6A49 for <>; Sun, 13 Mar 2011 16:20:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.176
X-Spam-Status: No, score=-101.176 tagged_above=-999 required=5 tests=[AWL=-0.171, 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 n8WD+ZLccdSW for <>; Sun, 13 Mar 2011 16:20:52 -0700 (PDT)
Received: from ( [IPv6:2001:dc0:2001:11::199]) by (Postfix) with ESMTP id 689303A68AB for <>; Sun, 13 Mar 2011 16:20:50 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTP id 017C6B6735; Mon, 14 Mar 2011 09:22:09 +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 10:22:03 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <20110228223003.13022.10464.idtracker@localhost> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
To: Brian E Carpenter <>
X-Mailer: Apple Mail (2.1082)
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 23:20:53 -0000

On 14/03/2011, at 9:32 AM, Brian E Carpenter wrote:

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

As might be evident from my positing I'm of the view that this is
a case of "nothing to see here, move along" and therefore I personally 
disagree that this "problem" needs to be solved. (but I also appreciate
that in the IETF this never works and the IETF is often more
obsessed with the rathole than the larger landscape.  :-)

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

That's my understanding of the situation!

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