Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC

Lorenzo Colitti <> Tue, 13 August 2013 04:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DF27221E80A7 for <>; Mon, 12 Aug 2013 21:07:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.622
X-Spam-Status: No, score=0.622 tagged_above=-999 required=5 tests=[FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DblpUnmQItT1 for <>; Mon, 12 Aug 2013 21:07:35 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c03::234]) by (Postfix) with ESMTP id 1CFFC21E809E for <>; Mon, 12 Aug 2013 21:07:34 -0700 (PDT)
Received: by with SMTP id aq17so9261333iec.25 for <>; Mon, 12 Aug 2013 21:07:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=7m3nqI/Hmxh9nATC+EjP/ssD8wxS3swxbfMU1mOrdkA=; b=ipR5zYfdtucICDkFDRsIVLwfeSLycHlZYiVhm9CO315FTWUO2QXEk/PTTJ/JWkNBkz nbrpQKVJjS3dSCpRPx7tD0keekuJ1qoFWeHWlnTPviea/YlBGFIbvnFLzQz2XsZ144kx C4zCz50b2CxEHt5wGjbSXqVYCiz3AeAR6kxRTtH2Th3p64f/kas8kwZHaXCigAH2Vu9T KrREGx14B5wsoi9a8WKzBh7K3/ZxVuiIWCPWv2eJ3BQ4uS547m+sr/oUGXp8/er1DDeR UW2uFDYf0+ngkF+dIMhJdVwqn7RBOiBqStgJUwBBESLMLcmDgBgL4JtUK33sCP/Ao8hh l+jg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=7m3nqI/Hmxh9nATC+EjP/ssD8wxS3swxbfMU1mOrdkA=; b=YvnYZybdMoNDl5gfCCgUM5vwZQHCdTHgzQjxyU9KLgOJU4CF6JoM7gNSqUGhYeJVp4 WV1cAg8VQFb9JAVCndInTZK4brXSOqiLqvnW0Yi6qTqH9qUpIdaZWKdLGRzijE5ybqN9 5H7exEDxXHTT8ratXoT/rCeeke0y44YUX2oZqNidrqCr9r9ugShyjg/K96dadFmlo4O1 2NvL88jSmFG8EYDCNEFTV+gpAtnhzrVfSJlULXZgE8udtFKMi1X2t55SN/Qv9r11mJ1s /6rWrpbt+3NFrcwiUcls3f200Tqzdztdq2x4ivhVKcGJag9FoTNvF9PPS+M0Yp2IF2Rk Nhcg==
X-Gm-Message-State: ALoCoQmgY6jvpBSwluVC4lFbrUWnpspmVNdqyot/CijB3ejkIr0WzB47OII17lH4tNdOeu4wPfU2fNBDdsnw3JDqLOHakcBGOTEDDQzLCo4EdA3bT7Cxe8F7Pu6Nb6us3eETNRApUcWMM19aiex7Xk+LR6z9RyLYwyUUtdhMdB9SDoSfX1o9r5ib6vpg3L5xOH9BCNAWfapU
X-Received: by with SMTP id 20mr1308107igi.56.1376366854621; Mon, 12 Aug 2013 21:07:34 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 12 Aug 2013 21:07:14 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <>
From: Lorenzo Colitti <>
Date: Tue, 13 Aug 2013 13:07:14 +0900
Message-ID: <>
To: "Arie Vayner (avayner)" <>
Content-Type: multipart/alternative; boundary=e89a8f64303473715504e3cc619a
Cc: "" <>
Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 13 Aug 2013 04:07:36 -0000

On Tue, Aug 13, 2013 at 2:34 AM, Arie Vayner (avayner) <>wrote;wrote:

>  Actually, you can use NPTv6 to protect against it… ****
> If I have an external pool per site, traffic egressing that site would get
> a source routed back only to that site… Am I missing something?
As I said, NPTv6 by itself doesn't protect against this problem.

It only protect against this problem if each egress point is only reachable
using one prefix, and all the prefixes are different. To people used to
deploying NAT44 networks, this will likely be the only deployment model
that comes to mind, and thus it will appear to them that NPTv6 does solve
this problem.

But in fact, NPTv6 was supposed to be deployed statelessly. The very first
words of RFC6296 are "This document describes a stateless [...] function
[...] preserving end-to-end reachability at the network layer.". In the
introduction, it then goes on to say it "this specification provides a
mechanism that has fewer architectural problems than merely implementing a
traditional stateful NAT". If you were to deploy it statelessly, you would
have this problem.

The interesting point here, really, is that when the IETF says "NPTv6"
people hear "NAT66", when in fact they are supposed to be different. Out of
curiosity: Fred, as the co-author of RFC 6296, were you anticipating that
people would do this? Or was the belief actually that people would
understand the difference?