Re: classful routes redux
On Tue, Nov 08, 2005 at 04:29:18PM +0100, Per Heldal wrote: ... ... which is why I specifically said no intention to ever connect to, or communicates with nodes on, the global network. In which case overlaps in adressblocks are irrelevant, as are any mention of NAT and firewalls as there is no connection (direct or indirect) between the networks. ... (1) Intentions change. As does ownership and therefore required connectivity. (2) Unique name spaces (from IP address or ASN spaces) are also used to verify that there is no leakage between two internets which one desires to keep separate. From a technical point of view, that may be considered a waste of the name spaces that could be used redundantly on both networks; from a security point of view ... it's one way to get the job done. I do think that hundreds of ASNs fall in these categories, I can't guess whether thousands do. -- Joe Yao --- This message is not an official statement of OSIS Center policies.
Re: classful routes redux
This is NOT true. Many ASes explicitly do *NOT* want to send traffic to any other AS. They only want to send traffic to customers, vendors or business partners of some sort. The point I was trying to make is: A site is assigned an AS if it has a network that is connected to the global Internet and wants to send traffic somewhere. (If not, why bother to get an AS?) Many companies get an AS in order to exchange traffic with other companies across an internetwork that IS NOT THE GLOBAL INTERNET!!! There are many internetworks separate from the global Internet. These internetworks carry traffic between many companies using globally unique IP addresses and global unique AS numbers. But these companies do not want any of this traffic to transit any part of the global Internet and they don't want any form of peering with the global Internet. Some people seem to think that IP addresses were created in order to allow people to run networks connected to the global Internet and that ASes were invented in order for such networks to exchange routing policy details on the global Internet. THIS IS *NOT* TRUE! IP (Internetwork Protocol) addresses were created to allow devices to communicate using IP regardless of whether they are all connected to a single global Internet or not. And AS numbers were created to allow IP networks to exchange routing policy details across any IP network, not just the global Internet. RFC1918 IP addresses were set aside for the special case in which someone is building a *PRIVATE* network. Once two organizations interconnect their networks, the two networks are no longer private and must use globally unique addresses to avoid conflicts. Similarly private AS numbers were created for people to build private internetworks such as in a lab environment or at the edge of the global Internet where the private ASes would disappear when routes are aggregated towards the core. But if many companies wish to connect their networks in an internetwork, separate from the global Internet then private AS numbers are required to avoid conflicts. So, to answer your question, Why bother to get an AS?. In order to exchange routing policy details with other organizations on one of the many internetworks that are NOT PART OF THE GLOBAL INTERNET! It is important for RIR policymakers to understand that the RIRs are not managing Internet resources. They are managing IP (Internetwork Protocol) resources that are absolutely essential for ALL users of IP and related protocols. These users may not be part of the Internet but they still have a right to use these resources in order to build their networks. One of the rules in the policies is that the AS is returned when the need disappears. Excellent rule and it should be more widely enforced. I also agree that there are cases where a network is not visible at all on the Internet and a private AS cannot be used. However, I do not believe that these cases account for 1/3 of the AS out there. I agree. I would guess that there are no more than a few hundred ASes in use on private internetworks. So that still leaves almost 10,000 ASes that could be recovered and reused. On the other hand, it may be cheaper in the long run to just go to a 4-byte AS number and forget about lost AS numbers entirely. Is waste really a relevant word when we have IPv6 and 4-byte ASNs on the horizon? --Michael Dillon
Re: classful routes redux
On Tue, 2005-11-08 at 10:46 +, [EMAIL PROTECTED] wrote: This is NOT true. Many ASes explicitly do *NOT* want to send traffic to any other AS. They only want to send traffic to customers, vendors or business partners of some sort. The point I was trying to make is: A site is assigned an AS if it has a network that is connected to the global Internet and wants to send traffic somewhere. (If not, why bother to get an AS?) Many companies get an AS in order to exchange traffic with other companies across an internetwork that IS NOT THE GLOBAL INTERNET!!! There are many internetworks separate from the global Internet. These internetworks carry traffic between many companies using globally unique IP addresses and global unique AS numbers. But these companies do not want any of this traffic to transit any part of the global Internet and they don't want any form of peering with the global Internet. Some people seem to think that IP addresses were created in order to allow people to run networks connected to the global Internet and that ASes were invented in order for such networks to exchange routing policy details on the global Internet. THIS IS *NOT* TRUE! IP (Internetwork Protocol) addresses were created to allow devices to communicate using IP regardless of whether they are all connected to a single global Internet or not. And AS numbers were created to allow IP networks to exchange routing policy details across any IP network, not just the global Internet. You need to separate technology from implementation. Anybody is free to use IP-technology to build their own network for which they define their own policies. What you refer to as the global internet is just one particular implementation with resource-allocation-policies decided by its users. With no shortage of resources (in this case AS-numbers and IP-addresses) we wouldn't have this discussion. Then nobody would care how an organisation is using the resources that are allocated to them. Resource-allocation across separate administrative domains doesn't work when there's a shortage. *If* that happens private networks may need to establish their own registry for private ipv4 resources overlapping with the global internet, so that those resources can be re-used. RFC1918 IP addresses were set aside for the special case in which someone is building a *PRIVATE* network. Once two organizations interconnect their networks, the two networks are no longer private and must use globally unique addresses to avoid conflicts. Similarly private AS numbers were created for people to build private internetworks such as in a lab environment or at the edge of the global Internet where the private ASes would disappear when routes are aggregated towards the core. But if many companies wish to connect their networks in an internetwork, separate from the global Internet then private AS numbers are required to avoid conflicts. So, to answer your question, Why bother to get an AS?. In order to exchange routing policy details with other organizations on one of the many internetworks that are NOT PART OF THE GLOBAL INTERNET! Nobody is questioning the advantages of globally unique identifiers. However, administrative resources for the internet are primarily ment to serve the public. If or when there's a shortage of resources, private network may have to accept to administer their resources separately. There is technically no need for these networks to share resources with the global internet if they have no intention to ever connect to, or communicates with nodes on, the global network. It is important for RIR policymakers to understand that the RIRs are not managing Internet resources. They are managing IP (Internetwork Protocol) resources that are absolutely essential for ALL users of IP and related protocols. These users may not be part of the Internet but they still have a right to use these resources in order to build their networks. Wrong. RIRs have no authority outside the resources they've been assigned from the global pool, and certainly not over networks not connected to the global internet. RIR's are (as anybody else) free to take part in the process of developing global policies. Anybody is free to build their own separate networks and use IP-technology as they want, but internet registries have no obligation to administer their resources. //Per
Re: classful routes redux
With no shortage of resources (in this case AS-numbers and IP-addresses) we wouldn't have this discussion. Then nobody would care how an organisation is using the resources that are allocated to them. Thankfully there is no shortage of IP addresses and there will be no shortage of AS numbers. The factory has already ramped up production of IPv6 addresses and warehouses are full. Designs for the new version AS numbers are just about past engineering review and the factory is ready to begin production. Nobody is questioning the advantages of globally unique identifiers. However, administrative resources for the internet are primarily ment to serve the public. And the public *IS* being served by the diversity of applications and networks which use the Internet Protocol. The public is served regardless of whether the device is on a private network, the global Internet or some other internet. There is technically no need for these networks to share resources with the global internet if they have no intention to ever connect to, or communicates with nodes on, the global network. This is where you are wrong. Primarily this is because firewalls make it possible for organizations to run a network which connects to BOTH the global Internet and one or more private Internets without allowing any traffic to transit between these networks or any routing information to leak between these networks. Nevertheless, the network in the middle needs to use globally unique addresses and both RFC 1918 and RFC 2050 explicitly account for such networks. If a network interconnects with other networks it is *NOT a private network and therefore it requires globally unique identifiers. Wrong. RIRs have no authority outside the resources they've been assigned from the global pool, and certainly not over networks not connected to the global internet. RIR's are (as anybody else) free to take part in the process of developing global policies. RIRs have no authority over networks connected to the global Internet either. RIRs are part of a system of self-regulation, not government regulation, and therefore have no authority other than the consent of their members. Anybody is free to build their own separate networks and use IP-technology as they want, but internet registries have no obligation to administer their resources. You seem to think that the Internet was created before there were nascent RIRs managing internet numbering. It was the other way around. Right from the beginning when IP, the internetwork protocol, was designed, there was an understanding of the need to COORDINATE numbering resources. After a while, so many of the young internetworks connected together that people started to think and speak of one single global Internet. This is a nice result but IP does not belong to *ONLY* those organizations who connect to the global Internet. It is more general than that. Even though the Internet is the major revenue source for most of the companies in which NANOG members work, these companies also operate important IP networks which are *NOT* the Internet. It is important to remember this, especially when talking about ARIN and other RIRs, ICANN, the IETF, etc. None of these organizations serve the global Internet exclusively. They serve the body of protocols which make the Internet, and other internets, possible. --Michael Dillon
Re: classful routes redux
On Tue, 2005-11-08 at 14:48 +, [EMAIL PROTECTED] wrote: With no shortage of resources (in this case AS-numbers and IP-addresses) we wouldn't have this discussion. Then nobody would care how an organisation is using the resources that are allocated to them. Thankfully there is no shortage of IP addresses and there will be no shortage of AS numbers. The factory has already ramped up production of IPv6 addresses and warehouses are full. Designs for the new version AS numbers are just about past engineering review and the factory is ready to begin production. Nobody is questioning the advantages of globally unique identifiers. However, administrative resources for the internet are primarily ment to serve the public. And the public *IS* being served by the diversity of applications and networks which use the Internet Protocol. The public is served regardless of whether the device is on a private network, the global Internet or some other internet. There is technically no need for these networks to share resources with the global internet if they have no intention to ever connect to, or communicates with nodes on, the global network. This is where you are wrong. Primarily this is because firewalls make it possible for organizations to run a network which connects to BOTH the global Internet and one or more private Internets without allowing any traffic to transit between these networks or any routing information to leak between these networks. Nevertheless, the network in the middle needs to use globally unique addresses and both RFC 1918 and RFC 2050 explicitly account for such networks. If a network interconnects with other networks it is *NOT a private network and therefore it requires globally unique identifiers. ... which is why I specifically said no intention to ever connect to, or communicates with nodes on, the global network. In which case overlaps in adressblocks are irrelevant, as are any mention of NAT and firewalls as there is no connection (direct or indirect) between the networks. Wrong. RIRs have no authority outside the resources they've been assigned from the global pool, and certainly not over networks not connected to the global internet. RIR's are (as anybody else) free to take part in the process of developing global policies. RIRs have no authority over networks connected to the global Internet either. RIRs are part of a system of self-regulation, not government regulation, and therefore have no authority other than the consent of their members. Authority wasn't the right word perhaps ;) Operating context may be a better term. Anybody is free to build their own separate networks and use IP-technology as they want, but internet registries have no obligation to administer their resources. You seem to think that the Internet was created before there were nascent RIRs managing internet numbering. Nope, when I started networking there was no global network worth connecting to and sna, decnet or ipx nodes worldwide outnumbered ip by 1000 to one or more. RFC1918 wasn't even on the horizon and there were lots of ad-hoc built IP networks using randomly selected addresses. Internet governance was handled by handful of people in IANA. It was the other way around. Right from the beginning when IP, the internetwork protocol, was designed, there was an understanding of the need to COORDINATE numbering resources. After a while, so many of the young internetworks connected together that people started to think and speak of one single global Internet. This is a nice result but IP does not belong to *ONLY* those organizations who connect to the global Internet. It is more general than that. Sure, and that's why you need to separate between the technology administered through the IETF and *one* particular implementation of it which happen to be coordinated by a hierarchy of organisations under the ICANN-umbrella. Those who don't want to take part in this hierarchy or communicate with it's network are free to organise their own in whatever way they please. Even though the Internet is the major revenue source for most of the companies in which NANOG members work, these companies also operate important IP networks which are *NOT* the Internet. It is important to remember this, especially when talking about ARIN and other RIRs, ICANN, the IETF, etc. None of these organizations serve the global Internet exclusively. They serve the body of protocols which make the Internet, and other internets, possible. technology != implementation //Per
Re: classful routes redux
... which is why I specifically said no intention to ever connect to, or communicates with nodes on, the global network. In which case overlaps in adressblocks are irrelevant, as are any mention of NAT and firewalls as there is no connection (direct or indirect) between the networks. The only case that I am aware of where there is truly *NO* intention to ever connect to the global Internet is military networks. When I was referring to other internets I did not have military networks in mind. In every other case that I am aware of, the partcipants in the internet also maintain connectivity to the Internet via alternate paths. --Michael Dillon
Re: classful routes redux
Thus spake [EMAIL PROTECTED] ... which is why I specifically said no intention to ever connect to, or communicates with nodes on, the global network. In which case overlaps in adressblocks are irrelevant, as are any mention of NAT and firewalls as there is no connection (direct or indirect) between the networks. The only case that I am aware of where there is truly *NO* intention to ever connect to the global Internet is military networks. When I was referring to other internets I did not have military networks in mind. In every other case that I am aware of, the partcipants in the internet also maintain connectivity to the Internet via alternate paths. I've personally dealt with private networks that had no intent of ever connecting to the Internet, though they were connected to other internal networks that did have such connectivity and to business partners (over private links) that probably did as well. One I still have nightmares about was a mess of eight (yes, eight) instances of 10/8 which were dynamically NATed to class B addresses to reach common servers and for communication to various partners, with a few tens of thousands of static NAT entries for devices that needed to be polled. I suppose if those private networks had had a default route (they didn't) and there were no firewalls in the way (there were) they could have reached the Internet, but at the time it was designed there was no intent to ever allow such. Too bad the equipment we had to support didn't understand IPv6, or we could have gotten away with using the site-local prefix (or, later, ULAs) and no NAT at all. S Stephen SprunkStupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them. --Aaron Sorkin
Re: classful routes redux
What about those that are assigned and used but not [currently] visible on the public Internet [i.e., are on other internets]? Indeed! On Henk's slide number 5 he states: Each AS wants to be able to send traffic to any other AS This is NOT true. Many ASes explicitly do *NOT* want to send traffic to any other AS. They only want to send traffic to customers, vendors or business partners of some sort. In other words, there are many so-called extranets which are basically internets built using exactly the same technology as the Internet however with more restrictive interconnect policies. One way to visualize this is to imagine the Internet as a cloud. At the core of the cloud are the core providers and at the edge of the cloud are the end user organizations, many of which appear to be singly homed. However, hidden behind this edge is a thin layer which represents a private internet. It also connects many networks but it does *NOT* exchange traffic with the public Internet. All the networks connected to these private internets are also connected to the public Internet but they implement strict traffic separation policies internally. In some cases, this is an air gap but these days it is often a bunch of firewalls. In the 24/7 connected world of the 21st century there is a lot of growth in these internets that wrap around the Internet but don't exchange vital fluids with it. --Michael Dillon
Re: classful routes redux
On 7-Nov-2005, at 05:57, [EMAIL PROTECTED] wrote: On Henk's slide number 5 he states: Each AS wants to be able to send traffic to any other AS This is NOT true. Many ASes explicitly do *NOT* want to send traffic to any other AS. Wanting to do something and wanting to be able to do something are different.
Re: classful routes redux
Thus spake [EMAIL PROTECTED] One way to visualize this is to imagine the Internet as a cloud. At the core of the cloud are the core providers and at the edge of the cloud are the end user organizations, many of which appear to be singly homed. However, hidden behind this edge is a thin layer which represents a private internet. It also connects many networks but it does *NOT* exchange traffic with the public Internet. All the networks connected to these private internets are also connected to the public Internet but they implement strict traffic separation policies internally. In some cases, this is an air gap but these days it is often a bunch of firewalls. And let's not forget that various parts of that thin layer connect to each other in something approaching a partial mesh with no transitive reachability. While I doubt that it's anywhere near enough to account for all the MIA ASNs, nor do we have any way of knowing for sure, but many of those folks cannot get by with private ASNs for those networks for the same reason they can't use RFC1918 space. Others give in and use static routes and double-NATs. S Stephen SprunkStupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them. --Aaron Sorkin
Re: classful routes redux
At 11:57 07/11/2005, [EMAIL PROTECTED] wrote: What about those that are assigned and used but not [currently] visible on the public Internet [i.e., are on other internets]? Indeed! On Henk's slide number 5 he states: Each AS wants to be able to send traffic to any other AS This is NOT true. Many ASes explicitly do *NOT* want to send traffic to any other AS. They only want to send traffic to customers, vendors or business partners of some sort. You are right, but this was not the point I was trying to make on this slide. The point I was trying to make is: A site is assigned an AS if it has a network that is connected to the global Internet and wants to send traffic somewhere. (If not, why bother to get an AS?) One of the rules in the policies is that the AS is returned when the need disappears. So, very naively, I'd think that for each assigned AS there is at least one path announcing the address space in that AS to somebody else. I immediately agree that there are cases where an AS does not want to send traffic to another AS, or prefers not to use a path even though it is available. I also agree that there are cases where a network is not visible at all on the Internet and a private AS cannot be used. However, I do not believe that these cases account for 1/3 of the AS out there. Henk In other words, there are many so-called extranets which are basically internets built using exactly the same technology as the Internet however with more restrictive interconnect policies. One way to visualize this is to imagine the Internet as a cloud. At the core of the cloud are the core providers and at the edge of the cloud are the end user organizations, many of which appear to be singly homed. However, hidden behind this edge is a thin layer which represents a private internet. It also connects many networks but it does *NOT* exchange traffic with the public Internet. All the networks connected to these private internets are also connected to the public Internet but they implement strict traffic separation policies internally. In some cases, this is an air gap but these days it is often a bunch of firewalls. In the 24/7 connected world of the 21st century there is a lot of growth in these internets that wrap around the Internet but don't exchange vital fluids with it. --Michael Dillon -- Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The NetherlandsThe NetherlandsMobile: +31.6.55861746 -- Look here junior, don't you be so happy. And for Heaven's sake, don't you be so sad. (Tom Verlaine)
Re: classful routes redux
On Mon, Nov 07, 2005 at 09:33:30PM +0100, Henk Uijterwaal wrote: At 11:57 07/11/2005, [EMAIL PROTECTED] wrote: What about those that are assigned and used but not [currently] visible on the public Internet [i.e., are on other internets]? Indeed! On Henk's slide number 5 he states: Each AS wants to be able to send traffic to any other AS This is NOT true. Many ASes explicitly do *NOT* want to send traffic to any other AS. They only want to send traffic to customers, vendors or business partners of some sort. You are right, but this was not the point I was trying to make on this slide. The point I was trying to make is: A site is assigned an AS if it has a network that is connected to the global Internet and wants to send traffic somewhere. (If not, why bother to get an AS?) ... ... Because it is connected to a DIFFERENT internet and wants to send traffic somewhere. My point was that the slide makes it sound like it covers ALL ASNs [as does your text, above], and there is AT LEAST one other possibility. -- Joe Yao --- This message is not an official statement of OSIS Center policies.
Re: classful routes redux
On Wed, Nov 02, 2005 at 04:14:31PM -0800, Bill Woodcock wrote: On Wed, 2 Nov 2005, Fred Baker wrote: While I think /32, /48, /56, and /64 are reasonable prefix lengths for what they are proposed for, I have this feeling of early fossilization when it doesn't necessarily make sense. Yeah, that's what seems important to me here... I mean, I've lived through the whole classful thing once... I'm still not clear why there are people who want to do it again. Well to be fair, classful routing actually did have a few advantages. Longest prefix match lookups have historically always been very difficult, so difficult that it held back the speed of routers for years. We've only recently been able to get a handle on the problem in hardware. Also, some of the original motivations behind CIDR starts to go out the window when you have enough IP space that you can hand out huge chunks ahead of immediate need. Who cares about efficient utilization or but I only need a /35 and you gave me a whole /32, I'm wasting so much space when there is not a space shortage. Just allocate enough space that you will never need to upgrade, you'll be doing more good than trying to predict or restrict your usage and creating more routing entries later when you need more space. Of course none of this is a compelling argument for classful routing. We've pretty much got the longest prefix match thing covered at this point, and claims that we need to scale bgp to support 2^128 routes so that everyone can multihome their refrigerators are a load of crap. Also, just because 2^128 is a big number does not mean that all IPv6 space is infinite, and there is no reason to get short-sighted. If we're really going to end up in a situation where a /64 is a host, then a /48 is the equivilent of a /16 on IPv4. That is a decent sized chunk for small users, but hardly infinite. If you are a larger provider with a /32 and you have to hand out /48s to everyone, it is like only having a /16 yourself. Imagine a large cable company who had to give an IP to every customer and trying to get it all done in a single /16. Suddenly all this massive space seems to be running low. /56s and the like as allocations seem like a really bad and short-sighted idea, unless we're talking about it for nothing more than business-class end-user service like a /27 on a business grade DSL circuit today. I'm still not seeing any reason that everything can't work itself out through existing means. Make the preferred allocation size from RIRs /32, to be given out to large networks or anyone with an ASN who asks for one. Make the preferred reallocation size for enterprises /48, and make it the smallest block which can be announced in BGP (with the expectation that /32s will be the primary announcement). Make the preferred assignment for end-users (cable modems and such) /64, and use the remaining 64 bits as a giant waste of time but one that makes certain we won't have to deal with NAT ever again. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: classful routes redux
Also, some of the original motivations behind CIDR starts to go out the window when you have enough IP space that you can hand out huge chunks ahead of immediate need. Who cares about efficient utilization or but I only need a /35 and you gave me a whole /32, I'm wasting so much space when there is not a space shortage. Just allocate enough space that you will never need to upgrade, you'll be doing more good than trying to predict or restrict your usage and creating more routing entries later when you need more space. The original motivation behind this conversation stems from some long held concerns that the address plan for IPv6 may not encompass our visions of a network that serves a device dense world for many decades to come. http://www.potaroo.net/ispcol/2005-07/ipv6size.html contains one description of this concern. At issue here is two somewhat different views of the deployment scenarios of the network. One view is to attempt to use the larger address space to make deployment incredibly simple, and eliminate some of the overhead we have in IPv4 in our efforts to make the IPv4 address space last. So the IPv6 address plan says /48's to end sites with no assessment of end-site address utilization. The IPv6 address policy says use an HD Ratio of 0.8 to assess the requirement for additional address allocations. The IPv6 address policy says use a minimum initial allocation of a /32. In looking at these parameters, and making some pretty rough calculations of what a device-dense world would look like then it would appear that this plan would work for an end site population of between 50 to 200 billion, which would fit within this address plan - not comfortably, but it would fit. What if we have underestimated this population? In this view, the resolution is best expressed in RFC3177: Therefore, if the analysis does one day turn out to be wrong, our successors will still have the option of imposing much more restrictive allocation policies The other view is that by then the installed base will be so large (up to tens of billions of end sites) that any form of adjustment of the IPv6 address space will be extremely difficult, if not impossible. Within this view, the motivation is to set up an address plan that encompasses a margin for error in our assessments of future IPv6 network address requirements, while attempting to preserve as much of the essential elements of simplicity in the address plan as possible. To this end policy proposals to adjust the HD ratio to 0.94 have been proposed in APNIC, ARIN and RIPE this year, and the reaction from the addressing communities to this proposal have been largely positive. But there is still the lingering doubt (at least personally) that we really don't know how big and for how long we need to rely on IPv6, and the 3 bits (factor of 1 order of magnitude) you are likely to get from this HD ratio may not be enough. From this doubt came the second part of the proposal to define a second end site allocation point, namely that of a /56. This part of the proposal was not well received by any of these three policy fora. The reaction that this /56 end site allocation point has received has been twofold ; one that it impacts the existing deployed base of IPv6, and secondly, and perhaps more fundamentally, its not the RIR's role to define what an end-site allocation may be within any particular ISP, and this definition of /48, /56 and /64 looks very reminiscent of the old Class-full address plan of IPv4 over a decade ago. So it appears that this approach of simply defining another end-site allocation point does not have broad acceptance, and there is a clear message to go back and think some more about what is the issue here and how best to address it. The real issue here is NOT the definition of allocation points per se. The address plan used by an ISP ultimately falls within the business scope of the ISP itself. The central issue, if you accept that premise that end-site allocations are up to the ISPs, is how to define the algorithm to be used by the RIR to assess whether an existing allocation has been fully utilized in terms of end-site address allocations. So what algorithm could be used to assess address utilization in a manner that would provide _reasonable_ incentives to use the address space in a manner that preserves IPv6's future utility across many decades to come (and encompasses a pretty large margin for error in our very imperfect views of the future)? For me that's at the heart of this discussion, and of course I'd be very interested to hear what ideas others may have on this topic. regards, Geoff
Re: classful routes redux
At 03:09 AM 5/11/2005, Christopher L. Morrow wrote: On Fri, 4 Nov 2005, Russ White wrote: - -- BGP is currently moving to a 2^32 space for AS numbers. That's odd, if there's only 18,044 origins in the current table, and it won't ever grow to much more--how'd we lose 40,000 or so AS numbers, that we now need more than 64,000? I think someone at CAIDA or even Renesys could put out some good numbers for 'origin' AS counts and even 'AS in aspath' It's slightly higher than 18k, but not 40k higher :) At last look (during arin/nanog meeting) it was about 20k unique origins (from 701 perspective as seen through routeviews) As of a few minutes ago there are 21.042 unique ASs seen in Route-Views. 13,997 are origin onlu (i.e. they are not seen in the middle of an AS path), 66 are transit only and 6.979 are mixes origin + transit. 8,554 ASs announce a single prefix, while the average announcements per origin AS is 9.1 (the reason is a heavy tail distribution where a small number of ASs originate a very large number of prefixes) The average address span for an origin AS is 70,426 /32s (or slightly larger than a /16) Again this is a heavy tail distribution. (more time series data on the routing table than you'd ever want is at http://bgp.potaroo.net/as4637/ and http://bgp.potaroo.net/as6447) The overall trend is the association of fewer addresses per originating AS, pointing to a trend to impose ever finer levels of policy delineation within the inter-domain routing mesh at places closer to the edge of the network - i.e. multi-homing and traffic engineering within an increasingly dense interconnection mesh appear to be one of the major motivations here for the continued consumption of AS numbers. The CAIDA skitter graphs are perhaps the most dramatic way I've encountered so far that clearly shows this trend. regards Geoff
Re: classful routes redux
Hello; On Nov 5, 2005, at 12:01 PM, Geoff Huston wrote: At 03:09 AM 5/11/2005, Christopher L. Morrow wrote: On Fri, 4 Nov 2005, Russ White wrote: - -- BGP is currently moving to a 2^32 space for AS numbers. That's odd, if there's only 18,044 origins in the current table, and it won't ever grow to much more--how'd we lose 40,000 or so AS numbers, that we now need more than 64,000? I think someone at CAIDA or even Renesys could put out some good numbers for 'origin' AS counts and even 'AS in aspath' It's slightly higher than 18k, but not 40k higher :) At last look (during arin/nanog meeting) it was about 20k unique origins (from 701 perspective as seen through routeviews) As of a few minutes ago there are 21.042 unique ASs seen in Route- Views. From the multicast status page, http://www.multicasttech.com/status/ I get a total number of Active Unicast AS seen by BGP = 20660 (a little smaller than Route-Views), and a total of 22038 having _ever_ been seen by BGP announcements here (since April, 2001). There are clearly more AS's in use out there in non-public networks, as seen, e.g., by the steady dribble of low number DOD ASN's that leak out from time to time, but it does not seem that this pool is very large. Regards Marshall Eubanks 13,997 are origin onlu (i.e. they are not seen in the middle of an AS path), 66 are transit only and 6.979 are mixes origin + transit. 8,554 ASs announce a single prefix, while the average announcements per origin AS is 9.1 (the reason is a heavy tail distribution where a small number of ASs originate a very large number of prefixes) The average address span for an origin AS is 70,426 /32s (or slightly larger than a /16) Again this is a heavy tail distribution. (more time series data on the routing table than you'd ever want is at http://bgp.potaroo.net/as4637/ and http://bgp.potaroo.net/as6447) The overall trend is the association of fewer addresses per originating AS, pointing to a trend to impose ever finer levels of policy delineation within the inter-domain routing mesh at places closer to the edge of the network - i.e. multi-homing and traffic engineering within an increasingly dense interconnection mesh appear to be one of the major motivations here for the continued consumption of AS numbers. The CAIDA skitter graphs are perhaps the most dramatic way I've encountered so far that clearly shows this trend. regards Geoff
Re: classful routes redux
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 A routing table capable of handling a flat 2^128 addressing space goes beyond the realm of known physics -- and flat 2^64 comes close, at least for a while (consider semiconductor atomic weights, and the fact that 1 mole is approximately 2^79 atoms). That's quite a stretch, but should give a hint as to why flat addressing does not work for every model. Come on now, a lot of new routing gear made today can just barely handle 2^18 routes, and even the high end stuff tops out at 2^20. We're nowhere near handling 2^32 routes even for IPv4, nor should we be, so lets not start the whole but ipv6 has more space therefore routes will increase to 7873289439872361837492837493874982347932847329874293874 nonsense again. Removing the extreme restrictions on IP space allocation by being able to allocate chunks so large that you would RARELY need to go back for a second block would immediate reduce the size of the routing table. Let me state the stats again for the record: Total ASes present in the Internet Routing Table: 20761 Origin-only ASes present in the Internet Routing Table: 18044 Origin ASes announcing only one prefix:8555 Transit ASes present in the Internet Routing Table:2717 There are just not that many distinct BGP speaking networks out there, nor will there ever be. NOW is the time to make certain that IPv6 deployments makes sense in practice and not just in theory, so we don't work ourselves into exactly the same mess that we did in IPv4. Lets stop trying to solve theoretical scaling problems which will never happen at the expense of creating problems which actually DO exist, and apply a little bit of common sense. whilst i'm at the mic here, ditch the idea of microassignments, just give out a standard /32 block ... lets not start out with ge 33 prefixes in the table when theres no need Hmmm Some interesting points: - -- 2^32 is still larger than 2^20, which is claimed to be the largest feasible size, above. - -- BGP is currently moving to a 2^32 space for AS numbers. That's odd, if there's only 18,044 origins in the current table, and it won't ever grow to much more--how'd we lose 40,000 or so AS numbers, that we now need more than 64,000? Just curious. :-) Russ - -- [EMAIL PROTECTED] CCIE Grace Alone -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.0.2 (Build 2424) iQA/AwUBQ2trGREdu7FIVPTkEQI5RQCg+Ol1jrkvldeC5ao403Yw4WiiabgAnj1K KXBXTIBh9R7kDIDBWGooPxdQ =i+AJ -END PGP SIGNATURE-
Re: classful routes redux
On 4-Nov-2005, at 09:07, Russ White wrote: - -- BGP is currently moving to a 2^32 space for AS numbers. That's odd, if there's only 18,044 origins in the current table, and it won't ever grow to much more--how'd we lose 40,000 or so AS numbers, that we now need more than 64,000? http://www.nanog.org/mtg-0510/huston.as.html http://www.nanog.org/mtg-0510/wilhelm.html Joe
Re: classful routes redux
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joe Abley wrote: On 4-Nov-2005, at 09:07, Russ White wrote: - -- BGP is currently moving to a 2^32 space for AS numbers. That's odd, if there's only 18,044 origins in the current table, and it won't ever grow to much more--how'd we lose 40,000 or so AS numbers, that we now need more than 64,000? http://www.nanog.org/mtg-0510/huston.as.html http://www.nanog.org/mtg-0510/wilhelm.html From the second source: If all these unused ASNs could be recovered, the pool of ASNs would last until 2025 to 2030. So, if we think that 2^32 is ultimately unobtainable, we're just facing a deadline with 2^32's being the norm per AS of a few years longer. Of course, this doesn't even answer the question of how to get from 2^18 currently, to 2^32 in the first place. :-) Russ - -- [EMAIL PROTECTED] CCIE Grace Alone -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.0.2 (Build 2424) iQA/AwUBQ2t4+xEdu7FIVPTkEQIGUACfXDFqrwMY08f2ow+YeyafOoIVSG8AnRp0 hPXzjJt87XUCJ1mrfSDJr9o+ =ZRk5 -END PGP SIGNATURE-
Re: classful routes redux
On Fri, 4 Nov 2005, Russ White wrote: - -- BGP is currently moving to a 2^32 space for AS numbers. That's odd, if there's only 18,044 origins in the current table, and it won't ever grow to much more--how'd we lose 40,000 or so AS numbers, that we now need more than 64,000? I think someone at CAIDA or even Renesys could put out some good numbers for 'origin' AS counts and even 'AS in aspath' It's slightly higher than 18k, but not 40k higher :) At last look (during arin/nanog meeting) it was about 20k unique origins (from 701 perspective as seen through routeviews)
Re: classful routes redux
On Fri, Nov 04, 2005 at 09:57:14AM -0500, Joe Abley wrote: On 4-Nov-2005, at 09:07, Russ White wrote: - -- BGP is currently moving to a 2^32 space for AS numbers. That's odd, if there's only 18,044 origins in the current table, and it won't ever grow to much more--how'd we lose 40,000 or so AS numbers, that we now need more than 64,000? http://www.nanog.org/mtg-0510/huston.as.html http://www.nanog.org/mtg-0510/wilhelm.html Per the latter - ... We show that this is due to two effects: (1) ASNs which are assigned based on future plans but never used in practice, and (2) ASNs which are no longer in use but not returned to the RIRs. If all these unused ASNs could be recovered, the pool of ASNs would last until 2025 to 2030. ... What about those that are assigned and used but not [currently] visible on the public Internet [i.e., are on other internets]? -- Joe Yao --- This message is not an official statement of OSIS Center policies.
Re: classful routes redux
On Fri, 4 Nov 2005, Christopher L. Morrow wrote: On Fri, 4 Nov 2005, Russ White wrote: - -- BGP is currently moving to a 2^32 space for AS numbers. That's odd, if there's only 18,044 origins in the current table, and it won't ever grow to much more--how'd we lose 40,000 or so AS numbers, that we now need more than 64,000? I think someone at CAIDA or even Renesys could put out some good numbers for 'origin' AS counts and even 'AS in aspath' It's slightly higher than 18k, but not 40k higher :) At last look (during arin/nanog meeting) it was about 20k unique origins (from 701 perspective as seen through routeviews) From [bgp.potaroo.net], the number of all ASs seen in all the route-views routing tables is around 21,000. Plenty of space to recover, even though some of those might be in private use (and might or might not be able to use private ASNs). There just doesn't seem to be the political will to do so (e.g., by starting charging some amount of money per year, so dead/unpaid ones would be turned up). Or folks may consider that too big an effort compared to just upgrading to 4B as numbers now. Seems a bit irresponsible to me. Personally I'd rather focus on cleaning up the AS number mess a bit rather than throwing more technology at the problem. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: classful routes redux
On Fri, 04 Nov 2005 21:41:48 +0200, Pekka Savola said: Seems a bit irresponsible to me. Personally I'd rather focus on cleaning up the AS number mess a bit rather than throwing more technology at the problem. All the same, we need to start the technology throw now, because it's well known that the cleanup won't happen until far too late - by the time it gets painful enough that actual cleaning happens, we won't have enough lead time to deploy technology. Personally, I'd rather focus on making sure that a 75% complete cleanup doesn't result in us falling 5% short with no alternate plan already in place and ready to turn on. pgpVpHRWVJI1S.pgp Description: PGP signature
Re: classful routes redux
From [bgp.potaroo.net], the number of all ASs seen in all theroute-views routing tables is around 21,000. Plenty of space to recover, even though some of those might be inprivate use (and might or might not be able to use private ASNs).There just doesn't seem to be the political will to do so (e.g., by starting charging some amount of money per year, so dead/unpaid oneswould be turned up).Or folks may consider that too big an effortcompared to just upgrading to 4B as numbers now.Seems a bit irresponsible to me.Personally I'd rather focus on cleaning up the AS number mess a bit rather than throwing moretechnology at the problem. Its true that we see only some 20,700 AS's in the BGP table today, and its also true that there are some 12,500 unadvertised AS's that have been assigned by the RIR system (and its predecessors), and some 6,600 AS numbers held in the RIRs that they are currently allocating from ( http://www.potaroo.net/tools/asns) The AS story is about the trends in recent times, which see a best fit of an exponential growth model to the past 3 years of AS number allocations by the RIRs, and if we assume no change in AS number policies, and no change in the trend of ageing out 'old' AS numbers at a rate of some 5% per year into the unadvertised pool, then the 2byte field will exhaust sometime in October 2010. At that time there will be some 40,000 advertised AS numbers and some 20,000 unadvertised AS numbers. The discussion of whether there are 'natural' limits to AS number consumption is an interesting one - it seems that more smaller sites are multi-homing now, and the pressure for more AS numbers in the routing system appears to be based strongly in the area of distinct routing policies in an ever-richer inter-AS connectivity mesh ( http://www.potaroo.net/ispcol/2005-08/as.htmlcontains one view of this). I'm of the view that this consumption trend reflects a behavioural trend in routing that is going to prove difficult to stop, and what we will see is a steady growth in the number of stub AS numbers that perform no transit at all.Is AS reclaimation an option? We don't know how many 'dark' (unadvertised) AS numbers are used as VPN IDs in 2547 contexts. We don't know whether this use of AS numbers will continue to grow. The recent data suggests a steady growth in the unadvertised AS count, but not at the same rate as advertised AS numbers. How much time would aggressive reclaimation buy us? Current figures indicate that it wouldwork for 3 years if we were able to reclaim ALL unadvertised AS numbers and recycle them. How much effort would it take to get this additional 3 years? Is it worth it when ytou consider that the only AS domains trhat actually need to run the NEW BGP code are thos routing domains that use AS numbers with a non-zero high-order two bytes. So, as I see it, therequirement for 4-Byte AS numbers is, at the present, very much a 'when' not 'if' question. regards, Geoff
Re: classful routes redux
RIRs, and if we assume no change in AS number policies, and no change in the trend of ageing out 'old' AS numbers at a rate of some 5% per year into the unadvertised pool, then the 2byte field will exhaust sometime in October 2010. no waffling. you said october 14th, and we're holding you to it! we would like to know about what time of day, so we can schedule lunch and coffee. Is AS reclaimation an option? We don't know how many 'dark' (unadvertised) AS numbers are used as VPN IDs in 2547 contexts. do we care? i.e. does it affect the real public internet. are these not like 1918? Current figures indicate that it would work for 3 years if we were able to reclaim ALL unadvertised AS numbers and recycle them. How much effort would it take to get this additional 3 years? and how much money will lawers make off the ensuing riot? randy
Re: classful routes redux
On Fri, 4 Nov 2005, Randy Bush wrote: Is AS reclaimation an option? We don't know how many 'dark' (unadvertised) AS numbers are used as VPN IDs in 2547 contexts. do we care? i.e. does it affect the real public internet. are these not like 1918? nope, they need to be unique... or they SHOULD BE unique (globally unique). As more folks interconnect internally (business mergers, partnerships, things such as this) there will be more clashes on 1918 (raising the evil spectre that is NOT the AC-130, but in fact NAT) and ASN clashes resulting in fragile internal networks needing an ASN swap-out... which is devilishly hard so I've heard. (atleast on a large network) Current figures indicate that it would work for 3 years if we were able to reclaim ALL unadvertised AS numbers and recycle them. How much effort would it take to get this additional 3 years? and how much money will lawers make off the ensuing riot? lawYers will always make money... but I'm not sure that 'unadvertised' is the metric you want to use here. 'unpaid' might be better.
Re: classful routes redux
Is AS reclaimation an option? We don't know how many 'dark' (unadvertised) AS numbers are used as VPN IDs in 2547 contexts. do we care? i.e. does it affect the real public internet. are these not like 1918? nope, they need to be unique... or they SHOULD BE unique (globally unique). As more folks interconnect internally (business mergers, partnerships, things such as this) there will be more clashes on 1918 (raising the evil spectre that is NOT the AC-130, but in fact NAT) and ASN clashes resulting in fragile internal networks needing an ASN swap-out... which is devilishly hard so I've heard. (atleast on a large network) we either believe in private ip/asn space or we don't. if we do, then this asn usage falls under it. and how much money will lawers make off the ensuing riot? lawYers will always make money. sorry. typing while dealing with remote server messes. but I'm not sure that 'unadvertised' is the metric you want to use here. 'unpaid' might be better. please see what we promised fnc when we formed arin, slide nine of http://rip.psg.com/~randy/970414.fncac.pdf. i think this is perceived as the social contract with the legacy community. and some old legacy dogs are pretty adamant about this, hi jis. and we have both a simple and a more complex compatible transition path to four byte asns. it's ip addresses where we have no compatible transition path. eye on doughnut and all that. randy
Re: classful routes redux
At 07:27 AM 5/11/2005, Randy Bush wrote: RIRs, and if we assume no change in AS number policies, and no change in the trend of ageing out 'old' AS numbers at a rate of some 5% per year into the unadvertised pool, then the 2byte field will exhaust sometime in October 2010. no waffling. you said october 14th, and we're holding you to it! we would like to know about what time of day, so we can schedule lunch and coffee. well, the figures indicate that RIPE will receive 10 requests on that day, and will start the day with 5 left in their pool. So the first allocation processed after lunch will fail - so that would mean at 2:00 pm CET on the 14th October 2010 - or thereabouts! :-). Is AS reclaimation an option? We don't know how many 'dark' (unadvertised) AS numbers are used as VPN IDs in 2547 contexts. do we care? i.e. does it affect the real public internet. are these not like 1918? practice and theory. In theory whether such as's are used in private contexts or not makes no difference as to their potential to be used in the public Internet. The practice this may not be so easy. Current figures indicate that it would work for 3 years if we were able to reclaim ALL unadvertised AS numbers and recycle them. How much effort would it take to get this additional 3 years? and how much money will lawers make off the ensuing riot? Certainly a factor that can't be ignored completely! Which is why I've offerred the perspective that it may be easier to simply press on with the 4-Byte AS work and get the routers into a position to be able to accept the deployment of 4-Byte ASs, rather than debate at some length the potential cost and benefit of forms of reclaimation efforts in this space. regards, Geoff
Re: classful routes redux
no waffling. you said october 14th, and we're holding you to it! we would like to know about what time of day, so we can schedule lunch and coffee. well, the figures indicate that RIPE will receive 10 requests on that day, and will start the day with 5 left in their pool. So the first allocation processed after lunch will fail - so that would mean at 2:00 pm CET on the 14th October 2010 - or thereabouts! :-). v uh, won't that be 14:00 CST? as we don't do summertime here, this difference will impact my first cuppa. Is AS reclaimation an option? We don't know how many 'dark' (unadvertised) AS numbers are used as VPN IDs in 2547 contexts. do we care? i.e. does it affect the real public internet. are these not like 1918? practice and theory. In theory whether such as's are used in private contexts or not makes no difference as to their potential to be used in the public Internet. The practice this may not be so easy. we believe in private space or we don't. if we do, then they can use private asns or snatch public ones and keep their 42 ribs from mixing. if we don't, then we have to stop whining about giving folk real unique ip address space and asns we never see on the public net. Which is why I've offerred the perspective that it may be easier to simply press on with the 4-Byte AS work and get the routers into a position to be able to accept the deployment of 4-Byte ASs, rather than debate at some length the potential cost and benefit of forms of reclaimation efforts in this space. we're in agreement here, though, as you know, i am more inclined to the you have five years to upgrade conversion approach. less exposure to router code and config bugs. but ip space is a much harder issue. v6 did not come with a transition plan and still has no credible one. randy
Re: classful routes redux
At 11:10 AM 5/11/2005, Randy Bush wrote: no waffling. you said october 14th, and we're holding you to it! we would like to know about what time of day, so we can schedule lunch and coffee. well, the figures indicate that RIPE will receive 10 requests on that day, and will start the day with 5 left in their pool. So the first allocation processed after lunch will fail - so that would mean at 2:00 pm CET on the 14th October 2010 - or thereabouts! :-). v uh, won't that be 14:00 CST? as we don't do summertime here, this difference will impact my first cuppa. my mistake - yes, that will be CST rather than CET I trust that this adjustment will not impact your scheduling of the lunch and coffee caterers :-) As you point out, the IP issue is much harder, and because the transition is so markedly different from the AS one the dynamics of exhaustion of the unallocated IP V4 address pool will undoubtedly be different (and much harder to use relatively simple numerical methods to predict). I could use the word panic but as we are all responsible and careful players here let's just call it the looming scenario of folk looking at last chance direct IPv4 address allocations in the near term future. I'd be interested if anyone here has some generic modelling tools that include modelling of such so-called 'panic' situations, as I'd be interested to apply it to this situation in various ways. Geoff
Re: classful routes redux
Please pardon the crossposting between ppml and nanog... Geoff Huston [EMAIL PROTECTED] writes: Why /48 rather than /47 or /49? - alignment to nibble boundaries to make DNS delegation easier. It has recently come to my attention that we are in error when we expect n[iy]bble to have the same amount of popular awareness as byte. In point of fact, my guess is that most people who are not programmers (or particularly assembly language programmers) have minimal or no exposure to the term. Particularly in public policy discussions, such people abound, and their engagement in the process is no less important than that of a protocol implementer. Future proposals involving a preference toward doing things with 4-bit alignment should take care to explain what precisely a n[iy]bble is and hexadecimal numbering, and why it matters. ---Rob
Re: classful routes redux
On Thu, 3 Nov 2005, Stephen J. Wilcox wrote: well, /56 /48 /32 seem to have resonance but are not special in any way Well, they are somewhat special. All of them are on eight-bit boundaries. The importance of this comes in when deciding how to lay out a routing table in a gate array or memory-based table. A routing table capable of handling a flat 2^128 addressing space goes beyond the realm of known physics -- and flat 2^64 comes close, at least for a while (consider semiconductor atomic weights, and the fact that 1 mole is approximately 2^79 atoms). That's quite a stretch, but should give a hint as to why flat addressing does not work for every model. Routing tables become much simpler when you have N-level (tree-like) tables, a concept also used in MMUs. A tree done one bit at a time, while the most compact form in many cases, is not very efficient at lookups. If you divide the bitspace into sized chunks, the lookup time can be a better tradeoff between speed and tree size. Specifically, 8-bit dividing lines make this even easier. Much logic programming (FPGA or similar) depends on power-of-two data sizes with a minimum of 4 or 8 bits. This has led to well established 4-bit and 8-bit data movement patterns that have been better optimized over time. If using a store-and-forward mechanism with a more generic data processor (such as a CPU), 8-bit dividing lines are all the more important for speed. Or in summary of all of the above, 8-bit building blocks in routing tables make writing the physical routing code much easier, and in many cases makes the forwarding operation much faster. -- -- Todd Vierling [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: classful routes redux
On Thu, Nov 03, 2005 at 03:29:35PM -0500, Todd Vierling wrote: On Thu, 3 Nov 2005, Stephen J. Wilcox wrote: well, /56 /48 /32 seem to have resonance but are not special in any way Well, they are somewhat special. All of them are on eight-bit boundaries. The importance of this comes in when deciding how to lay out a routing table in a gate array or memory-based table. A routing table capable of handling a flat 2^128 addressing space goes beyond the realm of known physics -- and flat 2^64 comes close, at least for a while (consider semiconductor atomic weights, and the fact that 1 mole is approximately 2^79 atoms). That's quite a stretch, but should give a hint as to why flat addressing does not work for every model. Come on now, a lot of new routing gear made today can just barely handle 2^18 routes, and even the high end stuff tops out at 2^20. We're nowhere near handling 2^32 routes even for IPv4, nor should we be, so lets not start the whole but ipv6 has more space therefore routes will increase to 7873289439872361837492837493874982347932847329874293874 nonsense again. Removing the extreme restrictions on IP space allocation by being able to allocate chunks so large that you would RARELY need to go back for a second block would immediate reduce the size of the routing table. Let me state the stats again for the record: Total ASes present in the Internet Routing Table: 20761 Origin-only ASes present in the Internet Routing Table: 18044 Origin ASes announcing only one prefix:8555 Transit ASes present in the Internet Routing Table:2717 There are just not that many distinct BGP speaking networks out there, nor will there ever be. NOW is the time to make certain that IPv6 deployments makes sense in practice and not just in theory, so we don't work ourselves into exactly the same mess that we did in IPv4. Lets stop trying to solve theoretical scaling problems which will never happen at the expense of creating problems which actually DO exist, and apply a little bit of common sense. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: classful routes redux
On Thu, 3 Nov 2005, Richard A Steenbergen wrote: On Thu, Nov 03, 2005 at 03:29:35PM -0500, Todd Vierling wrote: On Thu, 3 Nov 2005, Stephen J. Wilcox wrote: well, /56 /48 /32 seem to have resonance but are not special in any way Well, they are somewhat special. All of them are on eight-bit boundaries. The importance of this comes in when deciding how to lay out a routing table in a gate array or memory-based table. A routing table capable of handling a flat 2^128 addressing space goes beyond the realm of known physics -- and flat 2^64 comes close, at least for a while (consider semiconductor atomic weights, and the fact that 1 mole is approximately 2^79 atoms). That's quite a stretch, but should give a hint as to why flat addressing does not work for every model. Come on now, a lot of new routing gear made today can just barely handle 2^18 routes, and even the high end stuff tops out at 2^20. We're nowhere near handling 2^32 routes even for IPv4, nor should we be, so lets not start the whole but ipv6 has more space therefore routes will increase to 7873289439872361837492837493874982347932847329874293874 nonsense again. Removing the extreme restrictions on IP space allocation by being able to allocate chunks so large that you would RARELY need to go back for a second block would immediate reduce the size of the routing table. Let me state the stats again for the record: Total ASes present in the Internet Routing Table: 20761 Origin-only ASes present in the Internet Routing Table: 18044 Origin ASes announcing only one prefix:8555 Transit ASes present in the Internet Routing Table:2717 There are just not that many distinct BGP speaking networks out there, nor will there ever be. NOW is the time to make certain that IPv6 deployments makes sense in practice and not just in theory, so we don't work ourselves into exactly the same mess that we did in IPv4. Lets stop trying to solve theoretical scaling problems which will never happen at the expense of creating problems which actually DO exist, and apply a little bit of common sense. ack that. assign one ipv6 prefix to every asn of sufficient size that most will not need to request additional space whilst i'm at the mic here, ditch the idea of microassignments, just give out a standard /32 block ... lets not start out with ge 33 prefixes in the table when theres no need Steve
Re: classful routes redux
whilst i'm at the mic here, ditch the idea of microassignments, just give out a standard /32 block ... lets not start out with ge 33 prefixes in the table when theres no need Steve there is this wonderful, apparently US phenomeon, called the warehouse store aka Stuffmart. Single guys go in for a quart of milk and some TP and walk out w/ a MINIMUM of four gallons of milk, 144 rolls of TP, and a side of beef. saving the poor routing table is a laudable and worthwhile goal, but dumping the excess into the edges, just cause its easy strikes me as lame. a routing table slot is a slot is a slot. It holds a /96 as well as a /32 as well as a /112. If we are going to ditch microassignments (and boy is that term an oxymoron) then we should also dump one-size-fits-all and really and truely give folks what they need. RIRs have -never- assured the routablity of delegations. --oat willie (as a lone voice)
Re: classful routes redux
On Nov 3, 2005, at 4:34 PM, [EMAIL PROTECTED] wrote: saving the poor routing table is a laudable and worthwhile goal, but dumping the excess into the edges, just cause its easy strikes me as lame. a routing table slot is a slot is a slot. It holds a /96 as well as a /32 as well as a /112. If we are going to ditch microassignments (and boy is that term an oxymoron) then we should also dump one-size-fits-all and really and truely give folks what they need. RIRs have -never- assured the routablity of delegations. Disagree. The one saving grace I can see of v6 is that there is enough space to give everyone the space they need in a single allocation. It's not a waste if it keeps people from needing a second block. Maybe not everyone needs a /32, but let's not get stingy with plentiful resources (IP space in v6) and risk using too much of a not- so-plentiful resource (routing table slot). -- TTFN, patrick
Re: classful routes redux
actually, no, I could compare a /48 to a class A. ...which makes the /32s-and-shorter that everybody's actually getting double-plus-As, or what? no, super *duper* A's. -- Paul Vixie
Re: classful routes redux
actually, no, I could compare a /48 to a class A. On Nov 2, 2005, at 3:51 PM, [EMAIL PROTECTED] wrote: er.. would this be a poor characterization of the IPv6 addressing architecture which is encouraged by the IETF and the various RIR members? class A == /32 class B == /48 class C == /56 hostroute == /64 (and just think of all that spam than can originate from all those loose IP addresses in that /64 for your local SMTP server!!! Yummy) -- Oat Willie -- Don't worry about the world coming to an end today. It's already tomorrow in Australia. (Charles Schulz )
Re: classful routes redux
On Wed, 2 Nov 2005, Fred Baker wrote: actually, no, I could compare a /48 to a class A. ...which makes the /32s-and-shorter that everybody's actually getting double-plus-As, or what? -Bill
Re: classful routes redux
On Nov 2, 2005, at 4:01 PM, Bill Woodcock wrote: On Wed, 2 Nov 2005, Fred Baker wrote: actually, no, I could compare a /48 to a class A. ...which makes the /32s-and-shorter that everybody's actually getting double-plus-As, or what? A class A gives you 16 bits to enumerate 8 bit subnets. If you start from the premise that all subnets are 8 bits (dubious, but I have heard it asserted) in IPv4, and that all subnets in IPv6 are 16 bits (again dubious, given the recent suggestion of a /56 allocation to an edge network), a /48 is the counterpart of a class A. We just have a lot more of them. All of which seems a little twisted to me. While I think /32, /48, / 56, and /64 are reasonable prefix lengths for what they are proposed for, I have this feeling of early fossilization when it doesn't necessarily make sense.
Re: classful routes redux
On Wed, 2 Nov 2005, Fred Baker wrote: While I think /32, /48, /56, and /64 are reasonable prefix lengths for what they are proposed for, I have this feeling of early fossilization when it doesn't necessarily make sense. Yeah, that's what seems important to me here... I mean, I've lived through the whole classful thing once... I'm still not clear why there are people who want to do it again. -Bill
Re: classful routes redux
* [EMAIL PROTECTED] (Fred Baker) [Thu 03 Nov 2005, 01:17 CET]: A class A gives you 16 bits to enumerate 8 bit subnets. If you start You've been reading too much Cisco Press material. All a Class A gives you today is filthy looks, and people who know better shake their heads, feeling sorry for you. The operational world left classful IPv4 addressing behind us, over a decade ago. Perhaps it's time that certain vendors did the same, in their literature and certification programmes. Recycling outdated terms to apply to new concepts (Class C to represent a /24 in the CIDR IPv4 world, or a /48 or whatever in IPv6) is a folly that can only lead to suffering. -- Niels.
Re: classful routes redux
On Wed, 2 Nov 2005, Fred Baker wrote: A class A gives you 16 bits to enumerate 8 bit subnets. If you start from the premise that all subnets are 8 bits (dubious, but I have heard it asserted) in IPv4, not according to my view of the internet.. /8: 18 /9: 5 /10: 8 /11: 17 /12: 79 /13: 179 /14: 335 /15: 651 /16: 8553 /17: 2855 /18: 4793 /19: 10791 /20: 11877 /21: 9990 /22: 13168 /23: 14299 /24: 93293 and that all subnets in IPv6 are 16 bits (again dubious, given the recent suggestion of a /56 allocation to an edge network), a /48 is the counterpart of a class A. We just have a lot more of them. well, /56 /48 /32 seem to have resonance but are not special in any way All of which seems a little twisted to me. you think? :) While I think /32, /48, / 56, and /64 are reasonable prefix lengths for what they are proposed for, I have this feeling of early fossilization when it doesn't necessarily make sense. classes are bad. but recognise v6 is a bit different, /48 or /56 is the per site bit which is not comparable to v4. then /32 is is largest generally accepted prefix for bgp. this suggests anything can happen from 0-32 in bgp and anything can happen in provider igp for 32-48 or 32-56 and again anything in end user igp for 48/56-128 repeat 3 times, twice daily. classes are bad, v6 is not v4 Steve
Re: classful routes redux
Bill Woodcock wrote: On Wed, 2 Nov 2005, Fred Baker wrote: While I think /32, /48, /56, and /64 are reasonable prefix lengths for what they are proposed for, I have this feeling of early fossilization when it doesn't necessarily make sense. Yeah, that's what seems important to me here... I mean, I've lived through the whole classful thing once... I'm still not clear why there are people who want to do it again. It's not quite the same as classful addressing in IPv4. There is no definition of prefix length by address range. At the RIR-ISP level It is actually CIDR with a minimum allocation size that intentionally covers 95+% of applicants. Shorter allocations of various sizes are made based on justification. An extra 1-3 bits is even reserved around each allocation for future growth. The same thing applies to End sites. You can get a /47 or shorter with justification. It's might be rare but it is possible. I think the goal was to avoid making multiple non-aggregatable allocations as is done with IPv4. An alternative would be to allocate based on initial need but still reserve a much larger prefix for future growth. This would avoid the illusion of fixed sizes and carry less risk of unused space. Is that worth the extra RIR effort? Maybe, maybe not. - Kevin
Re: classful routes redux
On Wed, 2 Nov 2005, Fred Baker wrote: actually, no, I could compare a /48 to a class A. (someone might already have asked this, but...) why /48? Perhaps it's the convenience of it all, but I was pretty much willing to 'accept' the listing as bill/randy had laid it out (accept the wording i suppose) On Nov 2, 2005, at 3:51 PM, [EMAIL PROTECTED] wrote: er.. would this be a poor characterization of the IPv6 addressing architecture which is encouraged by the IETF and the various RIR members? class A == /32 class B == /48 class C == /56 hostroute == /64 (and just think of all that spam than can originate from all those loose IP addresses in that /64 for your local SMTP server!!! Yummy) -- Oat Willie -- Don't worry about the world coming to an end today. It's already tomorrow in Australia. (Charles Schulz )
Re: classful routes redux
hostroute == /64 (and just think of all that spam than can originate from all those loose IP addresses in that /64 for your local SMTP server!!! Yummy) -- Oat Willie ok... so is it -just- me that gets the willies thinking of the 2x64-1 available IPv6 addresses that can be forged as source addresses for spam origination?i REALLY want to have a tidy way of only announcing -EXACTLY- what is being used (ok, modulo one or two adjacent numbers) and not some architecturally constrained addressing plan that has to conserve elsewhere. (yeah, and my co-bills want ponies) --bill
Re: classful routes redux
On Thu, 3 Nov 2005 [EMAIL PROTECTED] wrote: hostroute == /64 (and just think of all that spam than can originate from all those loose IP addresses in that /64 for your local SMTP server!!! Yummy) -- Oat Willie ok... so is it -just- me that gets the willies thinking of the 2x64-1 available IPv6 addresses that can be forged as source addresses for spam origination?i REALLY want to have a tidy but, but, but... ipv6 is more SECURE! :) I'm really not sure I understand why my LAN has to have more available ip space than the current Internet, but boy, it sure makes it easy to spam^H^H^H^Hfind available addresses! I view the 48/56/64 boundaries about like Woody does (and I suspect Mr. Narkins and Mr. Bush) they are in the documentation so people use them, it's not particularly a great idea, but it is an idea. (Oh, and some equipment won't do the lovely autoconfig unless you have a /64, someone should open a bug report on that)
Re: classful routes redux
I was pretty much willing to 'accept' the listing as bill/randy had laid it out (accept the wording i suppose) actually, bill and i disagreed. this is not unusual :-) On Nov 2, 2005, at 3:51 PM, [EMAIL PROTECTED] wrote: class A == /32 class B == /48 class C == /56 hostroute == /64 and i: I have to admit that I'm guilty of using the phrase class C more or less interchangably with /24 - I suspect a lot of us still do that... well, now you can do it for /64s and class B can be /48s (or is it /56s?) and class A can be /32s as, in the truely classful days, a lan was a C == /24, i'll stick to my guns for the moment that a new C is a /64 and so forth. as there is no emoticon for sarcasm, the naive should know that i (and maybe bill) draw this comparison to point out that, by codifying such boundaries in technology and policy, we're making the same old mistakes again. randy
Re: classful routes redux
On Wed, 2 Nov 2005, Randy Bush wrote: I was pretty much willing to 'accept' the listing as bill/randy had laid it out (accept the wording i suppose) actually, bill and i disagreed. this is not unusual :-) oh silly me, I skipped over 'hostroute' and read 'class c' doh :( anyway, this all seems foolish in the end, making the same mistakes again is going to bite someone in the behind.
Re: classful routes redux
class C == /56 hostroute == /64 and i: as, in the truely classful days, a lan was a C == /24, i'll stick to my guns for the moment that a new C is a /64 and so forth. and this from the man who actually received a /33 delegation in v4 space! :) as there is no emoticon for sarcasm, the naive should know that i (and maybe bill) draw this comparison to point out that, by codifying such boundaries in technology and policy, we're making the same old mistakes again. amen... in spades. --bill randy
Re: classful routes redux
At 01:16 PM 3/11/2005, Christopher L. Morrow wrote: On Wed, 2 Nov 2005, Fred Baker wrote: actually, no, I could compare a /48 to a class A. (someone might already have asked this, but...) why /48? Because the thinking at the time appears to be that to ease' renumbering reduce the costs associated with address distribution functions (and associated network assessment tasks) and because there were heaps of addresses, all end-sites would get the same address allocation, and the uniform amount that was arrived at was a /48 . When asked whether this referred to _everything_ that may require subnets, the answer was yes. When asked whether this encompassed everything from a mobile phone to a large corporate the answer given was, once more, yes. Why /48 rather than /47 or /49? - alignment to nibble boundaries to make DNS delegation easier. Why /48 rather than /32 or /40? I really cannot say - I suspect that /48 is the largest end site number that meets the projected scope as described in RFC 3177. regards, Geoff
Re: classful routes redux
On Wed, 2 Nov 2005, [EMAIL PROTECTED] wrote: er.. would this be a poor characterization of the IPv6 addressing architecture which is encouraged by the IETF and the various RIR members? class A == /32 class B == /48 class C == /56 hostroute == /64 It's quite arbitrary though, unlike the old classful IPv4 divisions - a matter of policy, not technology. The allocation sizes can and do vary over both time (as policy changes, IIRC RIPE used to assign /35s iirc, now it's /32) and between different RIRs. A hostroute is /128 btw. ;) regards, -- Paul Jakma [EMAIL PROTECTED] [EMAIL PROTECTED] Key ID: 64A2FF6A Fortune: QOTD: Every morning I read the obituaries; if my name's not there, I go to work.
