Re: [nvo3] draft-ietf-nvo3-encap-00 should add considerations of traversing NAPT

Dan Wing <dwing@vmware.com> Thu, 13 July 2017 20:53 UTC

Return-Path: <dwing@vmware.com>
X-Original-To: nvo3@ietfa.amsl.com
Delivered-To: nvo3@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9754F13145A; Thu, 13 Jul 2017 13:53:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.701
X-Spam-Level:
X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=onevmw.onmicrosoft.com
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 z-OnWGxDSQ3z; Thu, 13 Jul 2017 13:53:15 -0700 (PDT)
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0077.outbound.protection.outlook.com [104.47.37.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E230129B19; Thu, 13 Jul 2017 13:53:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onevmw.onmicrosoft.com; s=selector1-vmware-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=g2NnqSJEeObFWAcc1evMR3mcndzqWUGL0Xdtq42KHdk=; b=DO28n+5ev4LQWbABOLeg4c03HIuWgQT0jvccll0WFLYaEZkBGiqlt5zbpZi857jWkE6rMqSMIurVKfIi+d3/ZwTNOM5GBPPZS660jrjBtyJB+1enVCktrp12YnJPRzKhE4/GnT5KSzXI+BBzr8Tg9/eLZOPGnptKcAjaxANpFgA=
Received: from CO2PR05MB2648.namprd05.prod.outlook.com (10.166.95.12) by CO2PR05MB2648.namprd05.prod.outlook.com (10.166.95.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.4; Thu, 13 Jul 2017 20:53:13 +0000
Received: from CO2PR05MB2648.namprd05.prod.outlook.com ([10.166.95.12]) by CO2PR05MB2648.namprd05.prod.outlook.com ([10.166.95.12]) with mapi id 15.01.1261.007; Thu, 13 Jul 2017 20:53:13 +0000
From: Dan Wing <dwing@vmware.com>
To: Joe Touch <touch@isi.edu>
CC: Linda Dunbar <linda.dunbar@huawei.com>, "draft-ietf-nvo3-encap@ietf.org" <draft-ietf-nvo3-encap@ietf.org>, NVO3 <nvo3@ietf.org>
Thread-Topic: [nvo3] draft-ietf-nvo3-encap-00 should add considerations of traversing NAPT
Thread-Index: AdL7Q+/ZfEDwvo9TRzm5LoTlMhYAfAAH9f4AAB7fIYAADBpmAAAAtVmAAADUpAAAADtOAAAA0c8A
Date: Thu, 13 Jul 2017 20:53:13 +0000
Message-ID: <9D18C8E4-99CC-4880-8D39-0696C5516ED5@vmware.com>
References: <4A95BA014132FF49AE685FAB4B9F17F6593FAA91@SJCEML702-CHM.china.huawei.com> <F254185B-6142-479D-BBDA-983A1189580D@vmware.com> <07212cff-8dbd-8ae9-3ca7-35244007ad6b@isi.edu> <63F0786E-681F-45E5-9288-79C28978C9BB@vmware.com> <20426a5c-766b-323b-203c-113adf35c8ce@isi.edu> <08C1D3D7-F616-49B5-BED9-57AE7EC9E3BE@vmware.com> <3139e878-3aac-8eef-bfe9-1a57b08e27f3@isi.edu>
In-Reply-To: <3139e878-3aac-8eef-bfe9-1a57b08e27f3@isi.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: isi.edu; dkim=none (message not signed) header.d=none;isi.edu; dmarc=none action=none header.from=vmware.com;
x-originating-ip: [208.91.2.2]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CO2PR05MB2648; 20:P9NNC4paqWtenu4R+S533leAsUm2Gp63cIT2RC0i4PKSrkjwPNZuPdxujTC3yBjp3f28G85F1k+EU6LDypPJ81zTNi/AuC5KiL265z/r66bm9SLiNguOofwsJpOrePqMkSmwFBxKtalwe30hXY7flzfpOY4JVg6HImLmY4jRNbs=
x-ms-office365-filtering-correlation-id: 82fb7d19-2556-4d47-bf54-08d4ca312da4
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CO2PR05MB2648;
x-ms-traffictypediagnostic: CO2PR05MB2648:
x-exchange-antispam-report-test: UriScan:(236129657087228)(148574349560750)(247924648384137);
x-microsoft-antispam-prvs: <CO2PR05MB264894F305810B40853507DEDCAC0@CO2PR05MB2648.namprd05.prod.outlook.com>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(2017060910075)(5005006)(8121501046)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6041248)(20161123558100)(20161123562025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CO2PR05MB2648; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CO2PR05MB2648;
x-forefront-prvs: 0367A50BB1
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39860400002)(39450400003)(39840400002)(39850400002)(39410400002)(39400400002)(377454003)(24454002)(53936002)(54906002)(93886004)(3280700002)(53546010)(3660700001)(6506006)(305945005)(6246003)(66066001)(86362001)(2900100001)(33656002)(2906002)(8936002)(110136004)(6512007)(38730400002)(102836003)(14454004)(2950100002)(6436002)(6916009)(6116002)(8676002)(50986999)(229853002)(3846002)(189998001)(36756003)(82746002)(7736002)(2171002)(4326008)(81166006)(5660300001)(478600001)(83716003)(6486002)(99286003)(77096006)(230783001)(25786009)(54356999)(76176999); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR05MB2648; H:CO2PR05MB2648.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-ID: <8157D14414393C4D81DF94A9037367EC@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: vmware.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jul 2017 20:53:13.2210 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB2648
Archived-At: <https://mailarchive.ietf.org/arch/msg/nvo3/QaCFACdDu3dnqLwEABWuawFQR4E>
Subject: Re: [nvo3] draft-ietf-nvo3-encap-00 should add considerations of traversing NAPT
X-BeenThere: nvo3@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" <nvo3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nvo3>, <mailto:nvo3-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nvo3/>
List-Post: <mailto:nvo3@ietf.org>
List-Help: <mailto:nvo3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nvo3>, <mailto:nvo3-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Jul 2017 20:53:19 -0000

> On Jul 13, 2017, at 1:29 PM, Joe Touch <touch@isi.edu> wrote:
> 
> 
> 
> On 7/13/2017 1:23 PM, Dan Wing wrote:
>>> On Jul 13, 2017, at 12:59 PM, Joe Touch <touch@isi.edu> wrote:
>>> 
>>> 
>>> 
>>> On 7/13/2017 12:39 PM, Dan Wing wrote:
>>>>> On Jul 13, 2017, at 6:52 AM, Joe Touch <touch@isi.edu> wrote:
>>>>> 
>>>>> FWIW, why not just add the entropy in the IPv6 flow ID rather than
>>>>> expecting it at the transport layer? Intermediate network devices should
>>>>> be relying only on the flow ID for that entropy anyway.
>>>> I don't know if IPv6 routers do ECMP using flow ID, and I don't know if physical NICs do RSS CPU load balancing based on IPv6 flow ID.
>>> I don't either, but *if* they (either one) does, they really should.
>>> 
>>> RFC 6438 discusses this issue and implies that flow ID isn't used
>>> because it's mostly zero, but I wouldn't be surprised if that were to
>>> change over time.
>>> 
>>>>> (and yes, that doesn't solve the problem for IPv4, but perhaps that's a
>>>>> good reason to encourage use of IPv6)
>>>> Yeah, for v4 we're stuck with using source UDP port to provide the ECMP and receiver benefit.
>>>> 
>>>> 
>>>> What of NAT64?
>>> Sure, that'd help, except we'd have to expect that an IPv4 router would
>>> know to jump into the IPv6 flow ID to do ECMP. That seems more of a
>>> stretch than the above, IMO.
>> Sorry, I wasn't clear.  I'm not worried of the NAT64 device itself, but rather the IPv4 network beyond the NAT64, should we use IPv6 flow-id as proposed.
>> 
>> If there are different ways of expressing ECMP and RSS (receiver side scaling) for IPv6 versus IPv4, my worry is what a NAT64 is supposed to do with the IPv6 packet (containing a flow-id) it translates to IPv4.  If traffic from IPv6 is using Flow-ID to provide ECMP and RSS and it hits a NAT64, is the NAT64 now needing to do NAPT64 (port translation) in an attempt to provide some Flow-ID-like functionality to the source UDP port number?  
> Well, you're translating for a more capable protocol to a less-capable
> one. Losing information is part of that game.
> 
> There's no way to do NAT64 translation without losing some of the info
> in the IPv6 header, period.
> 
> It MIGHT try to use the flow ID to guide source UDP port generation, but
> that assumes there's a UDP header to play with in addition to the IPv4
> header. That's not NAT64 anymore.

Yeah, well, then there is IPv6's UDP checksum versus IPv4's.  :-)

