Re: Re: What is the most standard subnet length on internet
Suresh, Yes, I guess my concern is close to the second meaning. It seems so simple. Currently annoucement of /24 seems to be okey, most upstream providers accept this. However I wonder if there is any ground rule based on any standard or official recommandation. If there is some standardized rule about prefix length to be annouced, I will make my bgp & IP allocation policy of each data center of my company, and I will be able to more fairly and squarely speak to my customer like this "You have to change your server's IP address if you want move your server to other place" chiyoung ============================================= Chi-Young Joung SAMSUNG NETWORKS Inc. Email: lionair@samsung.com Tel +82 70 7015 0623, Mobile +82 17 520 9193 Fax +82 70 7016 0031 ============================================= ------- Original Message ------- Sender : Suresh Ramasubramanian<ops.lists@gmail.com> Date : 2008-12-19 12:37 (GMT+09:00) Title : Re: What is the most standard subnet length on internet Chi Young, let me clarify one thing here .. Do you mean IP allocation as in subnet allocation, swipping in apnic or through a rwhois server etc? Or do you mean "what is the minimum subnet size I can announce on the internet and have other providers not drop it on the floor"? srs On Fri, Dec 19, 2008 at 8:10 AM, 정치영 <lionair@samsung.com> wrote:
Hi everyone,
I'm going to rebuild IP allocation policy of my company and I am looking for some standard reference for my policy. I have already studied some standard like RFC1518, RIPE181, RFC2050 and I got it is very important to maintain hierachy structure. However, what I am really wondering is what is the most standard subnet length that always can be guaranteed through Internet. less than /24 bit ? I could not find any documents about that, which subnet length is most proper value and pursue internet standard policy ?
In general, announce what you are allocated from the RIR. The minimum allocation from you will see is a /24. A couple examples: http://www.arin.net/reference/ip_blocks.html#ipv4 https://www.ripe.net/ripe/docs/ripe-ncc-managed-address-space.html If you are allocated a /22, announce the /22. Do not announce anything longer unless you have a requirement to (such as a different origin AS). If you are further allocating a subset of that to a downstream, then a /24 out of that is acceptable as the origin will be different. -----Original Message----- From: 정치영 [mailto:lionair@samsung.com] Sent: Thursday, December 18, 2008 20:44 To: Suresh Ramasubramanian Cc: nanog@nanog.org Subject: Re: Re: What is the most standard subnet length on internet Suresh, Yes, I guess my concern is close to the second meaning. It seems so simple. Currently annoucement of /24 seems to be okey, most upstream providers accept this. However I wonder if there is any ground rule based on any standard or official recommandation. If there is some standardized rule about prefix length to be annouced, I will make my bgp & IP allocation policy of each data center of my company, and I will be able to more fairly and squarely speak to my customer like this "You have to change your server's IP address if you want move your server to other place" chiyoung ============================================= Chi-Young Joung SAMSUNG NETWORKS Inc. Email: lionair@samsung.com Tel +82 70 7015 0623, Mobile +82 17 520 9193 Fax +82 70 7016 0031 ============================================= ------- Original Message ------- Sender : Suresh Ramasubramanian<ops.lists@gmail.com> Date : 2008-12-19 12:37 (GMT+09:00) Title : Re: What is the most standard subnet length on internet Chi Young, let me clarify one thing here .. Do you mean IP allocation as in subnet allocation, swipping in apnic or through a rwhois server etc? Or do you mean "what is the minimum subnet size I can announce on the internet and have other providers not drop it on the floor"? srs On Fri, Dec 19, 2008 at 8:10 AM, 정치영 <lionair@samsung.com> wrote:
Hi everyone,
I'm going to rebuild IP allocation policy of my company and I am looking for some standard reference for my policy. I have already studied some standard like RFC1518, RIPE181, RFC2050 and I got it is very important to maintain hierachy structure. However, what I am really wondering is what is the most standard subnet length that always can be guaranteed through Internet. less than /24 bit ? I could not find any documents about that, which subnet length is most proper value and pursue internet standard policy ?
Even if a longer prefix like a /24 is announced, chances of people accepting it is slim. Especially, as you say, if the RIR allocation is something larger than /24 And I have a feeling acceptance /24 route announcements of anything other than legacy classful space, infrastructure space like the root servers is going to be patchy at best. 2008/12/19 Darryl Dunkin <ddunkin@netos.net>:
If you are allocated a /22, announce the /22. Do not announce anything longer unless you have a requirement to (such as a different origin AS). If you are further allocating a subset of that to a downstream, then a /24 out of that is acceptable as the origin will be different.
On Dec 19, 2008, at 12:27 AM, Suresh Ramasubramanian wrote:
Even if a longer prefix like a /24 is announced, chances of people accepting it is slim. Especially, as you say, if the RIR allocation is something larger than /24
And I have a feeling acceptance /24 route announcements of anything other than legacy classful space, infrastructure space like the root servers is going to be patchy at best.
If you are worried about /24s (and I really don't think you need to worry that much), just announce the covering CIDR somewhere and the few places that don't hear the /24 will send packets "at" the shorter prefix. Since routing is hop-based, as soon as the packet reaches an AS that hears the /24, the packet will be forwarded to the correct destination. I know from personal experience this works perfectly well today. But in all seriousness, /24s are close to universally heard. Networks used to filter them, but by and large, they went away or changed their policy. Of course, there are hold-outs, but most corporations which own networks realize that the Internet is a tool to make money, not prove or disprove some random technical argument on NANOG. Listening to /24s make most networks money (either directly by giving them more traffic for which they charge their downstreams, or indirectly by having networks - like mine - stop using them if they don't), ... well, the rest is left as an exercise for the reader. As for routing table size, no router which can handle 10s of Gbps is at all bothered by the size of the global table, so only edge devices or stub networks are in danger of needing to filter /24s. And both of those can (should?) have something called a "default route", making it completely irrelevant whether they hear the /24s anyway. -- TTFN, patrick
2008/12/19 Darryl Dunkin <ddunkin@netos.net>:
If you are allocated a /22, announce the /22. Do not announce anything longer unless you have a requirement to (such as a different origin AS). If you are further allocating a subset of that to a downstream, then a /24 out of that is acceptable as the origin will be different.
As for routing table size, no router which can handle 10s of Gbps is at all bothered by the size of the global table,
... as long as it isn't something like a Cisco Catalyst 6509 with SUP720 and doesn't have a PFC3BXL helping out ... ... or if we conveniently don't classify a Catalyst 65xx as a router because it was primarily intended as a switch, despite how ISP's commonly use them ...
so only edge devices or stub networks are in danger of needing to filter /24s. And both of those can (should?) have something called a "default route", making it completely irrelevant whether they hear the /24s anyway.
A more accurate statement is probably that "any router that can handle 10s of Gbps is likely to be available in a configuration that is not at all bothered by the current size of the global table, most likely at some substantial additional cost." ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
On Dec 19, 2008, at 10:48 AM, Joe Greco wrote:
As for routing table size, no router which can handle 10s of Gbps is at all bothered by the size of the global table,
... as long as it isn't something like a Cisco Catalyst 6509 with SUP720 and doesn't have a PFC3BXL helping out ...
... or if we conveniently don't classify a Catalyst 65xx as a router because it was primarily intended as a switch, despite how ISP's commonly use them ...
so only edge devices or stub networks are in danger of needing to filter /24s. And both of those can (should?) have something called a "default route", making it completely irrelevant whether they hear the /24s anyway.
A more accurate statement is probably that "any router that can handle 10s of Gbps is likely to be available in a configuration that is not at all bothered by the current size of the global table, most likely at some substantial additional cost."
Good point! I should have said "10s of Gbps and tables associated with default-free networks". Or are there lots of people using 6500s without 3BXLs in the DFZ? I admit I have not audited every router in the DFZ, so perhaps someone with factual info can help out here. If not, then we're back to where we started. The DFZ isn't worried about table size this cycle, and the edges can (should?) have default. I'm sure that will change in a couple years, but everything always does. Oh, and before anyone jumps all over me, I am NOT implying you should deaggregate and blow up the table. Just that 300K prefixes is the DFZ is not a reason to start filtering /24s. Today. :) -- TTFN, patrick
Oh, and before anyone jumps all over me, I am NOT implying you should deaggregate and blow up the table. Just that 300K prefixes is the DFZ is not a reason to start filtering /24s. Today. :)
given o ipv4 bits not scaling to internet growth o increase in multi-homing o internet growth nats, siit/nat-pt and ipv4/ipv4 nat will increase combined, this very well may create pressure to globally route longer ipv4 prefixes. randy
Since this old thread recently became alive (momentarily), and I read through the posts, (perhaps, again!) ... Patrick, I would like to understand why you said that routers handling 10G traffic in DFZ are not bothered (much) by a few extra prefixes? Isn't this counter-intuitive? For example, for the worst case packet size of 40 bytes, a router has only 32ns to completely process a packet (including lookup!) in order to support 10Gb/s line rates. The higher rates leave with even smaller time, which makes me think that it's the "slow running" routers that should not be bothered *much* by a small increase in the number of prefixes. Or, were you referring to 10G routers "slow running" by comparing them with 100G routers? I do not except anyone to have such a long memory, so you may want to skim through the following :) Zartash On Sat, Dec 20, 2008 at 9:37 AM, Patrick W. Gilmore <patrick@ianai.net>wrote:
On Dec 19, 2008, at 10:48 AM, Joe Greco wrote:
As for routing table size, no router which can handle 10s of Gbps is
at all bothered by the size of the global table,
... as long as it isn't something like a Cisco Catalyst 6509 with SUP720 and doesn't have a PFC3BXL helping out ...
... or if we conveniently don't classify a Catalyst 65xx as a router because it was primarily intended as a switch, despite how ISP's commonly use them ...
so only edge devices
or stub networks are in danger of needing to filter /24s. And both of those can (should?) have something called a "default route", making it completely irrelevant whether they hear the /24s anyway.
A more accurate statement is probably that "any router that can handle 10s of Gbps is likely to be available in a configuration that is not at all bothered by the current size of the global table, most likely at some substantial additional cost."
Good point! I should have said "10s of Gbps and tables associated with default-free networks".
Or are there lots of people using 6500s without 3BXLs in the DFZ? I admit I have not audited every router in the DFZ, so perhaps someone with factual info can help out here.
If not, then we're back to where we started. The DFZ isn't worried about table size this cycle, and the edges can (should?) have default. I'm sure that will change in a couple years, but everything always does.
Oh, and before anyone jumps all over me, I am NOT implying you should deaggregate and blow up the table. Just that 300K prefixes is the DFZ is not a reason to start filtering /24s. Today. :)
-- TTFN, patrick
On 2008-12-19, at 00:27, Suresh Ramasubramanian wrote:
Even if a longer prefix like a /24 is announced, chances of people accepting it is slim. Especially, as you say, if the RIR allocation is something larger than /24
I think in practice that's over-stating the problem. If an RIR assigns you a /22, the chances are good it has been assigned from some larger block which is also used to assign longer prefixes, down to whatever the RIR's minimum is (e.g. /24 under common critical infrastructure policies). While it's possible to imagine someone re-parsing a full set of all RIR data every day and rolling out martian filters to all border routers based on precisely what assignments have been made, that someone would incur that operational cost in the face of what is a fairly slim benefit seems unlikely. More likely that someone would filter based on the longest assignment made in a particular /8 (e.g. in 202/7, 199/8 we might expect to see / 24s, in 76/8 not so much, etc). Even more likely than that is that people might filter out obvious RFC3330-style martians and permit everything else up to a /24.
And I have a feeling acceptance /24 route announcements of anything other than legacy classful space, infrastructure space like the root servers is going to be patchy at best.
We're both speculating, of course. It'd be nice if some grad student somewhere with friends in the operations community was to experiment with /24s carved out of larger blocks from all over the planet and present some empirical data. Joe
[cf http://www.merit.edu/mail.archives/nanog/msg12684.html and related past threads] On Fri, Dec 19, 2008 at 10:53:48AM -0500, Joe Abley wrote: [snip]
More likely that someone would filter based on the longest assignment made in a particular /8 (e.g. in 202/7, 199/8 we might expect to see / 24s, in 76/8 not so much, etc).
This matches my past experience, and it is often the case that an entity is slow to revist specific /8s when RIR policies change... [snip]
It'd be nice if some grad student somewhere with friends in the operations community was to experiment with /24s carved out of larger blocks from all over the planet and present some empirical data.
We do know that filters come and filters go, and the policies most likely reflect who can afford what level of RIB storage across how large a DFZ folks maintain within their own ASN. I wonder if like hemlines, RIB storage capacity is an indirect economic indicator... In lieu of detailed data reporting, being as conservative as you can about contributing to the mess while being liberal as you can [fit into your budget cycles] in receiving the mess is a long-honoured, functional ops stance. :-) Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE
On Dec 19, 2008, at 10:53 AM, Joe Abley wrote:
It'd be nice if some grad student somewhere with friends in the operations community was to experiment with /24s carved out of larger blocks from all over the planet and present some empirical data.
We don't need a student. We have actual networks doing this every day without any issue, so we know it works. A research project could verify every last corner of the 'Net is accessible to /24s carved out of larger blocks, but the 'corners' tend to be more forgiving of things, it's the people in the "middle" who think they are too big or too important to listen to the little guys which cause problems. Little guys tend to not be so .. uh .. well, you can figure out what I mean. I believe there was a project on reachability of /24s which were _not_ carved out of larger blocks, although I can't find it right now. That might be more interesting. -- TTFN, patrick
Even if a longer prefix like a /24 is announced, chances of people accepting it is slim. Especially, as you say, if the RIR allocation is something larger than /24 And I have a feeling acceptance /24 route announcements of anything other than legacy classful space, infrastructure space like the root servers is going to be patchy at best. 2008/12/19 Darryl Dunkin <ddunkin@netos.net>:
If you are allocated a /22, announce the /22. Do not announce anything longer unless you have a requirement to (such as a different origin AS). If you are further allocating a subset of that to a downstream, then a /24 out of that is acceptable as the origin will be different.
On 19 Dec 2008, at 04:43, 정치영 wrote:
It seems so simple. Currently annoucement of /24 seems to be okey, most upstream providers accept this. However I wonder if there is any ground rule based on any standard or official recommandation.
The only rule is "my network, my rules" ;-) But if general rules did exist, they might say 1) not to announce smaller than a /24 to external parties without agreement, and 2) not to carve up registry assigned address blocks into individual announcements. 1 - You might announce your registry assigned block, AND deaggregated blocks to upstreams or peers for traffic engineering purposes, but you need to work closely with them to make sure that they don't filter the deaggs from your session, and also to make sure they don't onwardly announce the deaggs). 2 - The default free routing table is 270,000 entries large, and this is too big for lots of kit, so networks ARE FILTERING TODAY on registry boundaries. If you don't understand the implications of this do not deaggregate the addresses that the registry assign you. Good luck with your project. Drop me a note offlist if you need specific advice. Andy
On Dec 18, 2008, at 9:43 PM, 정치영 wrote:
Suresh,
Yes, I guess my concern is close to the second meaning.
It seems so simple. Currently annoucement of /24 seems to be okey, most upstream providers accept this. However I wonder if there is any ground rule based on any standard or official recommandation. If there is some standardized rule about prefix length to be annouced, I will make my bgp & IP allocation policy of each data center of my company, and I will be able to more fairly and squarely speak to my customer like this "You have to change your server's IP address if you want move your server to other place"
Some useful guidance is provided here (and in subsequent references) as well: An Architecture for IP Address Allocation with CIDR <http://tools.ietf.org/html/rfc1518> Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy <http://tools.ietf.org/html/rfc1519> Network Renumbering Overview <http://tools.ietf.org/html/rfc2071> A Framework for Inter-Domain Route Aggregation <http://tools.ietf.org/html/rfc2519> HTH, -danny
participants (11)
-
Andy Davidson -
Danny McPherson -
Darryl Dunkin -
Joe Abley -
Joe Greco -
Joe Provo -
Patrick W. Gilmore -
Randy Bush -
Suresh Ramasubramanian -
Zartash Uzmi -
정치영