[arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement)

Izaac izaac at setec.org
Sun May 13 07:41:22 EDT 2012


On Sat, May 12, 2012 at 10:05:45PM -0700, Owen DeLong wrote:
> > In my opinion, if you can't fit your world into a /56 or /48, you're
> > doing something very, very wrong.  But hey, I get that stuff happens.
> 
> If you're a single end-site, then a /48 should be fine in almost every case,
> if not every case.
> 
> If you are an end-user with a campus or multiple campuses that have multiple
> end-sites each, then you need a /48 for each end-site to do things properly.
> (Note, end-sites may actually be defined by natural network aggregation points
> in topology and not actual physical  buildings, but, a /48 per building or per
> tenant in a multi-tenant building serves as a pretty good rule of thumb in either case.)
> 
> However, if you are giving out /48s to the end-sites you serve as an ISP and
> some of your customers may have multiple end-sites, then you may not even
> fit in a /32. For example, Hurricane Electric has definitely outgrown its /32 and
> has (thankfully) received a /24 for growing our network which will serve us
> quite nicely for many years to come.

Yes.  I would hope that an ISP requesting space at that level would not
need to be compelled to present a commensurate IPv6 allocation request.
I suspect, though, that there are any number of multi-homed and end-user
requesters seeking /20's and longer that simply have not bothered to
consider transition at all.  Or I may be wrong.  But there's probably no
way to tell for sure right now.

I'd love to see a summer researcher or intern at ARIN try to match up
IPv4 and IPv6 allocations and generate a report.  It could be delivered
along-side the real exhaustion announcement I expect sometime around
Thanksgiving or Christmas.  Is there a box pool that I can get in on for
this, by the way?  Maybe NANOG has one. Hmm.

> I think this was stated mostly tongue in cheek.

I assumed that all three were tongue in cheek.

> No, not really. You also left out argument 4 which is that it does not make
> sense to assign unrequested addresses because people that qualify for and
> need IPv4 addresses from ARIN may already have sufficient IPv6 addresses
> from some other source. While they could qualify for IPv6 addresses from ARIN,
> if they have absolutely no need for them and have already deployed their
> IPv6 using addresses from another source, what possible good comes from
> giving them ARIN IPv6 addresses that they don't need or want?

I like argument four; it makes sense.  You're quite right.  If you've
already got IPv6 space allocated (and especially in use) to cover those
newly requested IPv4 blocks, you shouldn't need any more.  And it should
be trivial to attach a quick, formulaic report stating such to meet a
hypothetical commensurate-IPv6-rule.

On the other hand, if you have a requester coming back for another /20
because of network growth or topology change or whatever, is it not
reasonable to expect that their previous expectations on the IPv6-side
have also changed?  If he's sitting on a ::/32, I'd hope that 64ki of
::/48s is enough to cover all the little /29s into which he hopes to
carve that shiny new /20.  But as you suggest above, maybe not.

Fortunately, men and women far better than I are available and in
position to suss out the details of policies.  It allows me to remain
some cranky jerk that lobs crudely formed lumps of concept at mailing
lists which he normally doesn't even read in real-time -- except that he
broke his procmailrc.

-- 
. ___ ___  .   .  ___
.  \    /  |\  |\ \
.  _\_ /__ |-\ |-\ \__



More information about the ARIN-PPML mailing list