[ppml] PI and potential aggregation

[Houle, Joseph D (Joe), CMO]

Folks:
   A very minor change to this could make it more acceptable to the
"maintain aggregation" crowd.  
   It is not that PI is bad, it is allocations from ARIN that are down
at the "site-size" that is bad.   I am not convinced the PI causes
routing table explosion, it is advertising of site-sized blocks that
causes significant routing table growth.
   The "distinctly identified prefix" is interesting, but no matter
where the addresses come from there will be an expectation on the part
of the receiver of the addresses that address blocks assigned by ARIN
will be routable on the Internet.  As long as IP addresses are more on
the "locator" side of the ID/locator spectrum, they WILL have impact on
the routing table.   
   Now to the minor change... Allocate out the whole /44, as opposed to
a /48 out of a reserved /44.  The advantages are:
- ARIN stays out of the business of allocating "site-sized" addresses
for IPv6.
- This relieves qualifying organizations from developing justification
for "the remainder of their /44".
- ARIN doesn't need to deal with "return to the trough" process.
- This results in no higher burn rate of IPv6 addresses, if reserve
really means reserve.
- We maintain 4 bits worth of potential aggregation we would have lost.
- This gives us an opportunity to keep site-sized advertisements out of
the IPv6 routing table.
- this should increase the probability that these /44 blocks will
continue to be advertised and routable in the steady state IPv6
Internet.

   The only disadvantage I can see is that in a decade or two, if/when
IPv6 addresses become scarce we will not have these sets of two or three
/48s to harvest when the reservations are removed.  (BTW, is there a
process to determine if/when reservations should be removed?) That
almost sounds like a blessing, not a disadvantage (Can we really picture
in 2020 going back and harvest /48s worth of fragmented IPv6 space?).



Joe Houle

 
-----Original Message-----
From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of
Member Services
Sent: Friday, April 14, 2006 4:19 PM
To: ppml at arin.net
Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6
Assignments for End Sites - Last Call

The ARIN Advisory Council (AC), acting under the provisions of the ARIN 
Internet Resource Policy Evaluation Process (IRPEP), has reviewed Policy

Proposal 2005-1: Provider-independent IPv6 Assignments for End Sites and

has determined that there is community consensus in favor of the 
proposal, as edited below, to move it to last call. The AC added the 
final sentence to section 6.5.8.2. as shown below. The AC made this 
determination at their meeting at the conclusion of the ARIN Public 
Policy meeting on April 11, 2006. The results of the AC meeting were 
reported by the Chair of the AC at the member meeting. This report can 
be found at
http://www.arin.net/meetings/minutes/ARIN_XVII/mem.html

The policy proposal text is provided below and is also available at 
http://www.arin.net/policy/proposals/2005_1.html

Comments are encouraged. All comments should be provided to 
ppml at arin.net. This last call will expire at 12:00 Noon, Eastern Time, 
April 28, 2006.

The ARIN Internet Resource Policy Evaluation Process can be found at 
http://www.arin.net/policy/irpep.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)

###*###

Policy Proposal 2005-1: Provider-independent IPv6 Assignments for End
Sites

Policy statement:

Add new subsection in section 6.5 of the NRPM:

6.5.8. Direct assignments to end sites

6.5.8.1. To qualify for a direct assignment, an organization must:

a) not be an IPv6 LIR; and
b) Qualify for an IPv4 assignment or allocation from ARIN under the IPv4

policy currently in effect.

6.5.8.2. Direct assignment size to end sites

Organizations that meet the direct end site assignment criteria are 
eligible to receive a direct assignment. The minimum size of the 
assignment is /48.
Organizations requesting a larger assignment must provide documentation 
justifying the need for additional subnets.

These assignments shall be made from a distinctly identified prefix and 
shall be made with a reservation for growth of at least a /44.

6.5.8.3. Subsequent Assignment Size

Additional assignments may be made when the need for additional subnets 
is justified. When possible assignments will be made from an adjacent 
address block.

Policy Rationale

In IPv4 policy there are three main types of organizations that 
addresses are delegated to.

o ISP's receive allocations directly from ARIN or from other ISP's
o End Users receive assignments from ISP's
o Large and/or multihomed End Users receive assignments directly from
ARIN.

The third category is currently missing from IPv6 policy and this is 
believed to be severely hindering deployment by those organizations. In 
IPv6 policy-speak:

o LIR's receive allocations directly from ARIN
o End Sites receive assignments from LIR's

This policy proposes:

o Large and/or multihomed End Sites receive assignments directly from
ARIN.

This policy applies to organizations with networks that are large and/or

multihomed. Like their IPv4 counterparts they do not make assignments to

external organizations. They instead assign space internally to their 
own facilities. Similarly to IPv4 These internal assignments are not 
submitted to ARIN via swip/rwhois.

For transition purposes an organization that qualifies for IPv4 space 
today is considered eligible, regardless of whether they were considered

an ISP or End User under IPv4 policy. It is expected that the IPv6 only 
(non transition) requirements will be developed as experience is gained.

It is recommended that these assignments be made from a separate address

block set aside for this purpose and that at least a /44 be reserved 
around each assignment for possible expansion. One bit should be 
reserved around assignments /44 and larger.

Timetable for implementation: immediately
_______________________________________________
PPML mailing list
PPML at arin.net
http://lists.arin.net/mailman/listinfo/ppml