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

"Eric Vyncke (evyncke)" <> Wed, 07 August 2013 13:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 60A3121E811A for <>; Wed, 7 Aug 2013 06:07:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.448
X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id N-cXzoEwhuOo for <>; Wed, 7 Aug 2013 06:07:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 133E221E80FE for <>; Wed, 7 Aug 2013 06:07:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=12139; q=dns/txt; s=iport; t=1375880868; x=1377090468; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=95FC5rU8R4X7q57e0M3LqPL3GaukSS+05LVF7FiJVtU=; b=Ty4niXdSjimuQ7BjgIeHwBsAjvDqTb0tQhpSbdFfDMee7sR3+Lb3PEIc Yj4Z4LdPEExaM6Agp++qOZR3BJgmP0evt1TqMB8IFS5x5lyuZSbvdF3A+ ChjHPnX50vsyQ880viEwUlnym7smc0jVBnJ0eEd6K1I1pXVvF44+VxOtM w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos; i="4.89,833,1367971200"; d="scan'208,217"; a="244343514"
Received: from ([]) by with ESMTP; 07 Aug 2013 13:07:47 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id r77D7luw023723 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Aug 2013 13:07:47 GMT
Received: from ([]) by ([]) with mapi id 14.02.0318.004; Wed, 7 Aug 2013 08:07:46 -0500
From: "Eric Vyncke (evyncke)" <>
To: Lorenzo Colitti <>, "Fred Baker (fred)" <>
Thread-Topic: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC
Thread-Index: AQHOkTyDevJwNWLtzkuaof7OxddtY5mGm1kAgACKQoCAAF43gIAAFCCAgAArgQCAAfZ/gA==
Date: Wed, 7 Aug 2013 13:07:46 +0000
Message-ID: <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_97EB7536A2B2C549846804BBF3FD47E113128FA2xmbalnx02ciscoc_"
MIME-Version: 1.0
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: Wed, 07 Aug 2013 13:07:57 -0000

In short, the debate is not so much about ULA per se (we all know that there are obvious cases - even if rare - where ULA is the obvious choice) but about NPTv6 ;-O What a surprise...

I dislike NAT (especially the n:1 stateful one) even more when it is assumed to add security (cough cough).

But, during my day job I talk to enterprise customers (from small SMB with 3 people - friends and acquaintance - to 1000 people) and to be honest ULA (and I am ashamed to add NPT6 to the mix) is really what they want and I can understand why:

-       Having the internal network up when DHCP-PD is failing because WAN link is down (at least they keep ULA and loose only their GUA), this should be mentioned in our I-D

-       Having a simple and cheap way to do multi-homing, search about multi-homing, load-balancing, ... for SMB and those boxes uses RFC 1918 inside + NAT towards two ISP or two links (xDSL & 4G)... Not all SMB will get a PI space and will run BGP.

In short, I am probably the only co-author, that do not want to hide the topic under the carpet of another I-D. We could mention the above points (and others) without taking decisions but referring to the ULA use case I-D. But, we should mention that there are use case where ULA _APPEARS_ as appealing.

-éric (and YES I dislike NAPT for breaking apps, and making security worse)

From: [] On Behalf Of Lorenzo Colitti
Sent: mardi 6 août 2013 04:03
To: Fred Baker (fred)
Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC

On Tue, Aug 6, 2013 at 8:27 AM, Fred Baker (fred) <<>> wrote:
> NAT creates problems for applications not only in the stateful case, but in the stateless case as well, because with NAT the client must be prepared for a situation where it does not know its own address. This complicates peer-to-peer networking applications such as video chat.
I'm not going to argue one way or the other. The substance of my comment related to an address that was not intended to be globally reachable. our thought there?

But if it's not indended to be globally reachable... then why is it behind a NPTv6 box? I'd argue is that it *does* need to be globally reachable, but "only for certain traffic". For example, "TCP/443 replies from the Windows Update server".

The point is that when people say, "X will never do Y" sometimes it turns out that "never" just means "in the next six months", and what ends up happening is that they need to deal with additional complexity once Y becomes a requirement.