[arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66)

james machado hvgeekwtrvl at gmail.com
Tue Feb 17 17:41:32 EST 2015


It seems to me, and I am sure I don't know or have all the answers,
that there is a disconnect going on in this discussion.

On one hand there is the great cry of v4 is running out and everybody
should/must move to v6 because addresses are plentiful and this is the
future.  On the other we are getting the "we don't offer it because
nobody asks for it".  Someplace in the middle of all this is the - you
can't have v6 addresses because you don't a) have enough
nodes/networks or b) already have v4 space (which you probably can't
qualify for and if you could we don't have any to give you) or c)
your not worthy of space in the routing table even if you could get
the assignment.

Now I don't know how much it costs for a v6 route in the global table
so I can't speak to that.

What I find interesting is that we know that at some point in the
future it will make more sense to do v6 than v4 and to get there we
have to get more v6 out than there is now.  I don't know what that
point is but I suspect someone has calculated it.  What I do know is
that if we want to get there sooner rather than later it make sense to
make it easier and not harder to get v6 allocations.  Its not like
were going to run out of addresses anytime soon and if my kids or
grand kids have to go through a v6 to vNumber conversion that's OK
with me as I wouldn't want them to get too comfortable in the jobs
they have.

I do get that FIB and RIB space is limited and needs to grow but grow
it will.  The sky has always been falling and we have always been
running out of space in the global routing table.  One way of getting
the space we need will be changes in hardware and software, another
will be getting v4 routes out of the table.  One thing is for sure if
the vendors don't see a need they won't find a way.

I support Gary's suggestion as written.  I would change it to read "if
they can pay the fee make the assignment".  Sure make them show how
they would utilize it but don't make artificial barriers as to the
number of nodes or networks except for determination of the size of
the allocation.

>From the perspective of the Enterprise renumbering is excruciating and
is to be avoided at all costs.  It doesn't matter if it is v6 or v4,
it is worth paying for an allocation just so I don't have to do that.
And once I don't have to worry about renumbering I am no longer
married to my current ISP.  This is why I can't walk to another
carrier when I get crappy service.  Its not the 3-6 month wait on
circuits.  Its the 100+ vendors and VPNs that have to be reworked to
renumber around.

Just to add to the discussion, when ARIN was in San Diego I asked the
question about allocations as I have 4 locations and I was wondering
how the allocation might work out.  The answer I received was "1 /48
for each location" it wasn't "1 /48 for each 2000 computers or 200
subnets".

James



On Tue, Feb 17, 2015 at 1:49 PM, Gary T. Giesen <ggiesen at giesen.me> wrote:
> FYI to try to address Bill Herrin's concern, I amended that they be 13 sites
> in a contiguous network to try to reduce the probability that there be 13
> separate announcements, although I'm not sure how enforceable such a
> provision would be.
>
> GTG
>
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of David Huberman
> Sent: February-17-15 3:46 PM
> To: mcr at sandelman.ca; Gary T. Giesen
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please
> don't me make do ULA + NAT66)
>
> Michael,
>
> Does Gary's concrete suggestion -- adding a qualifier that you can get
> approved for IPv6 space if you have 13 more sites, with no other criteria --
> make sense to you? Would you support it?
>
> Thanks,
> David
>
>
> -----Original Message-----
> From: mcr at sandelman.ca [mailto:mcr at sandelman.ca]
> Sent: Tuesday, February 17, 2015 12:42 PM
> To: Gary T. Giesen
> Cc: David Huberman; arin-ppml at arin.net
> Subject: Re: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please
> don't me make do ULA + NAT66)
>
>
> Gary T. Giesen <ggiesen at giesen.me> wrote:
>     > That's obviously a consideration but I don't want to build an IPv6
>     > adoption model for my customers around something quite so fuzzy where
>     > one customer could be approved and another be denied. I prefer
>     > something a little more concrete that I can point a customer to an say
>     > "apply under this" and it's plain to them (and ARIN) that they
> qualify.
>
> I completely hear you.
> I've argued repeatedly (back to 2007) that this BS about routing slots is
> onsense, and that these kinds of policies are preventing adoption of IPv6 by
> small and middle sized enterprises.
>
> It's just not ARIN's job to protect routing slots.
>
> I'm not clear if the resulting /40 will be announced at all.
> If it will remain internal with IPVPN, and then, with a PI prefix from each
> *local* ISP, then you have the classic Non-Connected Network.
>
> --
> ]               Never tell me the odds!                 | ipv6 mesh networks
> [
> ]   Michael Richardson, Sandelman Software Works        | network architect
> [
> ]     mcr at sandelman.ca  http://www.sandelman.ca/        |   ruby on rails
> [
>
>
>
> _______________________________________________
> 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.
>
> _______________________________________________
> 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.



More information about the ARIN-PPML mailing list