-Original Message-
From: Chris Boyd [mailto:cb...@gizmopartners.com]
Sent: Tuesday, October 26, 2010 3:08 PM
To: NANOG
Subject: Re: IPv6 Routing table will be bloated?
On Oct 26, 2010, at 2:45 PM, George Bonser wrote:
> But how do they multihome without an ASN?
> If they have an AS
On Oct 26, 2010, at 1:31 PM, Randy Carpenter wrote:
>
> I think ARIN is now doing sparse allocations on /28 boundaries.
Yes (two NANOG messages attached from earlier this month)
/John
Begin forwarded message:
> From: John Curran
> Date: October 18, 2010 2:55:49 PM EDT
> To: David Conrad
> Cc:
> So, the best that I can tell (still not through debating with RIR), the
> IPv6 routing table will see lots of bloat.
96 more bits, no magic
On Tue, Oct 26, 2010 at 05:48:13PM -0400, Randy Carpenter wrote:
> Someone who Randy didn't attribute wrote:
> > I think APNIC has a policy that defines the minimum IPv6 allocation
> > based on your current IPv4 allocation/usage. This would fix the
> > problem?
> It would be nice as a start, but do
- Original Message -
> From: "Owen DeLong"
> To: "Franck Martin"
> Cc: "Randy Carpenter" , nanog@nanog.org
> Sent: Wednesday, 27 October, 2010 11:48:58 AM
> Subject: Re: IPv6 Routing table will be bloated?
> It's very interesting
heck-your-eligibility/check-ipv6
> http://www.apnic.net/services/become-a-member/how-much-does-it-cost
>
> - Original Message -
> From: "Randy Carpenter"
> To: "Franck Martin"
> Cc: nanog@nanog.org, "Nick Hilliard"
> Sent: Wednesday, 27 October, 2010
ick Hilliard"
Sent: Wednesday, 27 October, 2010 10:48:13 AM
Subject: Re: IPv6 Routing table will be bloated?
It would be nice as a start, but does not really take into consideration future
expansion needs.
I would think that you could draw some parallels, though.
Something like:
v4 /16
sed on your current IPv4 allocation/usage. This would fix the
> problem?
>
> - Original Message -
> From: "Randy Carpenter"
> To: "Nick Hilliard"
> Cc: nanog@nanog.org
> Sent: Wednesday, 27 October, 2010 6:31:18 AM
> Subject: Re: IPv6 Routing t
31:18 AM
Subject: Re: IPv6 Routing table will be bloated?
I think ARIN is now doing sparse allocations on /28 boundaries.
My personal opinion is that it should be even more sparse, and that allocations
should be done on nibble boundaries. Any reasonably-sized ISP should get at
least a /28.
I deal
RIRs, LIRs etc. sooner rather than later.
>
> On 10/26/2010 3:20 PM, George Bonser wrote:
> >
> >> -Original Message-
> >> From: Jack Bates [mailto:jba...@brightok.net]
> >> Sent: Tuesday, October 26, 2010 11:23 AM
> >> To: Randy Carpente
On Tue, 26 Oct 2010 12:19:30 -0500
Jack Bates wrote:
> On 10/26/2010 12:04 PM, Nick Hilliard wrote:
> > In practice, the RIRs are implementing sparse allocation which makes it
> > possible to aggregate subsequent allocations. I.e. not as bad as it may
> > seem.
> >
>
> Except, if you are given b
> From: Chris Boyd
> Sent: Tuesday, October 26, 2010 1:08 PM
> To: NANOG
> Subject: Re: IPv6 Routing table will be bloated?
>
>
> I beleive Jack said that they have redundant connections to his
> network. I took that to mean that they did not multihome to different
On Tue, Oct 26, 2010 at 12:45:45PM -0700, George Bonser wrote:
> But how do they multihome without an ASN?
Well, get space from one of your providers, and an LOA
to get the other to announce the deaggregate for you.
Or they've got legacy space, and never had an AS; just
get their
al.
On 10/26/2010 3:20 PM, George Bonser wrote:
-Original Message-
From: Jack Bates [mailto:jba...@brightok.net]
Sent: Tuesday, October 26, 2010 11:23 AM
To: Randy Carpenter
Cc: nanog@nanog.org
Subject: Re: IPv6 Routing table will be bloated?
On 10/26/2010 1:01 PM, Randy Carpenter wro
what's the problem anyway
with 32bit ASN's there should be enough AS namespace to give everyone that
wants to multihome their ipv6/ipv4 PI their own AS number...
should pretty much be the de-facto standard (unless ofcourse you want to
tie your customers to your internet-provider-activities by
On 10/26/2010 2:26 PM, Blake Dunlap wrote:
This is actually not that uncommon. You see it a lot in the smaller
level. I had several such clients at my last job. They want to be
multi-homed for redundancy, but either don't have enough space, or
don't want to pay full time people, so they use a s
On Oct 26, 2010, at 2:45 PM, George Bonser wrote:
> But how do they multihome without an ASN?
> If they have an ASN, how did they get it without going to an RIR and
> paying a fee?
I beleive Jack said that they have redundant connections to his network. I
took that to mean that they did not mu
We also have various customers that only obtain LIR registration services
and have no network links whatsoever with us (so just PI and/or AS
registration, no transit or whatever)
which -is- what a LIR does.. operating a network has nothing to do with
being a LIR per-se.
On Tue, 26 Oct 2010,
eh don't know about you americans but here in europe you just go to a LIR
and ask them to register an AS for you.
there are ofcourse maintenance fees nowadays.
On Tue, 26 Oct 2010, George Bonser wrote:
Shared hosting ISPs also do not make subdelegations and generally
don't
even uses the i
On Tue, Oct 26, 2010 at 14:45, George Bonser wrote:
> >
> > Shared hosting ISPs also do not make subdelegations and generally
> don't
> > even uses the ips on a one-specific-customer-per-ip basis.
>
> But how do they multihome without an ASN?
> If they have an ASN, how did they get it without goi
On Tue, 26 Oct 2010, George Bonser wrote:
To: Sven Olaf Kamphuis
Shared hosting ISPs also do not make subdelegations and generally
don't
even uses the ips on a one-specific-customer-per-ip basis.
But how do they multihome without an ASN?
If they have an ASN, how did they get it without g
>
> Shared hosting ISPs also do not make subdelegations and generally
don't
> even uses the ips on a one-specific-customer-per-ip basis.
But how do they multihome without an ASN?
If they have an ASN, how did they get it without going to an RIR and
paying a fee?
HAHA that would totally make the MAFIAA's day...
entering all your dialup and adsl customers into whois as they would be
"end users" :P quite sure the EU would not agree on that definition of
what constitutes an end-user, and therefore, its quite possible to provide
access services on PI space
2. RIPE has always issued PI space to LIRs (ISPs are by
definition LIRs).
ISPs are not per-se LIRs.
LIRs register IP space on behalf of customers
customers that do not make delegations themselves (i'm quite sure you
don't put each and every one of your access customers into whois,
On Tue, Oct 26, 2010 at 14:20, George Bonser wrote:
>
>
> > -Original Message-
> > From: Jack Bates [mailto:jba...@brightok.net]
> > On 10/26/2010 1:01 PM, Randy Carpenter wrote:
> > >
> > > Wait... If you are issuing space to ISPs that are multihomed, they
> > > should be getting their o
> -Original Message-
> From: Jack Bates [mailto:jba...@brightok.net]
> Sent: Tuesday, October 26, 2010 11:23 AM
> To: Randy Carpenter
> Cc: nanog@nanog.org
> Subject: Re: IPv6 Routing table will be bloated?
>
> On 10/26/2010 1:01 PM, Randy Carpenter wrote:
&g
On Oct 26, 2010, at 11:19 AM, Sven Olaf Kamphuis wrote:
> On Tue, 26 Oct 2010, Randy Carpenter wrote:
>
>> - Original Message -
>>> On 10/26/2010 12:04 PM, Nick Hilliard wrote:
In practice, the RIRs are implementing sparse allocation which makes
it
possible to aggregate su
On Tue, Oct 26, 2010 at 2:19 PM, Sven Olaf Kamphuis wrote:
> On Tue, 26 Oct 2010, Randy Carpenter wrote:
>
>> - Original Message -
>>>
>>> On 10/26/2010 12:04 PM, Nick Hilliard wrote:
In practice, the RIRs are implementing sparse allocation which makes
it
possible to ag
On Tue, Oct 26, 2010 at 21:19, Sven Olaf Kamphuis wrote:
On Tue, 26 Oct 2010, Randy Carpenter wrote:
- Original Message -
On 10/26/2010 12:04 PM, Nick Hilliard wrote:
In practice, the RIRs are implementing sparse allocation which makes
it
possible to aggregate subsequent allocati
On Tue, Oct 26, 2010 at 21:19, Sven Olaf Kamphuis wrote:
> On Tue, 26 Oct 2010, Randy Carpenter wrote:
>
>> - Original Message -
>>>
>>> On 10/26/2010 12:04 PM, Nick Hilliard wrote:
In practice, the RIRs are implementing sparse allocation which makes
it
possible to aggr
On 10/26/2010 1:01 PM, Randy Carpenter wrote:
Wait... If you are issuing space to ISPs that are multihomed, they
should be getting their own addresses. Even if they aren't
multihomed, they should probably be getting their own addresses. Why
would you be supplying them with address space if they
On Tue, 26 Oct 2010, Randy Carpenter wrote:
- Original Message -
On 10/26/2010 12:04 PM, Nick Hilliard wrote:
In practice, the RIRs are implementing sparse allocation which makes
it
possible to aggregate subsequent allocations. I.e. not as bad as it
may
seem.
Except, if you are give
- Original Message -
> On 10/26/2010 12:04 PM, Nick Hilliard wrote:
> > In practice, the RIRs are implementing sparse allocation which makes
> > it
> > possible to aggregate subsequent allocations. I.e. not as bad as it
> > may
> > seem.
> >
>
> Except, if you are given bare minimums, and
I think ARIN is now doing sparse allocations on /28 boundaries.
My personal opinion is that it should be even more sparse, and that allocations
should be done on nibble boundaries. Any reasonably-sized ISP should get at
least a /28.
I deal with many small-ish ISPs, and most are 5,000-10,000 u
On 26/10/2010 18:19, Jack Bates wrote:
My minimum /30 allocation per ARIN met a /27 in HD-Ratio thresholds. To not
be given the threshold space means no reservations for subtending ISPs, no
room for subtending ISPs to grow, and multiple assignments. If ARIN only
does /29 boundaries, I'll also be
On 10/26/2010 12:04 PM, Nick Hilliard wrote:
In practice, the RIRs are implementing sparse allocation which makes it
possible to aggregate subsequent allocations. I.e. not as bad as it may
seem.
Except, if you are given bare minimums, and you are assigning out to
subtending ISPs bare minimums
On 26/10/2010 17:23, Owen DeLong wrote:
He's talking about the bloat that comes from ISPs getting slow-started and then
only being able to increase their network in increments of 2x each time, so,
effectively ISP gets:
[...]
Probably not quite as bad as IPv4, but, potentially close.
In theory
dusty old routers with ram problems...
solution there: re-think the way you do your routing and compare the price
of ram versus cpu cycles. (as well as having custom hardware developed to
do it on, intel simply does not offer enough address bus lines to maintain
bigass tables and address them
On Oct 26, 2010, at 7:06 AM, TJ wrote:
> Quick comment:
> IGP bloat != BGP bloat. Your customers cannot announce the space you gave
> them externally - unless ~/32s, i.e. forced aggregation.
>
He's talking about the bloat that comes from ISPs getting slow-started and then
only being able to in
important.
Regards,
Jordi
> From: Tony Hain
> Reply-To:
> Date: Tue, 26 Oct 2010 09:02:00 -0700
> To: 'Jack Bates' ,
> Subject: RE: IPv6 Routing table will be bloated?
>
> You didn't miss anything, past ARIN practice has been broken, though using
> s
You didn't miss anything, past ARIN practice has been broken, though using
sparse allocation it is not quite as bad as you project. In any case, ISP's
with more than 10k customers should NEVER get a /32, yet that is what ARIN
insisted on giving even the largest providers in the region. Every ISP
sh
* Jack Bates:
> So, the best that I can tell (still not through debating with RIR),
> the IPv6 routing table will see lots of bloat. Here's my reasoning so
> far:
>
> 1) RIR (ARIN in this case, don't know other RIR interpretations) only
> does initial assignments to barely cover the minimum. If yo
On 10/26/2010 9:06 AM, TJ wrote:
Quick comment:
IGP bloat != BGP bloat. Your customers cannot announce the space you
gave them externally - unless ~/32s, i.e. forced aggregation.
Still waiting on ARIN to get back to my argument that I am allowed to
assign /32s to my subtending ISPs who are
On 10/26/2010 9:08 AM, Jeroen Massar wrote:
You are missing the point of making a proper plan which can justify
address space for your business for the next years.
According to ARIN, initial allocations due NOT allot for growth, only
for the existing infrastructure.
If done properly, you ha
On 2010-10-26 15:57, Jack Bates wrote:
[..]
> Am I missing something, or is this minimalist approach going to cause
> issues in BGP the same as v4 did?
You are missing the point of making a proper plan which can justify
address space for your business for the next years.
If done properly, you hav
Quick comment:
IGP bloat != BGP bloat. Your customers cannot announce the space you gave
them externally - unless ~/32s, i.e. forced aggregation.
Also, your customers shouldn't need to come back for more very often and
ideally you have some reservations for them a well :).
/TJ
PS - apologies fo
46 matches
Mail list logo
