[ppml] IPv6 addressing plans

Azinger, Marla marla.azinger at frontiercorp.com
Tue Sep 4 12:57:07 EDT 2007

You might find the following document that is working its way through IETF right now useful.  http://www.ietf.org/internet-drafts/draft-ietf-v6ops-addcon-05.txt
Also, I would stick to getting IPv6 Allocations from the respective RIR.  All the same routing reasons still apply to IPv6 at this time as they do for IPv4.  Maybe architectural changes could occur in the future...but we are not there yet.
Another one to read: ftp://ftp.isi.edu/in-notes/rfc1519.txt and http://www.ietf.org/rfc/rfc3177.txt.  I thought there was another document for guidance to ISP's...but I cant seem to find it.

-----Original Message-----
From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of cja at daydream.com
Sent: Tuesday, September 04, 2007 9:28 AM
To: michael.dillon at bt.com
Cc: ppml at arin.net
Subject: Re: [ppml] IPv6 addressing plans


I used to run a network that had allocations from the (at the time) 3 RIRs.  I did that on purpose for a couple of reasons.

- The networks were connected in a way that it made sense to have RIR based allocations 
-  I wanted our networks and the people who ran them to be active in the appropriate communities.  
-  The deployment schedules and address space utilization rates were significantly different from region to region. If we had it all from ARIN we probably would have had to have three separate allocations with different maintainer IDs anyway.  

I can tell you this.  And I know you're not going to believe me but it was much much easier to deal with ARIN's policies than the policies of the other RIRs.   We had a very small allocation window size from RIPE and so if we wanted to assign a subnet greater than a /29 to a customer we had to ask permission.  Even when it was raised to a /24 it was a total pain.  Further there were some really interesting requirements of cable providers in RIPE and APNIC that we had to work with the communities to fix.  That actually went very smoothly.  

We were certainly told that we could have all of our allocations from ARIN because our company headquarters was in the US.  There were days that I wished I had done just that.  I think we did greatly benefit from being active in all the regions and knowing the regional ISP communities was also a great benefit.  

I hope this helps.  

On 9/4/07, michael.dillon at bt.com <  <mailto:michael.dillon at bt.com> michael.dillon at bt.com> wrote: 

Does anyone have any reasoning why a network spanning two or more of the 
RIR regions, should or should not get separate ISP allocations from each

I'm not just interested in opinions, but also the reasoning behind them,
especially any technical pros and cons.

In addition, are there any characteristics that define a good IPv6
addressing plan for a network operator?

We've just received an IPv6 /22 from RIPE based solely on projections in
our European network infrastructure. Fairly soon we will have to decide 
whether to internally assign chunks of that space to our North American
network or to go to ARIN for a separate IPv6 allocation based on North
American needs only.

I imagine that a number of other companies are in this position and if 
there is actually a best practice for IPv6 addressing, it would be good
to document it and follow it before deployment gets much further ahead.
On the other hand, if it is a coin-toss scenario from a technical point 
of view, it would be nice to see general acknowledgement of that fact.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070904/fbd95713/attachment.html>

More information about the ARIN-PPML mailing list