[ppml] 2005-1 status

Scott Leibrand sleibrand at internap.com
Tue Jan 24 17:02:50 EST 2006 

IMO, 2005_1_orig does not *just* make IPv6 PI space available to anyone
who qualifies for IPv4 PI space, it goes much further (too far IMO).

With IPv4, a small organization that wants to multihome with BGP usually
gets a /24 from one or both of their ISPs, and announces that space to
both of them.  In the US, most tier1 networks accept such /24's from their
peers, but some do not.  However, those networks, and any networks (such
as those overseas) with more aggressive filters, can still access the
small organization, even in failover scenarios.  This is because they
still have the allocating ISP's aggregate netblock in their table, and the
allocating ISP receives the customer's /24 announcement either from the
customer directly or from the customer's other ISP in a failover scenario.

If this small organization wishes to switch ISPs, he will have to
renumber.  This likely involves changing router configurations, DHCP
server configurations, and server and DNS configurations for a small
number of statically addressed servers.  In most cases this can be done
without interrupting service.

If this small organization grows to the point where renumbering would
become an undue burden (defined by current policy 4.2.2.2 as having
efficiently utilized two /24's), he can request PI space from ARIN.  Once
he renumbers into that PI space, he needn't ever renumber those hosts
again, as his PI space is portable.

In the IPv6 world, I think we need a similar policy.  IMO 2005_1_orig is
not it.  2005_1_orig would allow the smallest multihomed organizations to
get PI space to start with, essentially forcing everyone in the
default-free zone to carry their routes or lose connectivity to them.  A
better policy would be to adopt the same sort of policy for IPv6 we have
for IPv4, which would require small organizations, for whom renumbering is
a small burden, to multihome with PA space initially.  Once such an
organization grows to the point where renumbering would become a
significant burden, it should be eligible to apply for PI space.

IMO the differences in recommended numbering practices between IPv4 and
IPv6 require us to measure renumbering difficulty differently.  Does
anyone have any good information on what the obstacles to renumbering are
in IPv6?  Not having done so myself, I can only speculate that difficulty
of renumbering is a function of the number of IPv6 subnets in use (which
will have to be renumbered in router configuration or DHCP) and the number
of statically configured IPv6 hosts (each of which would need to be
reconfigured either on the host itself or in DHCP, then updated in DNS).

Could a reasonable policy be written that makes a site eligible for PI
space once it has either a certain number of subnets (discrete physical
broadcast domains) in use, and/or has a certain number of statically
configured IPv6 hosts (which would presumably each be pointed to by a
discrete AAAA record in the DNS)?

-Scott

On 01/24/06 at 3:57pm -0500, Marshall Eubanks <tme at multicasttech.com> wrote:

> Sure :
>
> http://www.arin.net/policy/archive/2005_1_orig.html
>
> However, there is a caveat that it is 2:30 AM here, I am getting
> ready to leave for the airport,
> and this text may be tweaked, but not by me, at least not now.
> However, it should be close to what's resubmitted.
>
> Regards
> Marshall
>
> On Jan 24, 2006, at 3:46 PM, Scott Leibrand wrote:
>
> > Ok.  Could you perhaps re-post the version of 2005-1 you're
> > referring to
> > to de-confuse folks like myself?  :)
> >
> > -Scott
> >
> > On 01/24/06 at 3:34pm -0500, Marshall Eubanks
> > <tme at multicasttech.com> wrote:
> >
> >> Hello;
> >>
> >> On Jan 24, 2006, at 3:29 PM, Scott Leibrand wrote:
> >>
> >>> I would agree that IPv6 PI space should be made available to anyone
> >>> who qualifies for IPv4 PI space.  2005-1 as presented at L.A. was a
> >>> bit more restrictive than that, with the 100,000 device requirement.
> >>
> >> Yes, thus the proposal to go back to the original 2005-1. (Shouldn't
> >> these have version #s?)
> >>>
> >>> No, I don't think there is any working shim6 code.  However, as
> >>> I've tried
> >>> to say before, I think shim6 will provide a multihoming solution to
> >>> those
> >>> who've thus far not had one available.  IMO such a solution, if
> >>> widely
> >>> implemented, would likely be better for small sites than trying
> >>> to run
> >>> BGP.
> >>>
> >>
> >> Sure. We can certainly revisit this once that day comes.
> >>
> >>> -Scott
> >>
> >> Marshall
> >>
> >>>
> >>> On 01/23/06 at 9:52pm -0500, Marshall Eubanks
> >>> <tme at multicasttech.com> wrote:
> >>>
> >>>> Easy
> >>>>
> >>>> The experiment has been run. Something you basically never get to
> >>>> do in
> >>>> the real world, run a test case, has been done courtesy of IPv4.
> >>>> And it
> >>>> works and hasn't caused problems.
> >>>>
> >>>> The original 2005-1 matches the existing IPv4 model closely, so the
> >>>> burden should be on those who want to
> >>>> change it, to show that their plans will work and not cause
> >>>> problems
> >>>> or undue burdens.
> >>>>
> >>>> Without working code for SHIM6, I do not see how that can be
> >>>> done. (I
> >>>> am not saying that that is sufficient, just necessary.) Thus, my
> >>>> question.
> >>>>
> >>>> Regards
> >>>> Marshall
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On Jan 23, 2006, at 9:53 PM, Bill Darte wrote:
> >>>>
> >>>>> And I would request that alternatives posed should establish to
> >>>>> the
> >>>>> extent
> >>>>> possible why this alternative is necessary or best suited to be
> >>>>> the
> >>>>> consensus model.
> >>>>>
> >>>>> Bill Darte
> >>>>> ARIN AC
> >>>>>
> >>>>>
> >>>>> I would agree.  However, 2005-1 did not reach consensus, so we
> >>>>> need to
> >>>>> come up with an alternative that's more likely to do so.  I would
> >>>>> love
> >>>>> to
> >>>>> hear what exactly everyone thinks is an appropriate standard for
> >>>>> allocating IPv6 PI space so we can better gauge what would be a
> >>>>> consensus
> >>>>> position.
> >>>>>
> >>>>> -Scott
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 01/23/06 at 9:01pm -0500, Marshall Eubanks
> >>>>> <tme at multicasttech.com>
> >>>>> wrote:
> >>>>>
> >>>>>> I cannot predict what might happen hundreds of years from now.
> >>>>>>
> >>>>>> I can say, however, that 2002-3 has not caused an explosion in
> >>>>>> the
> >>>>>> routing table for IPv4, nor
> >>>>>> would I expect that 2005-1 would do so for IPv6.
> >>>>>>
> >>>>>> Regards
> >>>>>> Marshall
> >>>>>>
> >>>>>> On Jan 23, 2006, at 4:10 PM, Lea Roberts wrote:
> >>>>>>
> >>>>>>> because, as I'm sure you remember, Bill, the routing table won't
> >>>>> scale
> >>>>>>> over the lifetime of v6
> >>>>>>>
> >>>>>>> On Mon, 23 Jan 2006, Bill Darte wrote:
> >>>>>>>
> >>>>>>>> OK, I'll start....
> >>>>>>>>
> >>>>>>>> Why should the criteria for PI in v6 be ANY different than
> >>>>>>>> with v4?
> >>>>>>>> What was large under v4 is somehow not large under v6
> >>>>>>>> apparently?
> >>>>>>>> Turn in you v4 PI block for a v6 PI block.
> >>>>>>>>
> >>>>>>>> That's probably a sufficiently high level argument to begin the
> >>>>>>>> discussion.
> >>>>>>>>
> >>>>>>>> Bill Darte
> >>>>>>>> ARIN AC
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> -----Original Message-----
> >>>>>>>>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On
> >>>>>>>>> Behalf Of Lea Roberts
> >>>>>>>>> Sent: Monday, January 23, 2006 3:01 PM
> >>>>>>>>> To: Owen DeLong
> >>>>>>>>> Cc: ppml at arin.net
> >>>>>>>>> Subject: Re: [ppml] 2005-1 status
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> well, seems like maybe we should talk it out here (again...
> >>>>>>>>> :-) for a while.  this sounds more like a "PI for everyone"
> >>>>>>>>> policy.  while I'm sure there's a large number of people who
> >>>>>>>>> would like that, I still think it's unlikely it can reach
> >>>>>>>>> consensus...
> >>>>>>>>>
> >>>>>>>>> As I said at the meeting in L.A., I still think it is
> >>>>>>>>> possible to reach consensus for PI assignments for large
> >>>>>>>>> organizations and I thought that's where we were still headed
> >>>>>>>>> after the last meeting., i.e. trying to find criteria that
> >>>>>>>>> the latest round of objectors could live with.
> >>>>>>>>>
> >>>>>>>>> let the discussion begin!				/Lea
> >>>>>>>>>
> >>>>>>>>> On Mon, 23 Jan 2006, Owen DeLong wrote:
> >>>>>>>>>
> >>>>>>>>>> Kevin,
> >>>>>>>>>> 	Why don't you, Lea, and I take this off line and decide
> >>>>>>>>>> what to present back to the group.  I apologize for not
> >>>>>>>>>> having
> >>>>>>>>>> followed up in a more timely manner after the last meeting.
> >>>>>>>>>>
> >>>>>>>>>> Owen
> >>>>>>>>>>
> >>>>>>>>>> On Jan 23, 2006, at 7:54 AM, Kevin Loch wrote:
> >>>>>>>>>>
> >>>>>>>>>>> Marshall Eubanks wrote:
> >>>>>>>>>>>> Hello;
> >>>>>>>>>>>>
> >>>>>>>>>>>> When last I saw it, 2005-1 was to be reformatted to
> >>>>>>>>> something more
> >>>>>>>>>>>> like its original version.
> >>>>>>>>>>>
> >>>>>>>>>>> These were my suggestions using feedback from the last
> >>>>>>>>>>> meeting:
> >>>>>>>>>>>
> >>>>>>>>>>> To qualify for a minimum end site assignment of /44 you
> >>>>>>>>> must either:
> >>>>>>>>>>>
> >>>>>>>>>>>    - have an allocation or assignment directly from ARIN
> >>>>>>>>> (and not a
> >>>>>>>>>>>      legacy allocation or assignment)
> >>>>>>>>>>>
> >>>>>>>>>>>    OR
> >>>>>>>>>>>
> >>>>>>>>>>>    - meet the qualifications for an IPv4 assignment from
> >>>>>>>>> ARIN without
> >>>>>>>>>>>      actually requesting one.
> >>>>>>>>>>>
> >>>>>>>>>>>    OR
> >>>>>>>>>>>
> >>>>>>>>>>>    - be currently connected to two or more IPv6 providers
> >>>>>>>>>>> with
> >>>>> at
> >>>>>>>>>>> least
> >>>>>>>>>>>    one /48 assigned to you by an upstream visible in
> >>>>> whois/rwhois.
> >>>>>>>>>>>
> >>>>>>>>>>> Assignment prefixes shorter than the minimum would be
> >>>>>>>>> based on some
> >>>>>>>>>>> metric and definition of "sites".
> >>>>>>>>>>>
> >>>>>>>>>>> One practical way to look at sites is by number of
> >>>>>>>>>>> connections
> >>>>> to
> >>>>>>>>>>> separate upstream provider POPs.
> >>>>>>>>>>>
> >>>>>>>>>>> +--------------------------+
> >>>>>>>>>>> | Connections | Assignment |
> >>>>>>>>>>> +-------------+------------+
> >>>>>>>>>>> |         <12 |     /44    |
> >>>>>>>>>>> |       <=192 |     /40    |
> >>>>>>>>>>> |      <=3072 |     /36    |
> >>>>>>>>>>> |       >3072 |     /32    |
> >>>>>>>>>>> +-------------+------------+
> >>>>>>>>>>> (C=0.75 * 2^(48-A))
> >>>>>>>>>>>
> >>>>>>>>>>> Or if /56 becomes the new default PA assignment shift the
> >>>>>>>>> assignment
> >>>>>>>>>>> sizes right 4 bits.
> >>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Can someone tell me what the status of 2005-1 is
> >>>>>>>>>>>> currently ?
> >>>>>>>>>>>
> >>>>>>>>>>> As far as I know it hasn't changed since the last meeting.
> >>>>>>>>>>> Obviously it should be updated one way or another.  I
> >>>>>>>>> would gladly
> >>>>>>>>>>> write up a formal revision or new proposal if requested.
> >>>>>>>>>>>
> >>>>>>>>>>> - Kevin
> >>>>>>>>>>>
> >>>>>>>>>>> _______________________________________________
> >>>>>>>>>>> PPML mailing list
> >>>>>>>>>>> PPML at arin.net
> >>>>>>>>>>> http://lists.arin.net/mailman/listinfo/ppml
> >>>>>>>>>>
> >>>>>>>>>> _______________________________________________
> >>>>>>>>>> PPML mailing list
> >>>>>>>>>> PPML at arin.net
> >>>>>>>>>> http://lists.arin.net/mailman/listinfo/ppml
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> _______________________________________________
> >>>>>>>>> PPML mailing list
> >>>>>>>>> PPML at arin.net
> >>>>>>>>> http://lists.arin.net/mailman/listinfo/ppml
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> PPML mailing list
> >>>>>>> PPML at arin.net
> >>>>>>> http://lists.arin.net/mailman/listinfo/ppml
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> PPML mailing list
> >>>>>> PPML at arin.net
> >>>>>> http://lists.arin.net/mailman/listinfo/ppml
> >>>>>>
> >>>>> _______________________________________________
> >>>>> PPML mailing list
> >>>>> PPML at arin.net
> >>>>> http://lists.arin.net/mailman/listinfo/ppml
> >>>>
> >>>>
> >>
> >>
>
>

More information about the ARIN-PPML mailing list