Re: [OPSAWG] Request for feedback: draft-weil-opsawg-provider-address-space-02

Chris Donley <C.Donley@cablelabs.com> Thu, 28 October 2010 19:51 UTC

Return-Path: <C.Donley@cablelabs.com>
X-Original-To: opsawg@core3.amsl.com
Delivered-To: opsawg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B7AC3A6774 for <opsawg@core3.amsl.com>; Thu, 28 Oct 2010 12:51:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.463
X-Spam-Level:
X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id khV5JCA9XwDc for <opsawg@core3.amsl.com>; Thu, 28 Oct 2010 12:51:21 -0700 (PDT)
Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id C48373A69C9 for <opsawg@ietf.org>; Thu, 28 Oct 2010 12:51:21 -0700 (PDT)
Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o9SJrCcn012372; Thu, 28 Oct 2010 13:53:12 -0600
Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Thu, 28 Oct 2010 13:53:12 -0700 (MST)
X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com)
Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Thu, 28 Oct 2010 13:53:12 -0600
From: Chris Donley <C.Donley@cablelabs.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Date: Thu, 28 Oct 2010 13:53:10 -0600
Thread-Topic: [OPSAWG] Request for feedback: draft-weil-opsawg-provider-address-space-02
Thread-Index: Act2GT2hFd7fV9ZsRqCeI2GNlBINxQAmXmbg
Message-ID: <76AC5FEF83F1E64491446437EA81A61F7D20315A5A@srvxchg>
References: <76AC5FEF83F1E64491446437EA81A61F7D203158CE@srvxchg> <4CC891A3.2090802@gmail.com>
In-Reply-To: <4CC891A3.2090802@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Approved: ondar
Cc: "opsawg@ietf.org" <opsawg@ietf.org>, "Victor Kuarsingh (victor.kuarsingh@rci.rogers.com)" <victor.kuarsingh@rci.rogers.com>
Subject: Re: [OPSAWG] Request for feedback: draft-weil-opsawg-provider-address-space-02
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsawg>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Oct 2010 19:51:23 -0000

Brian,

I agree with you from a technical perspective that transitioning to IPv6 is the right long-term solution; NAT444 and other IPv4 multiplexing technologies cause problems, and are likely to provide a deteriorating user experience in the future. However, given that ISPs can't just switch to IPv6 - too many legacy devices in the home, CPE routers, network devices, and content providers either don't support IPv6 or don't fully support it, there needs to be a solution to extend IPv4 for at least a few years, and part of that solution will be NAT444, like it or not.  Another part of the solution to transition to IPv6 will be 6RD, allowing ISPs to deploy it before some infrastructure elements can be upgraded.  Agreed that both are sub-optimal, but both are needed.

Given that some ISPs will be deploying 6RD and/or NAT444, they will need an address block between the CPE router and the LSN/BR.  What is the appropriate addressing policy? As we see it, there are three options for providing that address space:
	1) Reserve a /8 from IANA (our proposal)
	2) Have ISPs individually request addresses from the RIRs.  By our count from just the ISPs we've spoken with, operators will need at least 60 million addresses (~3.75 /8s) to fill this need.  The total need is probably higher.  We believe that this is an inefficient use of public address space for addresses that don't need to be routed on the Internet. Allocating a single /8 for shared transition space will be more efficient.
	3) ISPs could 'squat' on a /8 allocated to another entity.  I think this is the worst of the three - problems with this approach have been documented in draft-azinger-additional-private-ipv4-space-issues, among other places. 

I agree with you that none of these options are great.  Of the three, we think (1) is the preferable policy, as it ties up a smaller allocation of otherwise public space. Do you have a different preference?  Is there a better option for providing a /8 or /9 to each large ISP that needs it for NAT444/6RD that we haven't considered?

Note: we don't think 240/4 space is viable, as too many home/enterprise routers don't support it, and it will not be operationally feasible to upgrade all the routers (particularly customer routers).

Chris

-----Original Message-----
From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] 
Sent: Wednesday, October 27, 2010 2:55 PM
To: Chris Donley
Cc: opsawg@ietf.org; Victor Kuarsingh (victor.kuarsingh@rci.rogers.com)
Subject: Re: [OPSAWG] Request for feedback: draft-weil-opsawg-provider-address-space-02

The arguments why this is a really bad idea have been made
often enough, so I won't repeat them here. I think that
the IETF should continue to not endorse the creation of yet
more ambiguous unroutable address space.

Instead, I'd like to see several other drafts moving on
as fast as possible, because we need to document as thoroughly
as possible why providers would come to deeply regret deploying
yet more ambiguous address space:

draft-donley-nat444-impacts
draft-kirkham-private-ip-sp-cores
draft-ietf-intarea-shared-addressing-issues

Regards
   Brian Carpenter

On 2010-10-27 11:37, Chris Donley wrote:
> Hello,
> 
> To support Service Provider deployments of NAT444 and 6RD, we are proposing that IANA reserve a /8 for shared transition space.  We believe that this will be a more efficient way of using the remaining unallocated IPv4 space. By sharing space for transition technologies, we believe that this will free up additional public addresses beyond a /8 that would otherwise be allocated to Service Providers for transition technologies.
> 
> We believe that we have incorporated your feedback on previous versions of our draft, and are interested in your feedback on our -02 version: http://datatracker.ietf.org/doc/draft-weil-opsawg-provider-address-space/. In particular, do you support this draft becoming a WG item?
> 
> Thanks,
> Chris
> 
> Chris Donley
> CCIE, CISSP, SCiPM
> Project Director - Network Protocols
> CableLabs(r)
> 858 Coal Creek Circle
> Louisville, CO 80027
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg