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

Geoff Huston <gih@apnic.net> Sun, 13 March 2011 22:57 UTC

Return-Path: <gih@apnic.net>
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 1EF8D3A690A for <shim6@core3.amsl.com>; Sun, 13 Mar 2011 15:57:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.455
X-Spam-Level:
X-Spam-Status: No, score=-101.455 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100]
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 X6ykAqUpI60H for <shim6@core3.amsl.com>; Sun, 13 Mar 2011 15:57:03 -0700 (PDT)
Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 9A40F3A68AB for <shim6@ietf.org>; Sun, 13 Mar 2011 15:57:02 -0700 (PDT)
Received: from dhcp76.potaroo.net (eth143.act.adsl.internode.on.net [203.16.208.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id DECC1B6735; Mon, 14 Mar 2011 08:58:23 +1000 (EST)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: Geoff Huston <gih@apnic.net>
In-Reply-To: <E4E83F81-BEF1-41C0-97BF-08107901758F@steffann.nl>
Date: Mon, 14 Mar 2011 09:58:17 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <B96B5E8F-1752-421A-BB80-C5EE4A05DD8B@apnic.net>
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> <E4E83F81-BEF1-41C0-97BF-08107901758F@steffann.nl>
To: Sander Steffann <sander@steffann.nl>
X-Mailer: Apple Mail (2.1082)
Cc: shim6-wg <shim6@ietf.org>
Subject: Re: [shim6] Exit selection [New Version Notification - draft-mrw-nat66-08.txt]
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: Sun, 13 Mar 2011 22:57:04 -0000

On 14/03/2011, at 8:23 AM, Sander Steffann wrote:

> Hi Geoff,
> 
>> 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.
> 
> From my personal experience here in The Netherlands: a) yes, b) yes. At least for home users and small/medium sized businesses. A lot of them use cheap DSL based internet access, and they do uRPF for IPv4 and refuse to deploy an IPv6 service that can not do uRPF. And because the service is cheap, the ISP has no budget for b)...
> 

wg co-chair hat still off

It may be (is?) heretical in the context of this wg, but at the low end of the market that is highly cost and process constrained, as the subject line refers, NAT66 is an obvious approach that does not try and jump through the trapeze hoops of trying to do hop-by-hop forwarding based on source address in a general manner..

:-)

  Geoff