[arin-ppml] IPv6 Non-connected networks

[Kevin Kargel]

What is the difference between networks (numbers is IPv4 think) that may be routed next year and networks that may be routed next week? In the end they are going to take the same number of slots and consume the same quantity of backbone at any point in time regardless of which pool they come from.

The discriminator here is not whether the networks will be globally routed, most everyone admits that is transmutable.  The discriminator is whether the networks are globally unique.  If they are in fact globally unique then the cost and acquisition requirements should be the same regardless of the intended use.  

There is no shortage of IPv6.  Get what you need, route what needs to be connected globally and don't route what doesn't, you are in control of your networks.  If you need separate blocks for internal and external networks then get them, you obviously have the requirements to justify the resources.  If you cannot justify another allocation then just carve out a block from your primary allocation for internal use and you are all set.  In the future when you want that network to go public all it takes is an adjustment to advertisement and/or firewall ACL's and you are off and running.  

I would much rather see liberalized allocation policies than restricted routing policies.  Let the ISP manage what is global and what is local by local policy according to local requirements.  

The simpler we can keep all of this the better off we will all be.  Complexity builds cost.  Simplicity engenders efficiency.  

 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of William Herrin
> Sent: Monday, February 22, 2010 2:16 PM
> To: matthew at matthew.at
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] IPv6 Non-connected networks
> 
> On Mon, Feb 22, 2010 at 2:29 PM, Matthew Kaufman <matthew at matthew.at>
> wrote:
> > Michael Richardson wrote:
> >> So far I haven't seen a proposal (other than 103) which really
> addresses
> >> this need.   It seems like the best answer is an RFC to be written to
> >> tell IANA to delegate FC00::/16 to the RIRs.
> >
> > This is approximately what I said two weeks ago, and so I still agree
> > entirely. If the RIR wants to hand out addresses which "will never be
> > routed" then IETF needs to specify what bits are set that mean "never be
> > routed", rather than "lets just pick a corner of space we've been
> delegated"
> 
> I concur as well. And if we want to hand out addresses for "may be
> connected in the future" instead then they should meet the same
> criteria as the ones for "are connected single-homed now."
> 
> One additional thought:  there's no hard and fast rule as to which has
> to come first: the RFC or the policy. An obvious objection to the RFC
> is that the RIRs haven't requested it. Having a policy in place for
> what to do with the numbers might help "grease the skids" for an RFC.
> 
> Regards,
> Bill Herrin
> 
> --
> William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
> 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
> Falls Church, VA 22042-3004
> _______________________________________________
> 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.