There is nothing about a cable modem that would normally prevent a BGP session. Nor do all the intermediate routers need to support BGP (multi-hop BGP). However, direct connections are preferred. Your _real_ challenge is convincing Roadrunner's NOC staff to program one of their backbone routers to do a BGP session with a cable modem sub. Or, for that matter, getting them to even route a non-roadrunner IP block to a cable modem sub. Instead you might try borrowing a bunch of old 2500s and setting up a test lab that isn't connected to actual net. Best of luck on your CCIE. John At 02:06 PM 11/2/2005, Edward W. Ray wrote:

66.6.208.1/24, ASN is currently 11509 but I will be getting my own shortly.

Edward W. Ray

-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Hannigan, Martin Sent: Wednesday, November 02, 2005 11:54 AM To: Edward W. Ray; nanog@merit.edu Subject: RE: Using BGP to force inbound and outbound routing through particular routes

What's the netblock and ASN you already have?

...

-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Edward W. Ray Sent: Wednesday, November 02, 2005 2:50 PM To: nanog@merit.edu Subject: Using BGP to force inbound and outbound routing through particular routes

spam was a lousy name...

-----Original Message----- From: spam [mailto:spamjail@mmicman.com] Sent: Wednesday, November 02, 2005 11:44 AM To: 'nanog@merit.edu' Subject: FW: Using BGP to force inbound and outbound routing through particular routes

I recently made a request to get a cable modem connection at my home. I went for one of those $29.95 for three month specials in case I run afoul of some rules prohibiting what I am going to do. I already have a multi-T1 connection with a Class C block and BGP running on my Cisco 3640 router, and was looking to become multi-homed. The cable connection is via bridge/DHCP cable modem, and was going to hook it up to the Cisco 3640. I have already done the research and know from what block of IP addresses I will be assigned, and the BGP route tables/peers.

I would like to use BGP to force inbound and outbound routing only through particular peers, Sprint (AS 1239) and UUNET (AS 701). I have been reading "Practical BGP" by Whate, McPherson and Sangli and this appears to be possible. However, do my adjacent routers need to support BGP in order for this to work? Could I use other routing protocols to accomplish this, or would this require knowledge of all possible downstream router IP addresses?

Edward W. Ray

RAS, 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... On 11/2/05 2:22 PM, "Richard A Steenbergen" <ras@e-gerbil.net> wrote:

On Wed, Nov 02, 2005 at 03:35:07PM -0600, John Dupuy wrote:

...

There is nothing about a cable modem that would normally prevent a BGP session. Nor do all the intermediate routers need to support BGP (multi-hop BGP). However, direct connections are preferred.

Your _real_ challenge is convincing Roadrunner's NOC staff to program one of their backbone routers to do a BGP session with a cable modem sub. Or, for that matter, getting them to even route a non-roadrunner IP block to a cable modem sub.

Instead you might try borrowing a bunch of old 2500s and setting up a test lab that isn't connected to actual net.

Best of luck on your CCIE.

A) No cable company in their right mind is going to speak BGP to a $29.95/mo residential customer, period.

B) The answer to his question about "I don't know if what I'm doing will violate the AUP or not" is, when in doubt the answer is YES. No sane comapny is going to let this guy near bgp with a 10ft pole after that statement, but then again no sane people read nanog any more I suspect.

C) If this guy actually had a CCIE, I would encourage Cisco to quickly implement a SWAT team responsible for reposessing the CCIE medals of anyone caught using the words "Class C" for a /24 out of 66. space.

D) Please do not feed the trolls. :)

-- Joe McGuckin ViaNet Communications 994 San Antonio Road Palo Alto, CA 94303 Phone: 650-213-1302 Cell: 650-207-0372 Fax: 650-969-2124

On Wed, Nov 02, 2005 at 03:21:15PM -0800, Joe McGuckin wrote:

RAS,

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, on behalf of the entire networking community, I hereby ask you to stop it. :) It's just a bad habit, and while you may know exactly what it means and doesn't mean, it does nothing but confuse new people about how and why classless routing works. It is absolutely absurd that so many people still teach classful routing FIRST to new students in this day and age, and then approach classless routing like it is something new and different which should be considered as an afterthought. Just remember, the people you confuse today are the ones who are going to be announcing their legacy erm "class B" allocations as /24s tomorrow, because they don't know any better. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

actually, no, I could compare a /48 to a class A. On Nov 2, 2005, at 3:51 PM, bmanning@vacation.karoshi.com 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 )

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.

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

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

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

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 <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

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)

-----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 - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.2 (Build 2424) iQA/AwUBQ2trGREdu7FIVPTkEQI5RQCg+Ol1jrkvldeC5ao403Yw4WiiabgAnj1K KXBXTIBh9R7kDIDBWGooPxdQ =i+AJ -----END PGP SIGNATURE-----

-----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 - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.2 (Build 2424) iQA/AwUBQ2t4+xEdu7FIVPTkEQIGUACfXDFqrwMY08f2ow+YeyafOoIVSG8AnRp0 hPXzjJt87XUCJ1mrfSDJr9o+ =ZRk5 -----END PGP SIGNATURE-----

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

Thus spake <Michael.Dillon@btradianz.com>

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 Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin

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 Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

From [bgp.potaroo.net <http://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.

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.html contains 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 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? 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, the requirement for 4-Byte AS numbers is, at the present, very much a 'when' not 'if' question. regards, Geoff

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.

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

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

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, bmanning@vacation.karoshi.com 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 )

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, bmanning@vacation.karoshi.com 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

...

...

...

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

On Wed, 2 Nov 2005, Richard A Steenbergen wrote:

It's just a bad habit, and while you may know exactly what it means and doesn't mean, it does nothing but confuse new people about how and why classless routing works. It is absolutely absurd that so many people still

keep them confused, then they can't join 'the club'...