<br><font size=2 face="sans-serif">Given the number of possible interfaces
available in a /64 I think it makes good sense to talk about the use of
subnets smaller than 64 bits long. However I think an ARIN policy change
would have to be preceded by the appropriate RFC changes. Specifically
RFC 4291 sec. 2.5.1 where it is stated that </font>
<br><font size=2 face="sans-serif">"For all unicast addresses, except
those that start with the binary value 000, Interface IDs are required
to be 64 bits long and to be constructed in Modified EUI-64 format."</font>
<br>
<br><font size=2 face="sans-serif">If there is an RFC that obsoletes 4291,
or if I am just misinterpreting it please provide the number or help me
understand the flaw in my interpretation.</font>
<br>
<br><font size=2 face="sans-serif">Anthony A. Crumb<br>
<br>
</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>Member Services <info@arin.net></b>
</font>
<br><font size=1 face="sans-serif">Sent by: ppml-bounces@arin.net</font>
<p><font size=1 face="sans-serif">10/22/2007 10:23 AM</font>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td><font size=1 face="sans-serif">ppml@arin.net</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">[ppml] Policy Proposal: IPv6 Assignment
Size Reduction</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<p><font size=1 face="sans-serif">Caterpillar: Confidential Green
Retain Until: 11/21/2007
</font>
<p>
<br>
<br>
<br><tt><font size=2>ARIN received the following policy proposal. In accordance
with the ARIN<br>
Internet Resource Policy Evaluation Process, the proposal is being<br>
posted to the ARIN Public Policy Mailing List (PPML) and being placed on<br>
ARIN's website.<br>
<br>
The ARIN Advisory Council (AC) will review this proposal at their next<br>
regularly scheduled meeting. The AC may decide to:<br>
<br>
1. Accept the proposal as a formal policy proposal as written.
If the<br>
AC accepts the proposal, it will be posted as a formal policy proposal<br>
to PPML and it will be presented at a Public Policy Meeting.<br>
<br>
2. Postpone their decision regarding the proposal until the
next<br>
regularly scheduled AC meeting in order to work with the author. The AC<br>
will work with the author to clarify, combine or divide the proposal. At<br>
their following meeting the AC will accept or not accept the proposal.<br>
<br>
3. Not accept the proposal. If the AC does not accept the
proposal,<br>
the AC will explain their decision. If a proposal is not accepted, then<br>
the author may elect to use the petition process to advance their<br>
proposal. If the author elects not to petition or the petition fails,<br>
then the proposal will be closed.<br>
<br>
The AC will assign shepherds in the near future. ARIN will provide the<br>
names of the shepherds to the community via the PPML.<br>
<br>
In the meantime, the AC invites everyone to comment on this proposal on<br>
the PPML, particularly their support or non-support and the reasoning<br>
behind their opinion. Such participation contributes to a thorough<br>
vetting and provides important guidance to the AC in their deliberations.<br>
<br>
The ARIN Internet Resource Policy Evaluation Process can be found at:<br>
http://www.arin.net/policy/irpep.html<br>
<br>
Mailing list subscription information can be found at:<br>
http://www.arin.net/mailing_lists/<br>
<br>
Regards,<br>
<br>
Member Services<br>
American Registry for Internet Numbers (ARIN)<br>
<br>
<br>
## * ##<br>
<br>
<br>
Policy Proposal Name: IPv6 Assignment Size Reduction<br>
<br>
Author: Brian Dickson<br>
<br>
Proposal Version: 1<br>
<br>
Submission Date: Oct 18, 2007<br>
<br>
Proposal type: modify<br>
<br>
Policy term: permanent<br>
<br>
Policy statement:<br>
<br>
6.5.4.1. Assignment address space size<br>
<br>
End-users are assigned an end site assignment from their LIR or ISP. The<br>
exact size of the assignment is a local decision for the LIR or ISP to<br>
make, using a minimum value of a /120 (when only one subnet is<br>
anticipated for the end site) up to the normal maximum of /48, except in<br>
cases of extra large end sites where a larger assignment can be justified.<br>
<br>
The following guidelines may be useful (but they are only guidelines):<br>
<br>
* /120 for a very small customer with one subnet, using
static<br>
assignments or DHCPv6<br>
* /116 for a small customer with a few subnets, using static<br>
assignments or DHCPv6<br>
* /112 for a medium size customer with a significant total
number<br>
of hosts and/or subnets, using static assignments and/or DHCPv6<br>
* /96 for large customers<br>
* /80 for very large customers, or for customers using a
proposed<br>
modified version of V6-autoconf (which uses EUI-48 instead of EUI-64)<br>
* /72 for customers with several subnets using modified
V6-autoconf<br>
(which uses EUI-48 instead of EUI-64)<br>
* /64 when it is known that one and only one subnet is needed,
for<br>
a customer that absolutely requires either traditional IPv6<br>
autoconfiguration, or IPv6 host Interface Identifier cryptographic<br>
generation<br>
* /60 for sites where a mix of IPv6-autoconfiguration and
other<br>
address assignment techiques are required<br>
* /56 for very large sites<br>
* /52 for very, very large sites<br>
* /48 for extremely large sites<br>
<br>
For end sites to whom reverse DNS will be delegated, the LIR/ISP should<br>
consider making an assignment on a nibble (4-bit) boundary to simplify<br>
reverse lookup delegation.<br>
<br>
Rationale:<br>
<br>
The intent is to provide more current guidance, to both ARIN members,<br>
and to ARIN staff, based on available IPv6 technology, and for the<br>
encouragement of efficient assignment of IPv6 address space.<br>
<br>
IPv6 supports numerous methods for address assignments to end nodes.<br>
Those include autoconfiguration, static assignment, and DHCPv6.<br>
Of those, only autoconfiguration requires use of /64 as the prefix size.<br>
<br>
Efficient use of IPv6 space should discourage widespread use of /64's,<br>
or for use of autoconfiguration as the sole justification for<br>
allocations of large address space.<br>
<br>
In particular, the effective lifetime of PA assignments to ISPs/LIRs, is<br>
largely a factor of internal aggregation, and the size of end assignments.<br>
<br>
Rather than meeting ISP needs by assigning very large IPv6 PA blocks, it<br>
would be wiser to encourage assignments that to not significantly use up<br>
available PA space for the ISP, even for very large customers.<br>
<br>
The overall intent is to minimize the need for any PA recipient, to<br>
return to ARIN for subsequent assignments, thus reducing the need for<br>
additional globally routable prefixes using up slots in routers in the<br>
DFZ - something that affects the long-term ability for all ISPs to<br>
continue to scale in a cost-effective manner.<br>
<br>
Timetable for implementation: Immediate<br>
<br>
<br>
<br>
_______________________________________________<br>
PPML<br>
You are receiving this message because you are subscribed to the ARIN Public
Policy<br>
Mailing List (PPML@arin.net).<br>
Unsubscribe or manage your mailing list subscription at:<br>
http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member
Services<br>
Help Desk at info@arin.net if you experience any issues.<br>
</font></tt>
<br>