[ppml] Proposed Policy: IPv6 Direct assignments to end sites
marcelo bagnulo braun
marcelo at it.uc3m.es
Tue Aug 30 08:56:40 EDT 2005
El 29/08/2005, a las 16:17, Member Services escribió:
> 6.5.8. Direct assignments to end sites.
> 18.104.22.168. To qualify for a direct end site assignment, an
> organization must:
> a) not be an LIR;
> b) be an end site;
> c) be currently multi-homed using IPv6 to two or more
> separate LIR's. native connections or statically
> configured tunnels may be used to satisfy this
Having two tunnels configured with different tunnels providers through
a single dsl line would fulfill this requirement?
I guess this would allow any IPv6 fan to have their own PI prefix
fairly easily, so i would argue for stronger requirements than this...
At least to be really multihomed, i.e. two different ISPs providing
different physical connectivity to the end site, similar to IPv4, i
However, i would even argue to reserve this type of PI based
multihoming only "big" sites (the problem here would be to define what
a big site is i am afraid)
> d) The prefix(es) used by the end site to demonstrate
> multihoming must be visible in the ARIN whois
> databse or via rwhois as being assigned to the
> requesting organization.
> 22.214.171.124. Direct assignment size to end sites
> Organizations that meet the direct end site
> criteria are eligible to receive a direct assignment
> 126.96.36.199. Subsequent direct assignments to end sites
> Only one direct assignment may be made to an end site
> End sites that require more than 65536 subnets should
> request space from an LIR or consider becoming
> an LIR.
> 188.8.131.52. Migration from end site to LIR
> A direct end site assignment shall not
> disqualify an organization from becoming an LIR and
> ceasing to be an end site if it otherwise meets the
> requirements for an initial allocation.
> Organizations receiving an LIR allocation must
> renumber into that allocation and return any direct
> assignments within 1 year. Micro allocations made
> under section 6.10 are not subject to this
> An LIR allocation shall disqualify an organization
> receiving a direct end site assignment unless it
> agrees to return all LIR allocations within 1 year.
> Micro allocations made under section 6.10 are not
> subject to this requirement.
> The lack of provider independent direct assignments is a
> significant impediment to adoption of IPv6 by enterprises and
> large content sites. This policy proposal defines clear
> verifiable requirements for receiving a direct assignment.
> Current IPv6 multi-homing was chosen as the key requirement for
> the following reasons:
> a) it is reasonable to expect that those reqesting provider
> independence would be connecting to two or more providers.
> b) the requirement of demonstrating current multi-homing will
> promote active deployment of IPv6 by those seeking direct
> It is possible that future technology developments will render
> this policy unnecessary. At this time there are no viable
> alternatives for IPv6 provider independence, other than
> an LIR.
> It is likely that this will help conserve IPv6 address space
> as most organizations requiring provider independence could
> easily qualify for an LIR allocation under current policy.
> Allowing them to apply for the more appropriate /48 is
> responsible resource management.
> This policy can easily be adapted to increase requirements for
> direct assignments if future conditions warrant. For example,
> the multihoming demonstration requirement could be increased
> to three or four separate LIR's. Additional verification
> of active current multihoming could be used. Or, as native
> connectivity becomes widespread the option of tunnel based
> connections for justification could be removed.
> It is extremely unlikely that this will result in a "land rush"
> of direct assignments. The requirements in this policy require
> more effort than the current requirements for a /32.
> Alternatively, a large number of applications would be a
> good sign of sincere IPv6 deployment due to the requirement
> to be currently multihomed.
> Timetable for implementation: Immediately
> PPML mailing list
> PPML at arin.net
More information about the ARIN-PPML