>> If so, that's new for NAT64, and can't work with stateless translation (IVI and related techniques).  If not, the IPv4 network suffers (no ECMP) and receiver suffers (because no RSS) because the sender was on IPv6 and the sender used flow-id.  In the other direction, IPv4 to IPv6, it seems easy for the NAT64 (stateless or stateful) to copy the UDP source port number into the IPv6 flow-id field, or do a cute 20-bit hash of the IPv4 5-tuple, or whatever.  If we spec'd that, NAT64 in the IPv4->IPv6 direction would align with RFC6438 and provide more ergs to IPv6 flow-id. 
>> 
>> However, I remain troubled by the IPv6->IPv4 direction with NAT64, should we use only Flow-ID on the IPv6 side.
> 
> I don't think we should try to lobotomize an elegant IPv6 solution "just
> in case" it hits NAT64.

IPv6 flow-id is only elegant if, on a v6 network, it provides us same ECMP and RSS benefits as UDP source port.  We haven't concluded we get (or don't get) ECMP and RSS yet.

> IMO, that's NAT64's problem to deal with (or not).

I could envision a knob that if the encapsulated traffic is traversing a NAT64, then it could use the in-elegant solution (UDP source port number) *and* the IPv6 flow-ID.  An SDN controller could (or should) know if the traffic will traverse a NAT64.  If the encapsulated traffic remains on v6 (and flow-ID gives us ECMP and gives us RSS), then it could avoid putting flow entropy into the UDP source port.

-d