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

"Arie Vayner (avayner)" <avayner@cisco.com> Fri, 09 August 2013 05:21 UTC

Return-Path: <avayner@cisco.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB37821F9E6A for <v6ops@ietfa.amsl.com>; Thu, 8 Aug 2013 22:21:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level:
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RvsFvNk9Hxc2 for <v6ops@ietfa.amsl.com>; Thu, 8 Aug 2013 22:21:18 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id ECC4D21F9E3C for <v6ops@ietf.org>; Thu, 8 Aug 2013 22:21:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19102; q=dns/txt; s=iport; t=1376025678; x=1377235278; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=CLbMOSS/qvG/+l9vWTjMFX+in/O+w9thwXptwA0qoow=; b=DyVTox9wNx8K91SinqURyxMwzlka2WGtvwQCF65Fy7Vd4ToB/IpohTdL RGJQeWAdirJBdp/3NFx/n+lMuBYKRczc/uNBiLhWvC2Jm+4klDAcyBfbX lSrcMciOKeEF7BYAU4Y6ai9YjazT5p+eoLHw36YbBxUR9q4LyMJBJ5Fmj w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmgFAM57BFKtJXG//2dsb2JhbABbgkJENVC+UIEZFnSCJAEBAQMBLUwFCwIBCBEEAQEBCh0HMhQDAQUIAgQBDQUIE4dvBrkGj2oxBgGDGnQDiHOgPYMYgio
X-IronPort-AV: E=Sophos; i="4.89,844,1367971200"; d="scan'208,217"; a="245355484"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-6.cisco.com with ESMTP; 09 Aug 2013 05:21:12 +0000
Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r795LCE7028777 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 Aug 2013 05:21:12 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.159]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Fri, 9 Aug 2013 00:21:11 -0500
From: "Arie Vayner (avayner)" <avayner@cisco.com>
To: "Eric Vyncke (evyncke)" <evyncke@cisco.com>, Lorenzo Colitti <lorenzo@google.com>, "Fred Baker (fred)" <fred@cisco.com>
Thread-Topic: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC
Thread-Index: AQHOkTyDDMSxdUYJukeaGavK35KXPJmGm1kAgACKQoCAAF43gIAAFCCAgAArgQCAAkwdAIACTLxQ
Date: Fri, 9 Aug 2013 05:21:10 +0000
Message-ID: <CA6D42D0F8A41948AEB3864480C554F104AE7A3F@xmb-rcd-x10.cisco.com>
References: <201308041800.r74I03pC023049@irp-view13.cisco.com> <3374_1375690984_51FF60E8_3374_427_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15C5041E1E5@PUEXCB1C.nanterre.francetelecom.fr> <8C48B86A895913448548E6D15DA7553B96E2C5@xmb-rcd-x09.cisco.com> <CAKD1Yr13GK_cuvkt2LpJ1qJo2NR8eUnY-xfwMF_zWfe0P1mm9g@mail.gmail.com> <8C48B86A895913448548E6D15DA7553B96EAE7@xmb-rcd-x09.cisco.com> <CAKD1Yr2_d=4uD1W4WcQ82rupjVJ4UmmQAQmtSY+aQgTXmscNUw@mail.gmail.com> <97EB7536A2B2C549846804BBF3FD47E113128FA2@xmb-aln-x02.cisco.com>
In-Reply-To: <97EB7536A2B2C549846804BBF3FD47E113128FA2@xmb-aln-x02.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.19.89.89]
Content-Type: multipart/alternative; boundary="_000_CA6D42D0F8A41948AEB3864480C554F104AE7A3Fxmbrcdx10ciscoc_"
MIME-Version: 1.0
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
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: Fri, 09 Aug 2013 05:21:24 -0000

Another loosely related point that I think could make sense in such a document would be the ways to accomplish multi-homing and how it is different than today's IPv4 implementations.

Many enterprises rely on NAT on the Internet edge as their multi-homing/traffic engineering mechanism with IPv4.

If we recommend against ULA+NPTv6 (or just NPTv6 for traffic engineering), then we need to highlight the symmetry requirement due to stateful security layers.
Traffic leaving from an Internet gateway site to the Internet has to come back through the same site, or the stateful firewalls would break the flow (well, has to hit the same stateful security layer)

Syncing upstream and downstream routing policies is not always an easy task (but could be relevant in some cases).
Linking the Internet gateway layer across sites (before hitting the stateful security layer) could be another solution.

Do you think a short discussion to raise awareness for this potential issue could be relevant in such a document?

Arie

From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Eric Vyncke (evyncke)
Sent: Wednesday, August 7, 2013 6:08 AM
To: Lorenzo Colitti; Fred Baker (fred)
Cc: v6ops@ietf.org
Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC

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: v6ops-bounces@ietf.org<mailto:v6ops-bounces@ietf.org> [mailto:v6ops-bounces@ietf.org] On Behalf Of Lorenzo Colitti
Sent: mardi 6 août 2013 04:03
To: Fred Baker (fred)
Cc: v6ops@ietf.org<mailto:v6ops@ietf.org>
Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC

On Tue, Aug 6, 2013 at 8:27 AM, Fred Baker (fred) <fred@cisco.com<mailto:fred@cisco.com>> 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.