Re: [v6ops] Operational Consensus on deployment

Philip Homburg <pch-v6ops-3@u-1.phicoh.com> Wed, 06 August 2014 10:08 UTC

Return-Path: <pch-bBB316E3E@u-1.phicoh.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67ED51B2D02 for <v6ops@ietfa.amsl.com>; Wed, 6 Aug 2014 03:08:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.9
X-Spam-Level:
X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-eZChU-ws91 for <v6ops@ietfa.amsl.com>; Wed, 6 Aug 2014 03:07:58 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo6.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id E7EFC1B2CFE for <v6ops@ietf.org>; Wed, 6 Aug 2014 03:07:57 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1XEy8M-0000AXC; Wed, 6 Aug 2014 12:07:50 +0200
Message-Id: <m1XEy8M-0000AXC@stereo.hq.phicoh.net>
To: Tore Anderson <tore@fud.no>
From: Philip Homburg <pch-v6ops-3@u-1.phicoh.com>
Sender: pch-bBB316E3E@u-1.phicoh.com
References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <53E0C548.9050706@fud.no> <5C9FC57A-0DA5-4D36-84AE-CF1D6D17FB44@eircom.net> <53E1C587.4000506@fud.no>
In-reply-to: Your message of "Wed, 06 Aug 2014 08:04:55 +0200 ." <53E1C587.4000506@fud.no>
Date: Wed, 06 Aug 2014 12:07:45 +0200
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/5Be8JmaXT6Up0ho_eBsDr-tK7BI
Cc: IPv6 Ops WG <v6ops@ietf.org>
Subject: Re: [v6ops] Operational Consensus on deployment
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Aug 2014 10:08:00 -0000

In your letter dated Wed, 06 Aug 2014 08:04:55 +0200 you wrote:
>* Ross Chandler
>
>> What=92s your position on NAPT44 being put in front of an IP service =
>
>> address pool that used RFC1918 space? Not advocating for that but it
>> would inevitably be tried.
>
>I find this undesirable for several reasons. From the top of my head:
>
>1) The NAPT44 device needs to maintain per-flow state for each flow.
>This creates some new undesirable scaling properties, in particular
>limitations on concurrent flow count and and flow initiation rate which
>generally are reached long before the available interface bandwidth is
>exhausted. This in turn typically makes such boxes be the first thing to
>stop working under DDoS attacks, as the flow table gets filled up with
>junk flow entries, and/or that new flow entries cannot be added to the
>table fast enough.

As far as I can tell, your proposal maps every public IPv4 address to a
unique IPv6 address.

In that context, why not just use, for example, host routes to route IPv4
traffic to the right interface of an IPv4 host.

No need for any kind of NAT, translation or anything.

I.e. in the situaiton you describe there are enough addresses that there is no
need for NAT.