IETF Logo Mail Archive

RE: there _is_ IPv6 NAT - just look for it

"Manfredi, Albert E" <albert.e.manfredi@boeing.com> Mon, 17 March 2014 17:31 UTC

Return-Path: <albert.e.manfredi@boeing.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B6551A03F6 for <ipv6@ietfa.amsl.com>; Mon, 17 Mar 2014 10:31:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.747
X-Spam-Level:
X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] 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 s_zNtdmX91sB for <ipv6@ietfa.amsl.com>; Mon, 17 Mar 2014 10:31:27 -0700 (PDT)
Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id BE6E11A02AD for <ipv6@ietf.org>; Mon, 17 Mar 2014 10:31:27 -0700 (PDT)
Received: from blv-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id s2HHVIBr027353 for <ipv6@ietf.org>; Mon, 17 Mar 2014 10:31:19 -0700
Received: from XCH-PHX-408.sw.nos.boeing.com (xch-phx-408.sw.nos.boeing.com [137.136.239.50]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s2HHVIKo027350 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 17 Mar 2014 10:31:18 -0700
Received: from XCH-PHX-503.sw.nos.boeing.com ([169.254.6.193]) by XCH-PHX-408.sw.nos.boeing.com ([169.254.1.235]) with mapi id 14.03.0174.001; Mon, 17 Mar 2014 10:31:17 -0700
From: "Manfredi, Albert E" <albert.e.manfredi@boeing.com>
To: Lorenzo Colitti <lorenzo@google.com>
Subject: RE: there _is_ IPv6 NAT - just look for it
Thread-Topic: there _is_ IPv6 NAT - just look for it
Thread-Index: AQHPQYSbpcMHTQSo3EmbggTGSu6WtprlgRjg
Date: Mon, 17 Mar 2014 17:31:17 +0000
Message-ID: <021E64FECA7E5A4699562F4E66716481189E4C3D@XCH-PHX-503.sw.nos.boeing.com>
References: <E2C06D73-99FF-42B5-A3BE-337C307BCB0E@gmail.com> <CAKD1Yr0fjSWfPDkvc9Z53xBKxMGzYcVGzH3tLUGbjCKmgR_Duw@mail.gmail.com> <532374CD.3040100@gmail.com> <532401CB.8000003@gmail.com> <5324A1FF.3010109@gmail.com> <53255C09.7060900@gmail.com> <021E64FECA7E5A4699562F4E66716481189E49E8@XCH-PHX-503.sw.nos.boeing.com> <CAKD1Yr3sA4_4y18KBmBGOmY=PLOn1W4_F-3cgKyAfp4BQMUa=Q@mail.gmail.com>
In-Reply-To: <CAKD1Yr3sA4_4y18KBmBGOmY=PLOn1W4_F-3cgKyAfp4BQMUa=Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [137.136.248.6]
Content-Type: multipart/alternative; boundary="_000_021E64FECA7E5A4699562F4E66716481189E4C3DXCHPHX503swnosb_"
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/lO5DgAizWhMlgOOF4otJX8QVDpw
Cc: "ipv6@ietf.org" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Mar 2014 17:31:30 -0000

Residential ISPs who are stingy with their prefix, mobile hotspots, and any of a host of new applications, such as in-vehicle communications and IoT in general. Situations in which it is hard to predict what the subnet architecture will look like this early on. Mandating 64-bit IIDs seems like a sure way to either have to request more prefixes more frequently, or what the heck, using a NAT makes this simpler.

If every household and every IoT platform (e.g. automobile) were given a /48, it seems unlikely (to me, as of today) that IIDs less than 64 bits would ever be needed. The problem is, it seems even more unlikely that every such platform is going to be given a /48. So if 64-bit IIDs are going to become mandatory, the only option for future growth is going to be the NAT.

Too much depends on how these IoT systems evolve. For example, are refrigerators, electrical breaker boxes, and home HVAC systems going to be requesting /56 prefixes? I’d say, each of these would definitely need prefixes </64. So individual households have to be given something like /48 right off the bat, not just /56. Is this likely? If we guess wrong today, with IIDs fixed at 64 bits, the only options are renumbering or NATs.

Bert


From: Lorenzo Colitti [mailto:lorenzo@google.com]
Sent: Sunday, March 16, 2014 10:00 PM
To: Manfredi, Albert E
Cc: Brian E Carpenter; ipv6@ietf.org
Subject: Re: there _is_ IPv6 NAT - just look for it

On Mon, Mar 17, 2014 at 6:52 AM, Manfredi, Albert E <albert.e.manfredi@boeing.com<mailto:albert.e.manfredi@boeing.com>> wrote:
The IETF needs to deal with reality, though. I see a 64-bit IID mandate, the existence of /64 prefix assignments to customers, and opposition to IPv6 NAT as being internally inconsistent. Something has to give. I'm starting to see that IPv6 NAT will become popular in short order.

In what scenario do you see this as being necessary?

  *   For residential ISPs, there's DHCPv6 PD (and all ISPs I'm aware of are handing out larger than /64, either by default, or if the customer CPE advertises in a DHCPv6 PD hint that it would like larger than /64).
  *   For pre-rel10 3GPP links with a fixed allocation size of /64, there's draft-ietf-v6ops-64share
Anything else?

v2.23.0 | Report a Bug | By Email