IPv6 Routing table will be bloated?
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 you need more due to routing, you'll need to provide every pop, counts per pop, etc, to show how v6 will require more than just the minimums (full routing plan and customer counts to justify routing plan). HD-Ratio has NO bearing on initial allocation, and while policy dictates that it doesn't matter how an ISP assigns to customer so long as HD-Ratio is met, that is not the case when providing justification for the initial allocation. 2) Subsequent requests only double in size according to policy (so just keep going back over and over since HD is met immediately due to the minimalist initial assignment?) So I conclude that since I get a bare minimum, I can only assign a bare minimum. Since everything is quickly maxed out, I must request more (but only double), which in turn I can assign, but my customer assignments (Telcos/ISPs in this case) will be non-contiguous due to the limited available space I have to hand out. This will lead to IGP bloat, and in cases of multi-homed customers whom I provide address space for, BGP bloat. I'm small, so my bloat factor is small, but I can quickly see this developing exactly as my v4 network did (if it was years ago when I first got my v4 allocation, growing to today, for each allocation I got for v4, I'd expect similar out of v6). Sure, the end user gets loads of space with those nice /48's, but the space within ISPs and their ISP customers is force limited by initial allocations which will create fragmentation of address space. This is brought about due to the dual standard of initial vs subsequent allocations (just enough to cover existing vs HD Ratio). As an example, Using HD-Ratios as an initial assignment metric can warrant a /27, whereas the minimalist approach may only warrant a heavily utilized /30. 3 bits doesn't seem like much, but it's a huge difference in growth room. Bare minimums, as provided by me, only included the /24 IPv4 DHCP pools converted with a raw conversion as /32 IPv4 = /48 IPv6 network Am I missing something, or is this minimalist approach going to cause issues in BGP the same as v4 did? Jack
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 for top posting. On Oct 26, 2010 9:59 AM, "Jack Bates" <jbates@brightok.net> wrote:
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 you need more due to routing, you'll need to provide every pop, counts per pop, etc, to show how v6 will require more than just the minimums (full routing plan and customer counts to justify routing plan). HD-Ratio has NO bearing on initial allocation, and while policy dictates that it doesn't matter how an ISP assigns to customer so long as HD-Ratio is met, that is not the case when providing justification for the initial allocation.
2) Subsequent requests only double in size according to policy (so just keep going back over and over since HD is met immediately due to the minimalist initial assignment?)
So I conclude that since I get a bare minimum, I can only assign a bare minimum. Since everything is quickly maxed out, I must request more (but only double), which in turn I can assign, but my customer assignments (Telcos/ISPs in this case) will be non-contiguous due to the limited available space I have to hand out. This will lead to IGP bloat, and in cases of multi-homed customers whom I provide address space for, BGP bloat.
I'm small, so my bloat factor is small, but I can quickly see this developing exactly as my v4 network did (if it was years ago when I first got my v4 allocation, growing to today, for each allocation I got for v4, I'd expect similar out of v6). Sure, the end user gets loads of space with those nice /48's, but the space within ISPs and their ISP customers is force limited by initial allocations which will create fragmentation of address space. This is brought about due to the dual standard of initial vs subsequent allocations (just enough to cover existing vs HD Ratio).
As an example, Using HD-Ratios as an initial assignment metric can warrant a /27, whereas the minimalist approach may only warrant a heavily utilized /30. 3 bits doesn't seem like much, but it's a huge difference in growth room. Bare minimums, as provided by me, only included the /24 IPv4 DHCP pools converted with a raw conversion as /32 IPv4 = /48 IPv6 network
Am I missing something, or is this minimalist approach going to cause issues in BGP the same as v4 did?
Jack
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 of X size or are multihomed.
Also, your customers shouldn't need to come back for more very often and ideally you have some reservations for them a well :).
If the initial allocation from ARIN is only for current infrastructure and customers (the bare minimum), there is no room for reservation, nor will customers have room to grow in the initial allocation. This is the problem with minimal on initial instead of HD-Ratio (which is what the rest of the policy is based on), but it could lead to fragmented networks. Jack
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 increase their network in increments of 2x each time, so, effectively ISP gets: 1 x /32 Initial Fills that up, gets 1 x /32 First subsequent Then 1 x /31 then 1 x /30 etc. Probably not quite as bad as IPv4, but, potentially close.
Also, your customers shouldn't need to come back for more very often and ideally you have some reservations for them a well :).
Consider the scenario where you're dealing with an ISP that provides services to other ISPs as his downstream customers and the above statement doesn't hold true like you think it should. Owen
/TJ PS - apologies for top posting. On Oct 26, 2010 9:59 AM, "Jack Bates" <jbates@brightok.net> wrote:
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 you need more due to routing, you'll need to provide every pop, counts per pop, etc, to show how v6 will require more than just the minimums (full routing plan and customer counts to justify routing plan). HD-Ratio has NO bearing on initial allocation, and while policy dictates that it doesn't matter how an ISP assigns to customer so long as HD-Ratio is met, that is not the case when providing justification for the initial allocation.
2) Subsequent requests only double in size according to policy (so just keep going back over and over since HD is met immediately due to the minimalist initial assignment?)
So I conclude that since I get a bare minimum, I can only assign a bare minimum. Since everything is quickly maxed out, I must request more (but only double), which in turn I can assign, but my customer assignments (Telcos/ISPs in this case) will be non-contiguous due to the limited available space I have to hand out. This will lead to IGP bloat, and in cases of multi-homed customers whom I provide address space for, BGP bloat.
I'm small, so my bloat factor is small, but I can quickly see this developing exactly as my v4 network did (if it was years ago when I first got my v4 allocation, growing to today, for each allocation I got for v4, I'd expect similar out of v6). Sure, the end user gets loads of space with those nice /48's, but the space within ISPs and their ISP customers is force limited by initial allocations which will create fragmentation of address space. This is brought about due to the dual standard of initial vs subsequent allocations (just enough to cover existing vs HD Ratio).
As an example, Using HD-Ratios as an initial assignment metric can warrant a /27, whereas the minimalist approach may only warrant a heavily utilized /30. 3 bits doesn't seem like much, but it's a huge difference in growth room. Bare minimums, as provided by me, only included the /24 IPv4 DHCP pools converted with a raw conversion as /32 IPv4 = /48 IPv6 network
Am I missing something, or is this minimalist approach going to cause issues in BGP the same as v4 did?
Jack
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 linearily so you can keep entries for each ip or mac address out there and counters with them to automatically "migitate" ddos attacks and give every communications partner their own fair share on the outgoing interface's capacity). (and no, we're not talking linux/bsd here... just dedicated routing firmware on let's say ibm's power-6/power-7 platform) instead of buying the same old shit from juniper/cisco/foundry again which doesn't even have enough ram to announce /30's ipv4 (if everyone would do so ;), let alone properly prevent ddos attacks from even being possible -- Greetings, Sven Olaf Kamphuis, CB3ROB Ltd. & Co. KG ========================================================================= Address: Koloniestrasse 34 VAT Tax ID: DE267268209 D-13359 Registration: HRA 42834 B BERLIN Phone: +31/(0)87-8747479 Germany GSM: +49/(0)152-26410799 RIPE: CBSK1-RIPE e-Mail: sven@cb3rob.net ========================================================================= <penpen> C3P0, der elektrische Westerwelle ========================================================================= Confidential: Please be advised that the information contained in this email message, including all attached documents or files, is privileged and confidential and is intended only for the use of the individual or individuals addressed. Any other use, dissemination, distribution or copying of this communication is strictly prohibited. On Tue, 26 Oct 2010, Owen DeLong wrote:
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 increase their network in increments of 2x each time, so, effectively ISP gets:
1 x /32 Initial Fills that up, gets 1 x /32 First subsequent Then 1 x /31 then 1 x /30 etc.
Probably not quite as bad as IPv4, but, potentially close.
Also, your customers shouldn't need to come back for more very often and ideally you have some reservations for them a well :).
Consider the scenario where you're dealing with an ISP that provides services to other ISPs as his downstream customers and the above statement doesn't hold true like you think it should.
Owen
/TJ PS - apologies for top posting. On Oct 26, 2010 9:59 AM, "Jack Bates" <jbates@brightok.net> wrote:
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 you need more due to routing, you'll need to provide every pop, counts per pop, etc, to show how v6 will require more than just the minimums (full routing plan and customer counts to justify routing plan). HD-Ratio has NO bearing on initial allocation, and while policy dictates that it doesn't matter how an ISP assigns to customer so long as HD-Ratio is met, that is not the case when providing justification for the initial allocation.
2) Subsequent requests only double in size according to policy (so just keep going back over and over since HD is met immediately due to the minimalist initial assignment?)
So I conclude that since I get a bare minimum, I can only assign a bare minimum. Since everything is quickly maxed out, I must request more (but only double), which in turn I can assign, but my customer assignments (Telcos/ISPs in this case) will be non-contiguous due to the limited available space I have to hand out. This will lead to IGP bloat, and in cases of multi-homed customers whom I provide address space for, BGP bloat.
I'm small, so my bloat factor is small, but I can quickly see this developing exactly as my v4 network did (if it was years ago when I first got my v4 allocation, growing to today, for each allocation I got for v4, I'd expect similar out of v6). Sure, the end user gets loads of space with those nice /48's, but the space within ISPs and their ISP customers is force limited by initial allocations which will create fragmentation of address space. This is brought about due to the dual standard of initial vs subsequent allocations (just enough to cover existing vs HD Ratio).
As an example, Using HD-Ratios as an initial assignment metric can warrant a /27, whereas the minimalist approach may only warrant a heavily utilized /30. 3 bits doesn't seem like much, but it's a huge difference in growth room. Bare minimums, as provided by me, only included the /24 IPv4 DHCP pools converted with a raw conversion as /32 IPv4 = /48 IPv6 network
Am I missing something, or is this minimalist approach going to cause issues in BGP the same as v4 did?
Jack
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, yes, it's bad. 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. ARIN, RIPE and AfriNIC, for example, allocate on /29 boundaries. So if you get an initial allocation of /32, then find you need more, your subsequent allocations will be taken from the same /29, allowing aggregation up to /29. APNIC seem to be delegating on /22 boundaries, and LACNIC on /28. Nick
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, those subtending ISPs will end up with multiple networks. Some of them are BGP speakers. I can't use sparse allocation because I was given minimum space and not the HD-Ratio threshold space.
ARIN, RIPE and AfriNIC, for example, allocate on /29 boundaries. So if you get an initial allocation of /32, then find you need more, your subsequent allocations will be taken from the same /29, allowing aggregation up to /29.
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 getting multiple /29's, and not just working within a /27 per the HD-Ratio guidelines. It's the mixed viewpoint that is the problem. HD-Ratio is useless as a justification and as a metric which promotes route conservation/aggregation if it is not used for initial allocations. Initial allocations (including those handed out to subtending ISPs) should all be as large as the immediate use HD Ratio permits. ie, If you are immediately assigning X /56 blocks, your assignment should have a length one less than the highest threshold you crossed. To assign any less is to constrain the assignments, not allow for growth, and to increase routing table size. It also circumvents and completely destroys the concept of HD Ratio (as the initial assignments all are well in excess of the thresholds for requesting much larger blocks). Jack
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 getting multiple /29's, and not just working within a /27 per the HD-Ratio guidelines.
If the policy is broken, then submit a policy proposal to fix it. Nick
----- 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 you are assigning out to subtending ISPs bare minimums, those subtending ISPs will end up with multiple networks. Some of them are BGP speakers. I can't use sparse allocation because I was given minimum space and not the HD-Ratio threshold space.
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 are an ISP? -Randy -- | Randy Carpenter | Vice President, IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (419)739-9240, x1 ----
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 given bare minimums, and you are assigning out to subtending ISPs bare minimums, those subtending ISPs will end up with multiple networks. Some of them are BGP speakers. I can't use sparse allocation because I was given minimum space and not the HD-Ratio threshold space.
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 are an ISP?
-Randy
to my knowledge, RIPE still does not issue ipv6 PI space. so giving them their own space, is "problematic" to say the least. -- Greetings, Sven Olaf Kamphuis, CB3ROB Ltd. & Co. KG ========================================================================= Address: Koloniestrasse 34 VAT Tax ID: DE267268209 D-13359 Registration: HRA 42834 B BERLIN Phone: +31/(0)87-8747479 Germany GSM: +49/(0)152-26410799 RIPE: CBSK1-RIPE e-Mail: sven@cb3rob.net ========================================================================= <penpen> C3P0, der elektrische Westerwelle ========================================================================= Confidential: Please be advised that the information contained in this email message, including all attached documents or files, is privileged and confidential and is intended only for the use of the individual or individuals addressed. Any other use, dissemination, distribution or copying of this communication is strictly prohibited.
On Tue, Oct 26, 2010 at 21:19, Sven Olaf Kamphuis <sven@cb3rob.net> 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 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, those subtending ISPs will end up with multiple networks. Some of them are BGP speakers. I can't use sparse allocation because I was given minimum space and not the HD-Ratio threshold space.
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 are an ISP?
-Randy
to my knowledge, RIPE still does not issue ipv6 PI space. so giving them their own space, is "problematic" to say the least.
I got a /48 PI from RIPE a few months back. Maybe your knowledge needs to be a little bit refreshed regarding RIPE allocation policies :)
On Tue, Oct 26, 2010 at 21:19, Sven Olaf Kamphuis <sven@cb3rob.net> 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 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, those subtending ISPs will end up with multiple networks. Some of them are BGP speakers. I can't use sparse allocation because I was given minimum space and not the HD-Ratio threshold space.
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 are an ISP?
-Randy
to my knowledge, RIPE still does not issue ipv6 PI space. so giving them their own space, is "problematic" to say the least.
I got a /48 PI from RIPE a few months back. Maybe your knowledge needs to be a little bit refreshed regarding RIPE allocation policies :)
Magically, indeed, an ipv6 pi request form showed up in the lirportal. amazing!
On Tue, Oct 26, 2010 at 2:19 PM, Sven Olaf Kamphuis <sven@cb3rob.net> 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 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, those subtending ISPs will end up with multiple networks. Some of them are BGP speakers. I can't use sparse allocation because I was given minimum space and not the HD-Ratio threshold space.
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 are an ISP?
-Randy
to my knowledge, RIPE still does not issue ipv6 PI space. so giving them their own space, is "problematic" to say the least.
ISP's get an LIR assignemnt from RIPE, no? <http://www.ripe.net/ripe/docs/ripe-481.html#lir> Customers could get an end-user assignment (PA space normally or PI) <http://www.ripe.net/ripe/docs/ripe-481.html#_8._IPv6_Provider> (ripe PI assignment policies) -chris
-- Greetings,
Sven Olaf Kamphuis, CB3ROB Ltd. & Co. KG ========================================================================= Address: Koloniestrasse 34 VAT Tax ID: DE267268209 D-13359 Registration: HRA 42834 B BERLIN Phone: +31/(0)87-8747479 Germany GSM: +49/(0)152-26410799 RIPE: CBSK1-RIPE e-Mail: sven@cb3rob.net ========================================================================= <penpen> C3P0, der elektrische Westerwelle
=========================================================================
Confidential: Please be advised that the information contained in this email message, including all attached documents or files, is privileged and confidential and is intended only for the use of the individual or individuals addressed. Any other use, dissemination, distribution or copying of this communication is strictly prohibited.
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 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, those subtending ISPs will end up with multiple networks. Some of them are BGP speakers. I can't use sparse allocation because I was given minimum space and not the HD-Ratio threshold space.
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 are an ISP?
-Randy
to my knowledge, RIPE still does not issue ipv6 PI space. so giving them their own space, is "problematic" to say the least.
RIPE issues PI space in a couple of different forms... 1. Sponsoring LIR can pay 50 Euros/year and subsequently bill the recipient whatever they choose for the PI space. 2. RIPE has always issued PI space to LIRs (ISPs are by definition LIRs). 3. This is NANOG. NA != EU. Owen
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, for one thing because that would violate privacy laws :P do not need to be a LIR, and can just do so on PI space. Shared hosting ISPs also do not make subdelegations and generally don't even uses the ips on a one-specific-customer-per-ip basis. So no, ISP's do not have to be a LIR, and LIRs do not have to be an ISP. (in fact, we are considering moving our LIR activities to a completely seperate legal entity from our internet activities). as a LIR is just a buro that issues IP space and does not nessesarily own or operate a network. -- Greetings, Sven Olaf Kamphuis, CB3ROB Ltd. & Co. KG ========================================================================= Address: Koloniestrasse 34 VAT Tax ID: DE267268209 D-13359 Registration: HRA 42834 B BERLIN Phone: +31/(0)87-8747479 Germany GSM: +49/(0)152-26410799 RIPE: CBSK1-RIPE e-Mail: sven@cb3rob.net ========================================================================= <penpen> C3P0, der elektrische Westerwelle ========================================================================= Confidential: Please be advised that the information contained in this email message, including all attached documents or files, is privileged and confidential and is intended only for the use of the individual or individuals addressed. Any other use, dissemination, distribution or copying of this communication is strictly prohibited. On Tue, 26 Oct 2010, Owen DeLong wrote:
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 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, those subtending ISPs will end up with multiple networks. Some of them are BGP speakers. I can't use sparse allocation because I was given minimum space and not the HD-Ratio threshold space.
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 are an ISP?
-Randy
to my knowledge, RIPE still does not issue ipv6 PI space. so giving them their own space, is "problematic" to say the least.
RIPE issues PI space in a couple of different forms...
1. Sponsoring LIR can pay 50 Euros/year and subsequently bill the recipient whatever they choose for the PI space.
2. RIPE has always issued PI space to LIRs (ISPs are by definition LIRs).
3. This is NANOG. NA != EU.
Owen
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 (as you don't make sub delegations anyway) On Tue, 26 Oct 2010, Sven Olaf Kamphuis wrote:
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, for one thing because that would violate privacy laws :P do not need to be a LIR, and can just do so on PI space.
Shared hosting ISPs also do not make subdelegations and generally don't even uses the ips on a one-specific-customer-per-ip basis.
So no, ISP's do not have to be a LIR, and LIRs do not have to be an ISP. (in fact, we are considering moving our LIR activities to a completely seperate legal entity from our internet activities).
as a LIR is just a buro that issues IP space and does not nessesarily own or operate a network.
-- Greetings,
Sven Olaf Kamphuis, CB3ROB Ltd. & Co. KG ========================================================================= Address: Koloniestrasse 34 VAT Tax ID: DE267268209 D-13359 Registration: HRA 42834 B BERLIN Phone: +31/(0)87-8747479 Germany GSM: +49/(0)152-26410799 RIPE: CBSK1-RIPE e-Mail: sven@cb3rob.net ========================================================================= <penpen> C3P0, der elektrische Westerwelle
=========================================================================
Confidential: Please be advised that the information contained in this email message, including all attached documents or files, is privileged and confidential and is intended only for the use of the individual or individuals addressed. Any other use, dissemination, distribution or copying of this communication is strictly prohibited.
On Tue, 26 Oct 2010, Owen DeLong wrote:
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 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, those subtending ISPs will end up with multiple networks. Some of them are BGP speakers. I can't use sparse allocation because I was given minimum space and not the HD-Ratio threshold space.
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 are an ISP?
-Randy
to my knowledge, RIPE still does not issue ipv6 PI space. so giving them their own space, is "problematic" to say the least.
RIPE issues PI space in a couple of different forms...
1. Sponsoring LIR can pay 50 Euros/year and subsequently bill the recipient whatever they choose for the PI space.
2. RIPE has always issued PI space to LIRs (ISPs are by definition LIRs).
3. This is NANOG. NA != EU.
Owen
On Tue, 26 Oct 2010, George Bonser wrote:
To: Sven Olaf Kamphuis <sven@cb3rob.net>
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?
Legacy ASN assignment? Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony@lava.net
On Tue, Oct 26, 2010 at 14:45, George Bonser <gbonser@seven.com> 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 going to an RIR and paying a fee?
Its not that hard to get an ASN, and all the work can be done by said ISP on behaf of the client, especially many years ago. The extent of one client's knowledge was to turn off a provider router if they were having problems, anything else was handled by us, even with the other ISPs of the client. -Blake
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, Blake Dunlap wrote:
On Tue, Oct 26, 2010 at 14:45, George Bonser <gbonser@seven.com> 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 going to an RIR and paying a fee?
Its not that hard to get an ASN, and all the work can be done by said ISP on behaf of the client, especially many years ago.
The extent of one client's knowledge was to turn off a provider router if they were having problems, anything else was handled by us, even with the other ISPs of the client.
-Blake
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 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?
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 multihome to different AS. Such arrangements are not uncommon. Sprint seems to have done very well selling this sort of near-turnkey service to rural DSL carriers, tiny single town MSOs and the like. --Chris
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 making it hard to leave) maybe we should have made AS numbers 64 bit as well... so there would be one for every /64 end user as for the rest of it: get routers with more ram (i don't want to hear any "my border routers have less than 8GB of ram") arguments, that stuff is -old-, it's got gray hair and a beard and belongs in a museum, not on the internet) The internet will grow, you can't expect it to grow less fast or to "aggregate" routes just because your technically outdated stuff doesn't have enough ram to handle the growing route table size. (preferably offset-based rather than with a sort/lookup mechanism) if a customer has a /64 and wants to announce that /64 himself, i see no reason not to give it to them, especially not if hte only reason would be that some people run still routers that have less ram than my eeepc. (and some suppliers still think that's "OK" to sell) On Tue, 26 Oct 2010, Chris Boyd wrote:
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 multihome to different AS.
Such arrangements are not uncommon. Sprint seems to have done very well selling this sort of near-turnkey service to rural DSL carriers, tiny single town MSOs and the like.
--Chris
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 AS.
Ok, that is where my mental disconnect came from. I saw the word "multihomed" and took that to mean homed to two different providers, not dual connections to the same.
Such arrangements are not uncommon.
Indeed. We do that in a couple of places, too.
A combo WISP and pre-DOCSIS cable system we bought four years ago in a relatively rural area had exactly such a setup with Sprint and UUNet/Verizon/MCI. They had just one T-1 with each provider and a very simple BGP configuration. I just checked, and see that their ASN has been reused. Frank -----Original Message----- From: Chris Boyd [mailto:cboyd@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 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 multihome to different AS. Such arrangements are not uncommon. Sprint seems to have done very well selling this sort of near-turnkey service to rural DSL carriers, tiny single town MSOs and the like. --Chris
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 providers to announce it for them.
If they have an ASN, how did they get it without going to an RIR and paying a fee?
Legacy assignment...acquisition... And maybe they did, but just because they pay their RIR for an ASN doesn't mean they want to step up into the fees and documentation headaches of getting their own space. ($$$$) Some are even singlehomed with an ASN. (I can think of at least two regional providers that had an ASN while being singlehomed because they had downstream BGP speaking customers.) Just because you don't do it, doesn't mean someone else doesn't. It's a big world. --msa
Subject: RE: IPv6 Routing table will be bloated?
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?
Just wanted to note that after exchanging email off list with Jack, I have a better understanding of what he is up against and what he needs makes sense. I retract the "smell test" comment as it was based on my lack of clarity into what exactly the context was. G
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 are an ISP?
Because they are my customer. They don't know much about RIRs, paying membership fees, etc. They just know they want address space, and I provide that. 1) Policy doesn't state that only a RIR can hand address space to an ISP 2) You don't have to be multihomed to be considered an ISP or qualify for space from RIR (you just have to be larger if you aren't multihomed) 3) It has been this way for many years in IPv4, with all of my customers being ISPs from small to medium size and several of them even having their own subtending ISPs (some of which are even larger than my customer ISP in consumer customer counts). Jack
-----Original Message----- From: Jack Bates [mailto:jbates@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:
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 are an ISP?
Because they are my customer. They don't know much about RIRs, paying membership fees, etc. They just know they want address space, and I provide that.
If they are ISPs and don't know much about RIRs, can you please name them and provide their ASNs ... oh, wait ... they won't have an ASN if they don't know about RIRs and fees and such. Something isn't passing the smell test here.
On Tue, Oct 26, 2010 at 14:20, George Bonser <gbonser@seven.com> wrote:
-----Original Message----- From: Jack Bates [mailto:jbates@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 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 are an ISP?
Because they are my customer. They don't know much about RIRs, paying membership fees, etc. They just know they want address space, and I provide that.
If they are ISPs and don't know much about RIRs, can you please name them and provide their ASNs ... oh, wait ... they won't have an ASN if they don't know about RIRs and fees and such.
Something isn't passing the smell test here.
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 small to midsize ISP and their space and assistance to set up. -Blake
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 small to midsize ISP and their space and assistance to set up.
Some aren't multihomed, but they use larger than /20 of v4 space and so still qualify. Others are smaller and multihomed and with my permission (since I configured the BGP for them), use my ASN and routing tricks. Since they have grown this way, they often have no desires to renumber, and most have no desire to even bother with an ASN. However, given the price of an ASN vs price of an ASN and ISP v6 /32; I know exactly which they'll choose. They'll let me pay the higher membership fees, and just get space from me. Jack
Why would the assumption be the ISP = knowledgeable or even caring about RIRs, etc.? When I started my ISP 6 years ago I knew someone issued IP addresses to my upstream provider, but I really didn't care who that was. The upstream took care of everything related to getting and assigning addresses as far as I was concerned. Even when I changed upstream providers they took care of the addresses. It was at that time I realized I need to learn more about the whole IP address assignment process so I wouldn't have to renumber next time I changed providers. I dug far enough to find that my ISP was not big enough to get an assignment and the required fee was more than the cost to renumber, so I didn't look any farther. So, as a log of start-ups and small businesses do, I learned enough to make what I needed work, but not everything that may have been beneficial. On 10/26/2010 3:20 PM, George Bonser wrote:
-----Original Message----- From: Jack Bates [mailto:jbates@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:
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 are an ISP?
Because they are my customer. They don't know much about RIRs, paying membership fees, etc. They just know they want address space, and I provide that. If they are ISPs and don't know much about RIRs, can you please name them and provide their ASNs ... oh, wait ... they won't have an ASN if they don't know about RIRs and fees and such.
Something isn't passing the smell test here.
-- Scott Reed Owner NewWays Networking, LLC Wireless Networking Network Design, Installation and Administration Mikrotik Advanced Certified www.nwwnet.net (765) 855-1060
On Tue, 26 Oct 2010 16:25:39 -0400 Scott Reed <sreed@nwwnet.net> wrote:
Why would the assumption be the ISP = knowledgeable or even caring about RIRs, etc.?
When I started my ISP 6 years ago I knew someone issued IP addresses to my upstream provider, but I really didn't care who that was. The upstream took care of everything related to getting and assigning addresses as far as I was concerned. Even when I changed upstream providers they took care of the addresses. It was at that time I realized I need to learn more about the whole IP address assignment process so I wouldn't have to renumber next time I changed providers. I dug far enough to find that my ISP was not big enough to get an assignment and the required fee was more than the cost to renumber, so I didn't look any farther.
So, as a log of start-ups and small businesses do, I learned enough to make what I needed work, but not everything that may have been beneficial.
So maybe to state the obvious, IPv4 != IPv6, and therefore in Jack's situation something different needs to be done, such as those ISPs learning about RIRs, LIRs etc. sooner rather than later.
On 10/26/2010 3:20 PM, George Bonser wrote:
-----Original Message----- From: Jack Bates [mailto:jbates@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:
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 are an ISP?
Because they are my customer. They don't know much about RIRs, paying membership fees, etc. They just know they want address space, and I provide that. If they are ISPs and don't know much about RIRs, can you please name them and provide their ASNs ... oh, wait ... they won't have an ASN if they don't know about RIRs and fees and such.
Something isn't passing the smell test here.
-- Scott Reed Owner NewWays Networking, LLC Wireless Networking Network Design, Installation and Administration Mikrotik Advanced Certified www.nwwnet.net (765) 855-1060
On Tue, 26 Oct 2010 12:19:30 -0500 Jack Bates <jbates@brightok.net> 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 bare minimums, and you are assigning out to subtending ISPs bare minimums,
Why aren't those subtending ISPs getting their own PI (/32s)?
those subtending ISPs will end up with multiple networks. Some of them are BGP speakers. I can't use sparse allocation because I was given minimum space and not the HD-Ratio threshold space.
ARIN, RIPE and AfriNIC, for example, allocate on /29 boundaries. So if you get an initial allocation of /32, then find you need more, your subsequent allocations will be taken from the same /29, allowing aggregation up to /29.
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 getting multiple /29's, and not just working within a /27 per the HD-Ratio guidelines.
It's the mixed viewpoint that is the problem. HD-Ratio is useless as a justification and as a metric which promotes route conservation/aggregation if it is not used for initial allocations. Initial allocations (including those handed out to subtending ISPs) should all be as large as the immediate use HD Ratio permits. ie, If you are immediately assigning X /56 blocks, your assignment should have a length one less than the highest threshold you crossed. To assign any less is to constrain the assignments, not allow for growth, and to increase routing table size. It also circumvents and completely destroys the concept of HD Ratio (as the initial assignments all are well in excess of the thresholds for requesting much larger blocks).
Jack
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 users. Those are probably served by a /32 for quite some time. When you get into the ones that are 20,000-50,000, it gets tricker to deal with. Those should get a /28. The mega-ISPs should get a /24, or even a /20. Another problem is that the allocations from IANA to the RIRs are too small to begin with. If there are 5 RIRs, why does there have to be so much fragmentation? It is too late for that, though. Anyway, I think there are some proposals floating around (Owen? ;-) ) That would make the /32,/28,/24 (nibble boundary) idea into policy. We'll have to wait and see what happens. -Randy -- | Randy Carpenter | Vice President, IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (419)739-9240, x1 ---- ----- Original Message -----
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, yes, it's bad.
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.
ARIN, RIPE and AfriNIC, for example, allocate on /29 boundaries. So if you get an initial allocation of /32, then find you need more, your subsequent allocations will be taken from the same /29, allowing aggregation up to /29.
APNIC seem to be delegating on /22 boundaries, and LACNIC on /28.
Nick
I think APNIC has a policy that defines the minimum IPv6 allocation based on your current IPv4 allocation/usage. This would fix the problem? ----- Original Message ----- From: "Randy Carpenter" <rcarpen@network1.net> To: "Nick Hilliard" <nick@foobar.org> Cc: nanog@nanog.org Sent: Wednesday, 27 October, 2010 6: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 with many small-ish ISPs, and most are 5,000-10,000 users. Those are probably served by a /32 for quite some time. When you get into the ones that are 20,000-50,000, it gets tricker to deal with. Those should get a /28. The mega-ISPs should get a /24, or even a /20. Another problem is that the allocations from IANA to the RIRs are too small to begin with. If there are 5 RIRs, why does there have to be so much fragmentation? It is too late for that, though. Anyway, I think there are some proposals floating around (Owen? ;-) ) That would make the /32,/28,/24 (nibble boundary) idea into policy. We'll have to wait and see what happens.
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 ~ v6 /32 v4 /12 ~ v6 /28 v4 /8 ~ v6 /24 I know it we don't want to equate v4 and v6, but it may help as a guideline for the size of the customer base. -Randy -- | Randy Carpenter | Vice President, IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (419)739-9240, x1 ---- ----- Original Message -----
I think APNIC has a policy that defines the minimum IPv6 allocation based on your current IPv4 allocation/usage. This would fix the problem?
----- Original Message ----- From: "Randy Carpenter" <rcarpen@network1.net> To: "Nick Hilliard" <nick@foobar.org> Cc: nanog@nanog.org Sent: Wednesday, 27 October, 2010 6: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 with many small-ish ISPs, and most are 5,000-10,000 users. Those are probably served by a /32 for quite some time. When you get into the ones that are 20,000-50,000, it gets tricker to deal with. Those should get a /28. The mega-ISPs should get a /24, or even a /20.
Another problem is that the allocations from IANA to the RIRs are too small to begin with. If there are 5 RIRs, why does there have to be so much fragmentation? It is too late for that, though.
Anyway, I think there are some proposals floating around (Owen? ;-) ) That would make the /32,/28,/24 (nibble boundary) idea into policy. We'll have to wait and see what happens.
Yes indeed, but you don't have to justify much if you only ask for the minimum, if you want more you need to ask... Also, and this I like less, your membership is calculated from the number of IPs you have... I think in short $$=max(1180x1.3(log2(Addresses in /32)-8),Feev6 = 1180x1.3(log2(Addresses in /56)-22) http://www.apnic.net/services/apply-for-resources/check-your-eligibility/che... http://www.apnic.net/services/become-a-member/how-much-does-it-cost ----- Original Message ----- From: "Randy Carpenter" <rcarpen@network1.net> To: "Franck Martin" <franck@genius.com> Cc: nanog@nanog.org, "Nick Hilliard" <nick@foobar.org> 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 ~ v6 /32 v4 /12 ~ v6 /28 v4 /8 ~ v6 /24 I know it we don't want to equate v4 and v6, but it may help as a guideline for the size of the customer base.
It's very interesting to me that wee keep discussing RIRs other than ARIN when talking about allocation policies and issues for NANOG. The NA in NANOG puts the vast majority of it within the ARIN service region. The only other RIR which has territory within NA has not even been mentioned until now and that is LACNIC. (I'm afraid I am not yet familiar with their current IPv6 policies or practices). Owen On Oct 26, 2010, at 3:00 PM, Franck Martin wrote:
Yes indeed, but you don't have to justify much if you only ask for the minimum, if you want more you need to ask...
Also, and this I like less, your membership is calculated from the number of IPs you have... I think in short $$=max(1180x1.3(log2(Addresses in /32)-8),Feev6 = 1180x1.3(log2(Addresses in /56)-22)
http://www.apnic.net/services/apply-for-resources/check-your-eligibility/che... http://www.apnic.net/services/become-a-member/how-much-does-it-cost
----- Original Message ----- From: "Randy Carpenter" <rcarpen@network1.net> To: "Franck Martin" <franck@genius.com> Cc: nanog@nanog.org, "Nick Hilliard" <nick@foobar.org> 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 ~ v6 /32 v4 /12 ~ v6 /28 v4 /8 ~ v6 /24
I know it we don't want to equate v4 and v6, but it may help as a guideline for the size of the customer base.
----- Original Message -----
From: "Owen DeLong" <owen@delong.com> To: "Franck Martin" <franck@genius.com> Cc: "Randy Carpenter" <rcarpen@network1.net>, nanog@nanog.org Sent: Wednesday, 27 October, 2010 11:48:58 AM Subject: Re: IPv6 Routing table will be bloated? It's very interesting to me that wee keep discussing RIRs other than ARIN when talking about allocation policies and issues for NANOG.
The NA in NANOG puts the vast majority of it within the ARIN service region. The only other RIR which has territory within NA has not even been mentioned until now and that is LACNIC. (I'm afraid I am not yet familiar with their current IPv6 policies or practices).
"Cute but not too bright" The Oracle (The Matrix)
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 does not really take into consideration future expansion needs.
I would think that you could draw some parallels, though.
Something like:
v4 /16 ~ v6 /32 v4 /12 ~ v6 /28 v4 /8 ~ v6 /24
I know it we don't want to equate v4 and v6, but it may help as a guideline for the size of the customer base.
I don't think it's a particularly good metric, either, because it doesn't take into account the "conversion rate" of IPv4 to IPv6 addresses, which is wildly different in different networks. Fer instance, $JOB[-1] is a colo/hosting business, with a fair chunk of IPv4 allocated, and the standard IPv6 /32. I did the initial IPv6 address plan, and I'm pretty confident in saying that they'll *never* need any more than that /32 of IPv6, because their business model means that they pack their /64s relatively (hah!) densely (typically there's at least one /24 of IPv4 per /64 of IPv6). However, anyone doing network access is likely to be replacing an IPv4 /32 with an IPv6 /48, which results in a lot more address space usage. Direct conversion between IPv4 and IPv6 will either result in many places being starved of IPv6 (very bad, as the OP of this thread pointed out), or space will be massively overallocated (also, not real hot). - Matt
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 <jcurran@arin.net> Date: October 18, 2010 2:55:49 PM EDT To: David Conrad <drc@virtualized.org> Cc: North American Network Operators Group <nanog@nanog.org> Subject: Re: Definitive Guide to IPv6 adoption - Sparse IPv6 allocation
On Oct 18, 2010, at 2:18 PM, David Conrad wrote:
On Oct 18, 2010, at 6:59 AM, Jack Bates wrote:
ARIN does reservations (unsure at what length, but at least down to /31).
Do they still do that? Back when I was at IANA, one of the justifications the RIRs gave for the /12s they received was that they were going to be using the 'bisection' method of allocation which removes the need for reservation. Last I heard, APNIC was using the bisection method...
ARIN is doing the same (the 'bisection' method) with our IPv6 management since January 2010: we refer to the "sparse allocation" approach and it was requested by the community during the ARIN/NANOG Dearborn meeting.
FYI, /John
John Curran President and CEO ARIN
Begin forwarded message:
From: John Curran <jcurran@arin.net> Date: October 18, 2010 8:14:18 PM EDT To: North American Network Operators Group <nanog@nanog.org> Subject: Re: Definitive Guide to IPv6 adoption - Sparse IPv6 allocation
On Oct 18, 2010, at 3:42 PM, Randy Carpenter wrote:
I have a few customers whose allocations are /29 away from their nearest neighbor (half a nibble). That seems a little close considering there is a lot of talk about doing nibble boundaries, and there doesn't seem to be consensus yet.
For these customers, I don't think they will need more than a /29, but if we collectively decide that a /28 is the next step from a /32, how will the older allocations be dealt with? This is pretty much a rhetorical question at this point, and I suppose the proper thing to do is to channel these questions toward the PPML for discussion as potential policy.
Just for reference regarding existing IPv6 sparse practice:
Our current plan is to use the sparse allocation block (currently a /14) until we fill it up. Bisection done at the /28 boundary which leaves a fairly large reserve.
If an organization needs an allocation larger than a /28, we have set aside a /15 block for those larger ISPs.
The orgs that already have allocations (/32s from /29s) also have a reserve. If they need additional space, they can either request from their /29 reserve, or if they need more than a /29, can request a new block.
Obviously, this can be changed if the community wishes it so. Bring any obvious suggestions to the ARIN suggestion process, and anything which might be contentious or affect allocations to the policy process.
Thanks! /John
John Curran President and CEO ARIN
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 have successfully justified it and you will never ever have to go back to any of the five years. Now what will cause routing bloat is folks who keep on doing the same methods of "load balancing" and "chunking out of PA" and announcing that in BGP. Oh and then there are of course the various organizations who do not know/understand what RPSL is and who do not understand what filtering and aggregation means... Greets, Jeroen
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 have successfully justified it and you will never ever have to go back to any of the five years.
I'd have to lie about existing counts to plan for 5 years. I don't like lying.
Now what will cause routing bloat is folks who keep on doing the same methods of "load balancing" and "chunking out of PA" and announcing that in BGP.
I have customers who use my space and multihome. There is no reason or requirement for them to go to ARIN for this space. They can easily use my own. Ideally they would have (and I would have) large enough space for a single aggregate leaving their network, but with a minimal approach (vs HD-Ratio aligned assignment up front), that won't be possible. Jack
* 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 you need more due to routing, you'll need to provide every pop, counts per pop, etc, to show how v6 will require more than just the minimums (full routing plan and customer counts to justify routing plan).
If you get better routing and reachability from not filtering at the /32 boundary, network operators will stop filtering at the /32 boundary. So this issue will likely go away pretty soon because you can use our initial assignment to gain the routing flexibility you need. -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
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 should go back to ARIN, turn in the lame /32 nonsense they were given (that allocation size is for a startup ISP with 0 customers), follow that with an 'initial allocation' request that is based on your pop structure with a /48 per customer including projected growth. I don't care what you actually allocate to your customers at this point, just get a large enough block to begin with that you could give everyone a /48 the way policy allows. There is absolutely no reason to have to grovel at ARIN's feet every few months as you grow your IPv6 deployment. Get a 'real block' up front. Tony
-----Original Message----- From: Jack Bates [mailto:jbates@brightok.net] Sent: Tuesday, October 26, 2010 6:58 AM To: nanog@nanog.org Subject: IPv6 Routing table will be bloated?
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 you need more due to routing, you'll need to provide every pop, counts per pop, etc, to show how v6 will require more than just the minimums (full routing plan and customer counts to justify routing plan). HD-Ratio has NO bearing on initial allocation, and while policy dictates that it doesn't matter how an ISP assigns to customer so long as HD-Ratio is met, that is not the case when providing justification for the initial allocation.
2) Subsequent requests only double in size according to policy (so just keep going back over and over since HD is met immediately due to the minimalist initial assignment?)
So I conclude that since I get a bare minimum, I can only assign a bare minimum. Since everything is quickly maxed out, I must request more (but only double), which in turn I can assign, but my customer assignments (Telcos/ISPs in this case) will be non-contiguous due to the limited available space I have to hand out. This will lead to IGP bloat, and in cases of multi-homed customers whom I provide address space for, BGP bloat.
I'm small, so my bloat factor is small, but I can quickly see this developing exactly as my v4 network did (if it was years ago when I first got my v4 allocation, growing to today, for each allocation I got for v4, I'd expect similar out of v6). Sure, the end user gets loads of space with those nice /48's, but the space within ISPs and their ISP customers is force limited by initial allocations which will create fragmentation of address space. This is brought about due to the dual standard of initial vs subsequent allocations (just enough to cover existing vs HD Ratio).
As an example, Using HD-Ratios as an initial assignment metric can warrant a /27, whereas the minimalist approach may only warrant a heavily utilized /30. 3 bits doesn't seem like much, but it's a huge difference in growth room. Bare minimums, as provided by me, only included the /24 IPv4 DHCP pools converted with a raw conversion as /32 IPv4 = /48 IPv6 network
Am I missing something, or is this minimalist approach going to cause issues in BGP the same as v4 did?
Jack
Totally agree. In IPv6, polices are in some RIRs and MUST be in all them, balancing conservation and aggregation, but in case of conflict aggregation is the top priority. I can read it at the NRPM: 6.3.8. Conflict of goals The goals described above will often conflict with each other, or with the needs of individual IRs or end users. All IRs evaluating requests for allocations and assignments must make judgments, seeking to balance the needs of the applicant with the needs of the Internet community as a whole. In IPv6 address policy, the goal of aggregation is considered to be the most important. Regards, Jordi
From: Tony Hain <alh-ietf@tndh.net> Reply-To: <alh-ietf@tndh.net> Date: Tue, 26 Oct 2010 09:02:00 -0700 To: 'Jack Bates' <jbates@brightok.net>, <nanog@nanog.org> Subject: RE: IPv6 Routing table will be bloated?
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 should go back to ARIN, turn in the lame /32 nonsense they were given (that allocation size is for a startup ISP with 0 customers), follow that with an 'initial allocation' request that is based on your pop structure with a /48 per customer including projected growth. I don't care what you actually allocate to your customers at this point, just get a large enough block to begin with that you could give everyone a /48 the way policy allows. There is absolutely no reason to have to grovel at ARIN's feet every few months as you grow your IPv6 deployment. Get a 'real block' up front.
Tony
-----Original Message----- From: Jack Bates [mailto:jbates@brightok.net] Sent: Tuesday, October 26, 2010 6:58 AM To: nanog@nanog.org Subject: IPv6 Routing table will be bloated?
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 you need more due to routing, you'll need to provide every pop, counts per pop, etc, to show how v6 will require more than just the minimums (full routing plan and customer counts to justify routing plan). HD-Ratio has NO bearing on initial allocation, and while policy dictates that it doesn't matter how an ISP assigns to customer so long as HD-Ratio is met, that is not the case when providing justification for the initial allocation.
2) Subsequent requests only double in size according to policy (so just keep going back over and over since HD is met immediately due to the minimalist initial assignment?)
So I conclude that since I get a bare minimum, I can only assign a bare minimum. Since everything is quickly maxed out, I must request more (but only double), which in turn I can assign, but my customer assignments (Telcos/ISPs in this case) will be non-contiguous due to the limited available space I have to hand out. This will lead to IGP bloat, and in cases of multi-homed customers whom I provide address space for, BGP bloat.
I'm small, so my bloat factor is small, but I can quickly see this developing exactly as my v4 network did (if it was years ago when I first got my v4 allocation, growing to today, for each allocation I got for v4, I'd expect similar out of v6). Sure, the end user gets loads of space with those nice /48's, but the space within ISPs and their ISP customers is force limited by initial allocations which will create fragmentation of address space. This is brought about due to the dual standard of initial vs subsequent allocations (just enough to cover existing vs HD Ratio).
As an example, Using HD-Ratios as an initial assignment metric can warrant a /27, whereas the minimalist approach may only warrant a heavily utilized /30. 3 bits doesn't seem like much, but it's a huge difference in growth room. Bare minimums, as provided by me, only included the /24 IPv4 DHCP pools converted with a raw conversion as /32 IPv4 = /48 IPv6 network
Am I missing something, or is this minimalist approach going to cause issues in BGP the same as v4 did?
Jack
********************************************** The IPv6 Portal: http://www.ipv6tf.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
participants (24)
-
Antonio Querubin -
Blake Dunlap -
Chris Boyd -
Christopher Morrow -
Eugeniu Patrascu -
Florian Weimer -
Franck Martin -
Frank Bulk - iName.com -
George Bonser -
Jack Bates -
Jeroen Massar -
John Curran -
JORDI PALET MARTINEZ -
Majdi S. Abbas -
Mark Smith -
Matthew Palmer -
Nick Hilliard -
Owen DeLong -
Randy Bush -
Randy Carpenter -
Scott Reed -
Sven Olaf Kamphuis -
TJ -
Tony Hain