Re: [BEHAVE] [Fwd: Last Call: draft-azinger-additional-private-ipv4-space-issues (Additional Private IPv4 Space) to INFORMATIONAL RFC]

Joel Jaeggli <joelja@bogus.com> Tue, 03 August 2010 22:54 UTC

Return-Path: <joelja@bogus.com>
X-Original-To: behave@core3.amsl.com
Delivered-To: behave@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEF193A6B3D for <behave@core3.amsl.com>; Tue, 3 Aug 2010 15:54:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.869
X-Spam-Level:
X-Spam-Status: No, score=-2.869 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599]
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 7YUeDOqx+UMe for <behave@core3.amsl.com>; Tue, 3 Aug 2010 15:54:55 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 5CEE13A68D3 for <behave@ietf.org>; Tue, 3 Aug 2010 15:54:55 -0700 (PDT)
Received: from dhcp-183.nokia.net (dhcp-183.nokia.net [192.103.16.183] (may be forged)) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id o73MtNgj005993 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for <behave@ietf.org>; Tue, 3 Aug 2010 22:55:23 GMT (envelope-from joelja@bogus.com)
Message-ID: <4C589E5B.5020704@bogus.com>
Date: Tue, 03 Aug 2010 15:55:23 -0700
From: Joel Jaeggli <joelja@bogus.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.7) Gecko/20100713 Lightning/1.0b2 Thunderbird/3.1.1
MIME-Version: 1.0
To: behave@ietf.org
References: <4C4DAA99.5040500@piuha.net> <AANLkTi=65nxb_baJL=QDpFyJGuPFXNwZvnis9PZQNTRk@mail.gmail.com> <201007262131.o6QLVQmk001896@drugs.dv.isc.org> <28167C07-ED66-4B13-9A27-48B73EF4943C@magma.ca> <4C57524A.3040407@gmail.com> <39A95334-DF93-4A9A-A9D6-9D48177BB056@magma.ca> <4C588A7E.1040502@gmail.com>
In-Reply-To: <4C588A7E.1040502@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Tue, 03 Aug 2010 22:55:23 +0000 (UTC)
Subject: Re: [BEHAVE] [Fwd: Last Call: draft-azinger-additional-private-ipv4-space-issues (Additional Private IPv4 Space) to INFORMATIONAL RFC]
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Aug 2010 22:54:57 -0000

On 8/3/10 2:30 PM, Brian E Carpenter wrote:
> Philip,
> 
> This draft doesn't actually propose to allocate such space, so the fact that
> some ISPs want it is beside the point of the draft.
> 
> There are other drafts that do make such a proposal, but as far as I know they
> aren't in Last Call.

I'm sort of mystified by the intersection of

draft-azinger-additional-private-ipv4-space-issues

and

draft-weil-opsawg-provider-address-space-00

which sites it as an informative reference.

   Addressing solutions for dealing with the depletion of the IPv4
   public address space and the lack of available private addresses
   within large providers are presented in
   [I-D.azinger-additional-private-ipv4-space-issues] as well as
   [I-D.shirasaki-nat444-isp-shared-addr].  For larger Service Providers
   who require more than the 16 million Net-10 addresses, the preferred
   method for addressing the problems presented in both draft documents
   is to direct IANA to reserve a /8 from its unassigned IPv4 address
   pool.




> Regards
>    Brian
> 
> On 2010-08-03 22:08, Philip Matthews wrote:
>> Hmm... Perhaps I missing something, but I just re-read the draft and I didn't see that it was arguing against allocating additional space.   It pointed out some problems, but they didn't seem unsurmountable to me. The operators I talked with told me "We know there are problems, but we are willing to live with them, because we really need extra IPv4 space. We HAVE to get extra space from somewhere."
>> Some of the operators I talked with are those behind    http://tools.ietf.org/id/draft-weil-opsawg-provider-address-space-00.txt
>> - Philip
>>
>> On 2010-08-02, at 19:18 , Brian E Carpenter wrote:
>>
>>> Philip,
>>>
>>> I have no reason to doubt that many ISPs would like a little bit more
>>> private space. But how does that affect the arguments that any such
>>> space would create problems, which seems to be the point of this draft?
>>>
>>> Regards
>>>   Brian
>>>
>>> On 2010-08-03 02:32, Philip Matthews wrote:
>>>> From my discussions with a number of providers at the IETF meeting last week, they are all looking for a bit more private address space to provide them with a bit of breathing room while they transition to IPv6. Every provider that I talked to was working on IPv6 transition, but none of them could turn it on overnight. 
>>>> - Philip
>>>>
>>>> On 2010-07-26, at 17:31 , Mark Andrews wrote:
>>>>
>>>>> In message <AANLkTi=65nxb_baJL=QDpFyJGuPFXNwZvnis9PZQNTRk@mail.gmail.com>, Came
>>>>> ron Byrne writes:
>>>>>> d.  IPv6-only networks with NAT64 / DNS64.  This option best
>>>>>> encourages the use of IPv6 and really gets network and application
>>>>>> designers focused on the end-game, not wallowing in some middle-state
>>>>>> of CGN / LSN / and endless NAT444.
>>>>> Anything for big networks will require some form of address sharing
>>>>> between customers.  NAT64 / DS-LITE / NAT444.
>>>>>
>>>>> -- 
>>>>> Mark Andrews, ISC
>>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>>>>> PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org
>>>>> _______________________________________________
>>>>> Behave mailing list
>>>>> Behave@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/behave
>>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> Behave mailing list
>>>> Behave@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/behave
>>
>>
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave
>