Re: RFC 3484 Section 6 Rule 9
Joe Abley <jabley@ca.afilias.info> Wed, 04 June 2008 03:07 UTC
Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC03A3A6ADD; Tue, 3 Jun 2008 20:07:02 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA4E03A6ADD for <ietf@core3.amsl.com>; Tue, 3 Jun 2008 20:07:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 PkOO2GAaLkef for <ietf@core3.amsl.com>; Tue, 3 Jun 2008 20:06:59 -0700 (PDT)
Received: from monster.hopcount.ca (monster.hopcount.ca [199.212.90.4]) by core3.amsl.com (Postfix) with ESMTP id C18163A63CB for <ietf@ietf.org>; Tue, 3 Jun 2008 20:06:58 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=monster; d=ca.afilias.info; h=Received:Cc:Message-Id:From:To:In-Reply-To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:X-Mailer; b=SdV1G7QO+wHOcDdTvKzG27Wgkiv6b69AOakGsuL+m42lf4JgLvSHh/rNGYFEMKUEOhQ99uEkTa05J0as0sQ+xMbvblENOHybBPHS0Rr1GgrzmAcJ6VYV03rS6Nq/5O08;
Received: from [199.212.90.13] (helo=calamari.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from <jabley@ca.afilias.info>) id 1K3jON-000LiF-VW; Wed, 04 Jun 2008 03:10:29 +0000
Message-Id: <884C2127-D98B-472E-B245-D18CE61D4018@ca.afilias.info>
From: Joe Abley <jabley@ca.afilias.info>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
In-Reply-To: <4845B998.1010401@gmail.com>
Mime-Version: 1.0 (Apple Message framework v924)
Subject: Re: RFC 3484 Section 6 Rule 9
Date: Tue, 03 Jun 2008 23:06:45 -0400
References: <C46AB084.3A7B8%leo.vegoda@icann.org> <4845B998.1010401@gmail.com>
X-Mailer: Apple Mail (2.924)
Cc: marcelo bagnulo braun <marcelo@it.uc3m.es>, Mark Andrews <Mark_Andrews@isc.org>, "ietf@ietf.org" <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org
On 3 Jun 2008, at 17:37, Brian E Carpenter wrote: > I don't deny that some registries have started allocating PI prefixes > for large sites. ARIN is one such registry. http://www.arin.net/policy/nrpm.html#six58 All you need to do to qualify for a direct IPv6 assignment from ARIN is to not be an IPv6 LIR, and to qualify for any IPv4 assignment. The minimum assignment in such cases is a /48. http://www.arin.net/policy/nrpm.html#four3 All you need to do to qualify for a direct IPv4 assignment from ARIN is to demonstrate an intent to be multi-homed. The minimum assignment in such cases is a /22. End users need to demonstrate an immediate need for a /24, and a projected need for a /23 within a year. > That doesn't make PI the default model for small and > medium multi-homed IPv6 sites, which is where our scaling problem will > lie. Per above, if you're multi-homed and can justify a /22 of IPv4 space, you can get a /48 of IPv6 space as a direct assignment. You can qualify for the /22 if you plan to need a /23 within a year. I would say that a site that could number its entire operation in an IPv4 /23 could reasonably be called "small". Note that there is no requirement in the policy to use NAT or RFC1918 addresses. It seems to me that direct assignment could quite possibly become the default for small IPv6 sites in the ARIN region. IPv6 uptake to date has been so tiny that I don't think anybody can predict what behaviours will become prevalent if/when IPv6 takes off. Joe _______________________________________________ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
- Re: RFC 3484 Section 6 Rule 9 Mark Andrews
- Re: RFC 3484 Section 6 Rule 9 marcelo bagnulo braun
- Re: RFC 3484 Section 6 Rule 9 Mark Andrews
- RFC 3484 Section 6 Rule 9 Mark Andrews
- Re: RFC 3484 Section 6 Rule 9 Pekka Savola
- Re: RFC 3484 Section 6 Rule 9 Mark Andrews
- Re: RFC 3484 Section 6 Rule 9 marcelo bagnulo braun
- Re: RFC 3484 Section 6 Rule 9 SM
- Re: RFC 3484 Section 6 Rule 9 Brian E Carpenter
- Re: RFC 3484 Section 6 Rule 9 Tony Finch
- Re: RFC 3484 Section 6 Rule 9 Mark Andrews
- Re: RFC 3484 Section 6 Rule 9 Leo Vegoda
- Re: RFC 3484 Section 6 Rule 9 Thomas Narten
- Re: RFC 3484 Section 6 Rule 9 Simon Josefsson
- Re: RFC 3484 Section 6 Rule 9 Ralph Droms
- Re: RFC 3484 Section 6 Rule 9 Simon Josefsson
- Re: RFC 3484 Section 6 Rule 9 Tony Finch
- Re: RFC 3484 Section 6 Rule 9 Simon Josefsson
- Re: RFC 3484 Section 6 Rule 9 Arifumi Matsumoto
- Re: RFC 3484 Section 6 Rule 9 Michael StJohns
- Re: RFC 3484 Section 6 Rule 9 Tony Finch
- Re: RFC 3484 Section 6 Rule 9 Michael StJohns
- Re: RFC 3484 Section 6 Rule 9 Tony Finch
- Re: RFC 3484 Section 6 Rule 9 Brian E Carpenter
- Re: RFC 3484 Section 6 Rule 9 Joe Abley
- Re: RFC 3484 Section 6 Rule 9 Brian E Carpenter