[ppml] 2005-1 status

Scott Leibrand sleibrand at internap.com
Tue Jan 24 21:53:26 EST 2006 

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

> I do not agree.  I do not see why 2005-1 goes further than 2002-3 but
> I am certainly willing to be enlightened.

As I'll argue below, the original 2005-1 goes further than the original
2002-3.  I'd like the version of 2005-1 that finally gets approved to be
more like the final /22 version of 2002-3.

> What 2002-3 addressed (at least to me, when I was involved in writing
> the original draft) was not the difficulty of renumbering, but the
> difficulties associated with multihoming with aggregated addresses.
> There is a possibility of being black holed if you are multihomed and
> your PA space is aggregated. It's happened to me. It's not fun. It's
> not easy to detect, and it relies on the kindness of others to fix.

I've also been involved in such situations.  Though I haven't been
directly affected, I've had to help our customers fix them.  IMO this is
no longer as much of a problem for IPv4, especially in the ARIN region.
As was pointed out to me in a private reply, Verio no longer filters out
PA /24's, so I don't know of any North American Tier 1 NSPs with
problematic filters.  IMO it remains to be seen how much of a problem this
might be in IPv6.

> The original 2002-3 envisioned a /24 PI space for any multihomer;
> that was weakened to a /22 with justification for the space required.

I wasn't involved then, but I think there ware good reasons for weakening
2002-3, and I think the same reasons apply to the original 2005-1.

> I have never received a report of these micro-assignments being
> filtered out, and I have asked.

Nor have I.  To do so would be to disconnect from part of the Internet,
which I have not known to be a viable business model.

> I do not see signs that they are breaking the back of the IPv4
> address table.
>
> If you want to put a barrier to keep out someone with two DSL lines and
> a Mac at home, fine. But I don't think that the difficulty of
> renumbering is that germane to setting that barrier. Just my opinion.

And there we disagree.  I think non-PI multihoming should be the default
until the point where the benefits of PI space to the recipient outweigh
the cost of requiring all default-free operators to carry the PI block.  I
don't know exactly where those two lines cross, but I believe we need to
set the barrier as close to that point as we can, as was done with 2002-3.

> And, certainly, I would view someone with a 2002-3 micro assignment
> as having qualified.

I would agree.

> So, maybe anyone who has filled up a /56 or /57 should qualify here.

Perhaps.  I'm not sure, but will accept that as one possible solution.

> As you may know, I maintain my on list of ASN announced in BGP
> http://www.multicasttech.com/status/asn_expand.txt So, I keep up with
> new ASN announced. And, at least for ARIN, they seem to be dominated by
> (apparently) small multihomers. There is a big demand for this out
> there; IMHO Arin should give them the tools to do what they want to do.

That's fair, but IMO the policy providing those tools should try not
unduly accelerate the growth in the routing table.  There are a lot of
folks whose routers become obsolete once the routing table reaches a size
where they need more RAM than their router can handle.  Those are the
folks footing the bill each time another multihomed enterprise chooses to
announce their route into BGP, and IMO we should consider their interests
as well as those of the folks who would like to multihome.

-Scott

> On Jan 24, 2006, at 5:02 PM, Scott Leibrand wrote:
>
> > 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