prefix lengths [was Re: stla registry db issue]
Paul Wilson
pwilson@apnic.net
Fri, 28 Jan 2000 14:43:30 +1000
Here's a somewhat belated response on this topic, and on the previous
thread.
In this discussion it seems to me that the critical question is, what
defines an ISP?
In the v4 world, BigCo may be a large multinational company with a large
multihomed infrastructure, which doesn't call itself an ISP but which
nevertheless qualifies for a Provider Independent (i.e. portable, globally
routable) allocation. On the other hand, SmallCo may provide ISP services,
but have a small singly-homed infrastructure and therefore not qualify for a
PI allocation (needing instead to get address space from its upstream).
Therefore the allocations that RIRs make are not simply dependent on whether
the organisation is an "ISP", but rather on a number of other
technically-based and objective criteria.
We could of course redefine the term "ISP" to mean an organisation that
actually receives a PI allocation, but that's not really useful or necessary
since the term is so widely used to refer to a bigger class of
organisations.
In the IPv6 world, we could likewise define an "ISP" as an organisation that
qualifies for a /35 allocation and a /29 (subTLA) reservation, and I suspect
that this definition is behind some of the previous discussions. In this
case it goes without saying that we would never share a /29 among multiple
"ISPs", simply because the /29 is reserved for each "ISP".
However we must agree that once a /29 has been reserved/allocated to one
organisation, there *will* be downstream customer organisations receiving
assignments from that address block and using those assignments for ISP
activities. But the critical thing is that whether or not they call
themselves an ISP (and we don't care) their assignment will be "provider
aggregatable" and not entitled to be announced globally. Rather, like any
other downstream customer, their prefixes will be aggregated by the upstream
provider within its own announcement.
I believe it is this type of organisation (the small, downstream ISP) which
Kengo Nagahashi was referring to in his original message.
Incidentally, I guess such a downstream organisation (call it an ISP or not)
could conceivably end up with a /35 or larger assignment, but would still
aggregate that within its upstream address block, until such time as it
qualified for its own subTLA allocation. Furthermore, my understanding (and
correct me if i'm wrong) is that such an organisation could also be
multi-homed, having an equal-sized assignment from each of several
upstreams, but again having each of its routes aggregated in the global
announcements of those upstreams. This may not be the best case, but it
surely must be a possible outcome for one of the small ISP that grows a
multi-homed infrastructure without yet qualifying for a subTLA.
Finally, on the question of advertising prefix lengths longer than /29, it
is in fact the proposal of the RIRs that the prefixes announced by any
organisation will correspond only to their allocation (anywhere from /16 to
/35), and not to their reservation (which would be either /16 or /29). The
justification behind this (as discussed with the IAB in Minneapolis last
year) is that in a future scenario where many TLA and subTLA blocks were
released and allocated, and where routing table expansion again becomes a
concern, it is necessary for ISPs to have an objective means available for
limiting the size of their routing tables, and the best such means available
is to filter on prefix length.
The alternative is a huge routing table populated with /16 and /29 prefixes
only, where no objective means for route filtering is available, and where
bilateral routing agreements would emerge as the only way for an ISP to
control its tables.
Regards,
Paul Wilson
APNIC.
______________________________________________________________________
Paul Wilson, Director-General, APNIC <pwilson@apnic.net>
http://www.apnic.net ph/fx +61 7 3367 0490/82
----------------------------------------------------------------------
See you at APRICOT 2000! 28 Feb - 2 Mar http://www.apricot2000.ne.kr
----------------------------------------------------------------------
> -----Original Message-----
> From: owner-6bone@ISI.EDU [mailto:owner-6bone@ISI.EDU]On Behalf Of Brian
> E Carpenter
> Sent: Wednesday, 29 December 1999 3:51
> To: 6bone@ISI.EDU
> Subject: prefix lengths [was Re: stla registry db issue]
>
>
> Folks,
>
> 2**64 is a big number. It's the square of 2**32 if nobody
> noticed. The majority of
> BigCos will be able to understand this and use no more than an
> SLA. If there are a few
> idiot CIOs who insist on more for no good reason, it isn't the
> end of the world.
>
> I am very relaxed about /29s being reserved at this stage of the
> life of IPv6,
> because 2**29 is also a big number. I'm not recommending any
> change in the RIR
> guideline of only allocating /35s; all I'm doing is saying that
> we must stick
> to the rule of not splitting /29s between ISPs.
>
> If BigCo is 20-homed, and doesn't want to deal with 20 prefixes,
> then I can certainly
> see a case for them leasing a prefix that can be in the
> default-free table. But this
> really will be the exception case. What we must do is ensure that
> a 2-homed site can
> easily deal with 2 prefixes. BTW, how many 6bone sites are
> multihomed today?
>
> Brian
>
> "Perry E. Metzger" wrote:
> >
> > "Michael H. Lambert" <lambert@psc.edu> writes:
> > > On Thu, 23 Dec 1999, Bill Manning wrote:
> > > >
> > > > Er, that is pretty much exactly the point I was trying to make.
> > > > If Brian is right and that group is successful in restricting
> > > > announcements to /29's, how much space is wasted for the sixty
> > > > nodes that form the cluster "www.bigco.com" that has connections
> > > > to 20 major ISPs?
> > >
> > > But is "bigco.com" a transit IPv6 provider? My understanding
> is that if
> > > it isn't, it should never be allocated its own TLA. It
> should receive a
> > > small block from each of its ISPs. Or am I missing something?
> >
> > Anyone out there who thinks they can actually prevent GM or Yahoo or
> > the like from getting their own routes announced should talk to an
> > anti-trust lawyer.
> >
> > Perry
>
> --
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> Brian E Carpenter (IAB Chair)
> Program Director, Internet Standards & Technology, IBM
> On assignment for IBM at http://www.iCAIR.org
> Attend INET 2000: http://www.isoc.org/inet2000
> Non-IBM email: brian@icair.org
>
>
>