[arin-ppml] IPv4 Depletion as an ARIN policy concern

[Tony Hain]

joel jaeggli wrote:

> Tony Hain wrote:
> > Scott Leibrand wrote:
> >> So I take it you consider the existing ULA's "statistical
> uniqueness)
> >> to
> >> be sufficient?  One thing I've heard a small amount of support for
> is
> >> to
> >> have RIRs register unique addresses that are intended to be used for
> >> private addressing, and assign them out of a range dedicated for
> that
> >> purpose.  I'm not sure if that's necessary, myself, but I'm open to
> >> arguments from anyone who thinks so.
> >
> >
> > For many organizations the risks associated with 'statistical' are
> > unacceptable, either based on bad experiences with IPv4 mergers, or
> based on
> > interpretation of regulatory requirements to mitigate such risks.
> 
> it's no worse than what they do with ipv4 today, along many dimensions
> it's better.

Current IPv4 practice is insufficient for many, but all that is technically possible. There is no reason to artificially deny the technical capacity to do better than current practice.

> 
> > The
> > original ULA-C work was tabled due to lack of PI policy, so it looked
> like
> > an end-run around the RIR policy framework. Now that PI policy is in
> place
> > it is time to complete that part of the story. I have resurrected the
> effort
> > with the draft
> > http://www.ietf.org/internet-drafts/draft-hain-ipv6-ulac-01.txt .
> 
> I'm not sure that the existance of proof longer prefix assignments than
> a /32 (we're happy with our /43 btw) obviates the principle objection
> to
> ula-c namely that if there exists a lower barrier to entry on the
> availability of ula-c space then there is for pi-space that the
> temptation to shop for an upstream willing to route it is extremely
> high.
> 
> Private address space needs to be sufficiently toxic that no-one will
> consider routing it... ula-l actually achieves that.

Or conversely, PI availability needs to have a sufficiently low barrier to make it the preferred path for people that really want public routing.


> 
> > Rather than focus on the process of managing that space, for the
> moment I
> > just want to get the technical requirements clearly established. If
> ARIN (or
> > any RIR) chooses not to participate in the allocation of this space,
> that is
> > a separable policy discussion for another day. Until the ULA-C space
> is
> > clearly allocated to IANA, that discussion can't reasonably happen.
> 
> using unique public addresses for my private application, confers the
> salubrious benefit of being able to advertise and then black hole all
> traffic bound for those prefixes externally which I find quite
> attractive personally.

Then do that for your network. Others have different requirements where use of a ula-c for private interconnects with PI for the public interconnect is operationally simpler and lower cost. There is nothing about the existence of ula-c that mandates its use. The FUD about ula-c being a source of routing table bloat is really about an overly restrictive PI policy. The simplest solution to mitigate misuse of ula-c is to have the same organization deal with allocations, then if misuse becomes widespread revise the PI policy to make that be the lowest cost path for the abusers.

> 
> > Tony
> >
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> >