[arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process - revised

[Michael Richardson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>>>> "David" == David Farmer <farmer at umn.edu> writes:
    David> - Needs Basis

  I agree.

    David> First and probably most important from my personal point of
    David> view, I don't see a needs basis in this policy, even in the
    David> classful IPv4 days you had to demonstrate need to get a Class
    David> B, or Class A; I believe that you had to demonstrate a need

  In those days was very little required to get a /24.
  And, lots of organizations *DID* get /8s in those days, recall.
  As long as:

    David> So, I believe this proposal would need some kind of needs
    David> basis. Maybe something as simple as, to get a /32 provide a
    David> creditable business plan for more than 200 sites in two
    David> years, and for a /40 more than 1 site, for a /48 a site with
    David> more than 256 host, and anyone my request a /56. 

  The last part is there (/56), then I agree with the need for a minimal
needs basis.

    David> - This could encourage the Big Guys to filter the little
    David> guys, by maybe making it to easy for them to do so.
 
  Doesn't matter.  IPv6 encourages a site to have multiple prefixes.
Officially, that's the way to multihome (until shim6 either works or
fails), and now that site-locals are gone, there is nothing else to use
inside.  
  The /56s won't be seen in the routing table, and *THAT IS A GOOD THING*

    David> - As a result, this could encourage the smaller guys to try
    David> to get bigger blocks than they really need in order to
    David> justify having a routing slot and not being filtered.

  That's where we are now.

    David> - This would make ARIN's IPv6 policies way different than all
    David> the other RIRs.

    David> William partially answered this; paraphrasing his answer,
    David> maybe we shouldn't shift the whole world all at once.  There
    David> might be an advantage for one RIR to go down this road first.

  I concur.

    David> - 6.10.1 Micro-allocations for Critical Infrastructure are
    David> not moot and should be preserved, this allows network
    David> operators to create special filtering rule, if they wish, for
    David> these Critical Infrastructures.  It seems prudent to keep
    David> some special ranges such as these.  Maybe they should be
    David> renamed to Critical Infrastructure Allocations.  The term
    David> micro-allocations probably doesn't fit anymore, but they are
    David> still Critical Infrastructure.

  Okay.
  It's just a special extra pool of /48s or /56s, it's not a big deal.

    David> intractable ones.  Are there some incremental steps we can
    David> take toward this vision, without jumping off the cliff into a
    David> brave but unknown new world?

    David> How about creating PI /40 allocations for small providers and
    David> PI /40 assignments for large multi-site end-users, and
    David> blessing providers to make similar PA assignments.  In
    David> Dearborn we couldn't get consensus to change the 200 customer
    David> in two year justification required to get a /32. And there is
    David> nothing explicit for larger multi-site end users either. A
    David> /40 seems to fit the bill.

  okay, I can live with this.

    David> One last reminder;

    David> If you have opinions or arguments why the AC should or should
    David> not put this proposal on its docket you should speak up by
    David> the middle of next week.

    David> Thank you for your participation.

  Thanks for bringing this back up.
  I would like to see the AC proceed with this.

- -- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition. 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBSyMGeYCLcPvd0N1lAQIawQgAgikXqMcRsPEDigfCZZuJ2FYZbzWHaK9m
cpqzV+BT8InMMaOWcrhNSDAkwK8XNQlfvsxmoqk2of92SH7EyJLfC83Ut+PG50GF
h5H5zl7etw2Tb2+LnVwpqc8h4bYi2+oLpF/p2C7heH0118YeBBferzXQcgiFS9qg
uwA/xqRh+EwMm1Who4/ZFLGdBd+7sNFgo64OA2Gde58gpoqRZ519rqaBD4nDqz/w
mbU2T4YLxt4uTlubNaspVOgIkCGGpRYQx0hXOXDbm0KMmIvI6SFgXzj7JHce1sAG
FbPLspmuZHaC6yor4Yr8fPMuzov+FFi2Gfwu4oEi2AgJOkBtoLZAVA==
=MFoK
-----END PGP SIGNATURE-----