Re: OMB: IPv6 by June 2008
Randy Bush wrote: Is it a pproblem keeping 500,000 routess in core routers? Of course, it is not (it was in 1996, but it is not in 2005 really? we have not seen this so how do you know? and it will be fine with churn and pushing 300k forwarding entries into the fibs on a well-known vendor's line cards? Soon the fib can be replaced by just an array with an index for every IPv4 address. With 255 interfaces, 4G is sufficient .-) Pete
Re: DNS .US outage
- Original Message - From: Randy Bush [EMAIL PROTECTED] Sent: Wednesday, July 06, 2005 7:19 PM Subject: RE: DNS .US outage i believe even windoze has dig at the command line, though i don't know in what directory it lies. randy In case other Win users aren't aware: http://www.samspade.org/ssw/features.html --Michael
Re: OMB: IPv6 by June 2008
Jeroen Massar wrote: 2 - Replace network elements with IPv6 compatible network elements and S/W On a per-link basis, start with tunnels where needed, go native later on or rather directly when possible. Most Cisco's can be upgraded to support IPv6, JunOS supports it too, though they now suddenly require some absurd fee especially for IPv6. For most layer2 setups getting IPv6 working is really a matter of upgrading the kernels or just enabling it. The problem are printers, thermometers, cameras, barcodescanners or in case of the person you are replying to: strange scientific instruments (I guess). Nils
Re: OMB: IPv6 by June 2008
On Jul 7, 2005, at 2:14 PM, Iljitsch van Beijnum wrote: Right again. And like prospecting for oil, at some point you're burning it up faster than you can prospect it. There are some 45 - 50 /8s assigned to single organizations. Let's assume for simplicity that those can all be reclaimed. That's 4 years at a /8 a month. So far so good. Then there are 40 - 45 /8s in class B space. That means 256 times as much effort to reclaim the address space, or reclaiming about 10 class Bs a day... There is, of course, a slightly different model: As IPv4 address space becomes less freely available, there will be an increase in black and gray market transactions for that address space. Since these transactions involve actual money instead of the more difficult to account for human activity dealing with the RIRs or ISPs, there will be financial incentive both to reduce consumption as well as offer allocated but unused space via the black and gray markets. In this model, you get a natural, market-driven evolution towards a two tiered routing hierarchy (call it the core and the edge) mediated by That Which Shall Not Be Named. As folks who own address space (yes, I know, address space isn't owned. I suspect this convention might break down pretty quickly as address space becomes more scarce) figure out there's gold in dem dar unused tracts of address space, they'll make a quick buck selling it to somebody who desires it more (as demonstrated by their willingness to pay the owner's price) and moving their infrastructure behind a TWSNBN. Large blocks and provider aggregateable space will command a higher price, long prefix blobs spread out randomly a lower price due to the pain of trying to get it routed. Imagine (to pick an example purely at random) the President of MIT being presented with the choice of receiving a very large wad of cash in exchange for 18/8. How big would that wad have to be before she decided it'd be worth migrating 18/8 to 10/8 and living behind a TWSNBN? Of course, I'm sure this is all just a feverish nightmare caused by a bad habanero pepper... (why do I get a recurring image of Peter Lothberg wandering around the room collecting all the little balls he can?). Rgds, -drc P.S. No, I am not suggesting this is a good or even a likely outcome. Just pointing out that there can be other forces coming into play as scarcity becomes more noticeable.
Re: OMB: IPv6 by June 2008
Who need this complexity? What's wrong with old good _routing rotocol_ approach? Memory? (do not joke, today 4 Gb RAM is not a problem, when it is for slow routing system). CPU (the same)? What else? If it looked as a problem 10 years ago, it can not be relevant to today's realities. - Original Message - From: Joe Abley [EMAIL PROTECTED] To: Andre Oppermann [EMAIL PROTECTED] Cc: NANOG list nanog@merit.edu; Alexei Roudnev [EMAIL PROTECTED]; Iljitsch van Beijnum [EMAIL PROTECTED] Sent: Thursday, July 07, 2005 8:11 AM Subject: Re: OMB: IPv6 by June 2008 On 2005-07-07, at 10:23, Andre Oppermann wrote: It was about a spot in the global routing table. No matter if one gets PA or PI they get a routing table entry in the DFZ. There is no way around it other than to make the routing protocols more scaleable. With the hole-punching/CIDR abuse multihoming that is widely used in IPv4, a slot in the DFZ gets burned each time an end site adds a provider, regardless of whether they are using PA or PI addresses. This slot represents state information for the multi-homed site which answers the question how else can this set of addresses be reached? The shim6 approach shifts this state from the DFZ to the endpoints which are exchanging unicast traffic. The endpoints exchange a set of possible locators through a protocol element within the IP layer and handle locator migration transparently to the transport layer above. Hence the question how else can this particular remote address be reached is answered using information on the host, not information in the network. With shim6 an end site can multi-home using one PA prefix per provider, without taking up additional slots in the DFZ. Hosts within the site are given multiple addresses (locators), and the layer-3 shim handles any change of locator needed for traffic exchanged between any two hosts. If one (or both) of the hosts exchanging traffic don't support shim6, then the traffic is exchanged without transport-layer stability across re-homing events (and, potentially, without any optimisation as to the choice of endpoint addresses for the session). So, the shim6 future of multihoming looks like this: 1. ISPs multi-home exactly as people are used to doing today, using PI prefixes, and taking up a slot in the DFZ per transit provider. Everybody is familiar with this already. There is no change for ISPs in this picture. 2. Multi-homed end sites obtain one PA prefix per upstream ISP, and hosts within those end-sites are assigned multiple addresses (in some automated, secure and controllable fashion). There are no additional slots burned in the DFZ by end site multi-homing. Hosts obtain transport-layer reliability across re-homing events using shim6, rather than relying on the network to take care of it. Joe
Re: OMB: IPv6 by June 2008
At 12:51 AM -0700 2005-07-08, Alexei Roudnev wrote: Who need this complexity? What's wrong with old good _routing rotocol_ approach? Memory? (do not joke, today 4 Gb RAM is not a problem, when it is for slow routing system). CPU (the same)? What else? Can you put 4GB on every linecard on every router you own? Can you put a Power5 or PowerPC 970MP processor on every linecard on every router you own? Does your vendor support you making any modifications/upgrades to any of their linecards, or do they require you to buy new ones with the go-faster features? And how many tens of thousands of dollars do each of those go-faster linecards cost? And how many million-dollar fork-lift upgrades do you have to pay for in order to get the go-faster chassis in which to plug those go-faster cards into? Do you have thousands of routers? Hundreds of thousands? I'm asking serious questions here. I'm not a router guy, but I've heard a lot of comments on this list that give me pause, so I'd like to get real-world answers. Speaking from my own perspective, it seems to me that we've got a scalability problem here when we're expecting most devices to have a pretty complete picture of the entire world. I think that's the real problem that has to be addressed. In terms of the routing protocols and number of ASes, we know that it's possible to build machines which can handle those kinds of things at those kinds of numbers. The problem is that it's hard to do those kinds of things on a widespread basis (e.g., in every linecard in every router in the world), and most devices probably don't need that anyway. I don't know what the real solution is. But it seems to me that we need to find something, and having people say 4GB of RAM? No problem is not the way to get this solved. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See http://www.sage.org/ for more info.
Re: OMB: IPv6 by June 2008
On Fri, 8 Jul 2005, Alexei Roudnev wrote: Who need this complexity? What's wrong with old good _routing rotocol_ approach? Memory? (do not joke, today 4 Gb RAM is not a problem, when it is for slow routing system). CPU (the same)? What else? TCAMs are expensive and complex. Convergence time is also a problem. -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
Re: OMB: IPv6 by June 2008
What is CPU power of today's core routers? What's memory? Compare with junk-yard server - 2 x 1.4Ggz CPU, 4 GB RAM, total price about $1.5K. Routers have 3 - 10 times reserve _today_ . Then, you can always sacrify reaction time a little. Reserves are tremendous in this area. - Original Message - From: Randy Bush [EMAIL PROTECTED] To: Alexei Roudnev [EMAIL PROTECTED] Cc: nanog@merit.edu Sent: Thursday, July 07, 2005 1:23 PM Subject: Re: OMB: IPv6 by June 2008 Is it a pproblem keeping 500,000 routess in core routers? Of course, it is not (it was in 1996, but it is not in 2005 really? we have not seen this so how do you know? and it will be fine with churn and pushing 300k forwarding entries into the fibs on a well-known vendor's line cards? randy
Re: OMB: IPv6 by June 2008
Moreover, if you are not multihomned, you can be aggregated. If you became multihome - yes, you take a slot; how many entities in the world should be multihomed? - Original Message - From: Kuhtz, Christian [EMAIL PROTECTED] To: David Conrad [EMAIL PROTECTED]; Alexei Roudnev [EMAIL PROTECTED] Cc: Mohacsi Janos [EMAIL PROTECTED]; Daniel Golding [EMAIL PROTECTED]; Scott McGrath [EMAIL PROTECTED]; nanog@merit.edu Sent: Thursday, July 07, 2005 11:02 AM Subject: RE: OMB: IPv6 by June 2008 Alexei, On Jul 7, 2005, at 9:58 AM, Alexei Roudnev wrote: What's the problem with independent address space for every entity (company, family, enterprise) which wants it? It doesn't scale. Regardless of Moore's law, there are some fundamental physical limits that constrain technology. I would contend that is not true. What says that every device inside a company, family, enterprise etc has to be available and reachable by anyone on the planet in a bidirectional fashion as far as session initiation is concerned? Once you add that bit of reality to it, the scaling requirement goes down substantially. Wouldn't you agree? Trust me, I would like to just see us get it over with as far as IPv6 is concerned, provided we have a working, palatable IPv6 mh solution. But, man, I can't pass the red face test on a lot of these hypothesis :( Thanks, Christian The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 163
Re: OMB: IPv6 by June 2008
What is CPU power of today's core routers? What's memory? Compare with junk-yard server - 2 x 1.4Ggz CPU, 4 GB RAM, total price about $1.5K. Routers have 3 - 10 times reserve _today_ . Then, you can always sacrify reaction time a little. Reserves are tremendous in this area. Is it a pproblem keeping 500,000 routess in core routers? Of course, it is not (it was in 1996, but it is not in 2005 really? we have not seen this so how do you know? and it will be fine with churn and pushing 300k forwarding entries into the fibs on a well-known vendor's line cards? clue: some large isps have routers falling over today due to ram limitations on line cards. and it will cost a LOT of money for them to do upgrades which will last not long enough. as this is an ops list, can we try to stay somewhere in the neighborhood of operational realities? randy
Re: OMB: IPv6 by June 2008
At 1:11 AM -0700 2005-07-08, Alexei Roudnev wrote: What is CPU power of today's core routers? What's memory? Compare with junk-yard server - 2 x 1.4Ggz CPU, 4 GB RAM, total price about $1.5K. Fair enough. Since they're trivially cheap, you get to pay for upgrading all the routers in the world. Come back to us when you're done. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See http://www.sage.org/ for more info.
Re: OMB: IPv6 by June 2008
You do not need to - any router have only `1 - 10% of all routing table active, and it is always possible to optimize these alghoritms. On the other hand - what's wrong with 4Gb on line card in big core router? It's cheap enough, even today. And we have not 1,000,000 routes yet. - Original Message - From: Brad Knowles [EMAIL PROTECTED] To: NANOG nanog@merit.edu Sent: Friday, July 08, 2005 1:03 AM Subject: Re: OMB: IPv6 by June 2008 At 12:51 AM -0700 2005-07-08, Alexei Roudnev wrote: Who need this complexity? What's wrong with old good _routing rotocol_ approach? Memory? (do not joke, today 4 Gb RAM is not a problem, when it is for slow routing system). CPU (the same)? What else? Can you put 4GB on every linecard on every router you own? Can you put a Power5 or PowerPC 970MP processor on every linecard on every router you own? Does your vendor support you making any modifications/upgrades to any of their linecards, or do they require you to buy new ones with the go-faster features? And how many tens of thousands of dollars do each of those go-faster linecards cost? And how many million-dollar fork-lift upgrades do you have to pay for in order to get the go-faster chassis in which to plug those go-faster cards into? Do you have thousands of routers? Hundreds of thousands? I'm asking serious questions here. I'm not a router guy, but I've heard a lot of comments on this list that give me pause, so I'd like to get real-world answers. Speaking from my own perspective, it seems to me that we've got a scalability problem here when we're expecting most devices to have a pretty complete picture of the entire world. I think that's the real problem that has to be addressed. In terms of the routing protocols and number of ASes, we know that it's possible to build machines which can handle those kinds of things at those kinds of numbers. The problem is that it's hard to do those kinds of things on a widespread basis (e.g., in every linecard in every router in the world), and most devices probably don't need that anyway. I don't know what the real solution is. But it seems to me that we need to find something, and having people say 4GB of RAM? No problem is not the way to get this solved. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See http://www.sage.org/ for more info.
Re: OMB: IPv6 by June 2008
At 1:59 AM -0700 2005-07-08, Alexei Roudnev wrote: You do not need to - any router have only `1 - 10% of all routing table active, And do you have evidence to back up this claim? and it is always possible to optimize these alghoritms. Please feel free to do so. Then come back to us when you're done. On the other hand - what's wrong with 4Gb on line card in big core router? Because most of them aren't capable of supporting that? Maybe only the most expensive line cards which cost tens of thousands of dollars for just one card, and you have to have dozens or hundreds of such cards for a large Tier-1 network? Not to mention the hundreds of thousands or millions of dollars that you have to spend to get the ultra high-end chassis into which the expensive line cards have to be plugged in? It's cheap enough, even today. And we have not 1,000,000 routes yet. The please feel free to upgrade the entire Internet, and come back to us when you're done. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See http://www.sage.org/ for more info.
Re: OMB: IPv6 by June 2008
On 8-jul-2005, at 9:42, David Conrad wrote: There are some 45 - 50 /8s assigned to single organizations. Let's assume for simplicity that those can all be reclaimed. That's 4 years at a /8 a month. So far so good. Then there are 40 - 45 /8s in class B space. That means 256 times as much effort to reclaim the address space, or reclaiming about 10 class Bs a day... There is, of course, a slightly different model: As IPv4 address space becomes less freely available, there will be an increase in black and gray market transactions for that address space. Since these transactions involve actual money instead of the more difficult to account for human activity dealing with the RIRs or ISPs, there will be financial incentive both to reduce consumption as well as offer allocated but unused space via the black and gray markets. I'm not saying you're wrong (although the RIRs may do their best to stop the sale of address space, with unknown success), but I'm not sure this will make a huge difference. There are currently both holders of big chunks of address space, and holders of small chunks of address space, as well as organizations that burn up massive amounts of address space and those that use up very little. I can easily see how it makes sense for the users of relatively small amounts of address space to purchase or lease it from holders of (largely) unused /8s. At $1 per address, buying a /24 rather than jump through RIR hoops is probably a good deal for most people, while at $1 per address selling off your /8 is certainly worth the trouble. However, I don't think the likes of Comcast (which received 3 /10s or 3/4 of a /8 this year, or more than $12 million worth at our speculated $1/addr) are going to want to spend this kind of money as long as there is ANY chance they can get addresses from the RIRs. And then, think about it: how much money per address would you have to offer to someone with a spare /24 to part from those addresses? $1? $5? $10? I doubt the big ISPs that burn millions of addresses per year will be interested in that. Suddenly the transition to IPv6 (or recursive NAT...) is going to look very attractive. So basically the tradeoffs between market forces and regular reclaming are similar: easy for /8s, hard for /16s and close to impossible for /24s. And the real fun starts when people holding big blocks of address space start holding on to it because they expect to make more money that way in the future...
Re: OMB: IPv6 by June 2008
At 1:59 AM -0700 2005-07-08, Alexei Roudnev wrote: You do not need to - any router have only `1 - 10% of all routing table active, and it is always possible to optimize these alghoritms. If you've got proven solutions to all of the problems raised in RFC 3869, section 3.3, I'm sure we'd love to hear about them. Heck, if you've got even just one proven solution to one of those problems, we'd love to hear about them. But I think you're being more than a little disingenuous if you do not have proven solutions and simply roll out Let's replace all the Internet core routers with dirt-cheap PCs every time someone talks about an Internet routing scalability problem. Give me some evidence that you truly understand the problems of a Tier-1 provider, and that you've got real-world solutions, and I'd be perfectly happy to learn from whatever lessons you've got to teach. But even I am smart enough to figure out that the let them eat cake routine isn't particularly useful. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See http://www.sage.org/ for more info.
ATT CDPD
Can anyone tell me the status of CDPD in the ATT network? Thanks RonJ
Fw: ATT CDPD
- Original Message - From: Ronald W. Jean To: nanog@merit.edu Sent: Friday, July 08, 2005 8:00 AM Subject: ATT CDPD Can anyone tell me the status of CDPD in the ATT network? Thanks RonJ
The Cidr Report
This report has been generated at Fri Jul 8 21:46:31 2005 AEST.
The report analyses the BGP Routing Table of an AS4637 (Reach) router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org/as4637 for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
01-07-05161844 110253
02-07-05161945 110291
03-07-05161936 110251
04-07-05161979 110171
05-07-05161865 110332
06-07-05162173 110414
07-07-05162308 110338
08-07-05162251 110458
AS Summary
19872 Number of ASes in routing system
8171 Number of ASes announcing only one prefix
1481 Largest number of prefixes announced by an AS
AS7018 : ATT-INTERNET4 - ATT WorldNet Services
90546944 Largest address span announced by an AS (/32s)
AS721 : DLA-ASNBLOCK-AS - DoD Network Information Center
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 08Jul05 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 162376 1104545192232.0% All ASes
AS4323 1120 223 89780.1% TWTC - Time Warner Telecom
AS18566 8268 81899.0% COVAD - Covad Communications
AS4134 914 231 68374.7% CHINANET-BACKBONE
No.31,Jin-rong Street
AS721 1100 562 53848.9% DLA-ASNBLOCK-AS - DoD Network
Information Center
AS27364 555 22 53396.0% ACS-INTERNET - Armstrong Cable
Services
AS7018 1481 963 51835.0% ATT-INTERNET4 - ATT WorldNet
Services
AS7725 499 17 48296.6% CCH-AS7 - Comcast Cable
Communications Holdings, Inc
AS22773 499 25 47495.0% CCINET-2 - Cox Communications
Inc.
AS6197 927 506 42145.4% BATI-ATL - BellSouth Network
Solutions, Inc
AS3602 542 150 39272.3% SPRINT-CA-AS - Sprint Canada
Inc.
AS17676 437 81 35681.5% JPNIC-JP-ASN-BLOCK Japan
Network Information Center
AS6467 383 34 34991.1% ESPIRECOMM - e.spire
Communications, Inc.
AS9929 356 49 30786.2% CNCNET-CN China Netcom Corp.
AS4766 577 281 29651.3% KIXS-AS-KR Korea Telecom
AS14654 281 12 26995.7% WAYPORT - Wayport
AS6140 395 142 25364.1% IMPSAT-USA - ImpSat
AS15270 311 59 25281.0% AS-PAETEC-NET - PaeTec.net -a
division of
PaeTecCommunications, Inc.
AS5668 484 236 24851.2% AS-5668 - CenturyTel Internet
Holdings, Inc.
AS1239 883 639 24427.6% SPRINTLINK - Sprint
AS23126 260 20 24092.3% KMCTELCOM-DIA - KMC Telecom,
Inc.
AS4755 529 296 23344.0% VSNL-AS Videsh Sanchar Nigam
Ltd. Autonomous System
AS6167 300 67 23377.7% CELLCO-PART - Cellco
Partnership
AS2386 891 659 23226.0% INS-AS - ATT Data
Communications Services
AS6198 463 240 22348.2% BATI-MIA - BellSouth Network
Solutions, Inc
AS812242 20 22291.7% ROGERS-CABLE - Rogers Cable
Inc.
AS7545 503 287 21642.9% TPG-INTERNET-AP TPG Internet
Pty Ltd
AS9498 327 114 21365.1% BBIL-AP BHARTI BT INTERNET
LTD.
AS11456 312 99 21368.3% NUVOX - NuVox Communications,
Inc.
AS6478 378 167 21155.8% ATT-INTERNET3 - ATT WorldNet
Services
AS9583 757 564 19325.5% SIFY-AS-IN Sify Limited
Fw: ATT CDPD
Can anyone from the ATT/Cingular NOC contact me regarding CDPD. Thanks... - Original Message - From: Ronald W. Jean To: [EMAIL PROTECTED] Sent: Friday, July 08, 2005 8:03 AM Subject: Fw: ATT CDPD - Original Message - From: Ronald W. Jean To: nanog@merit.edu Sent: Friday, July 08, 2005 8:00 AM Subject: ATT CDPD Can anyone tell me the status of CDPD in the ATT network? Thanks RonJ
Re: OMB: IPv6 by June 2008
Rubbish. Many of the organizations that hold legacy /8s are Universities. If a .edu can pick up even a few million dollars from selling off a class A, they will. After all, they could simply sell chunks. $1 per IP address is the going rate, as I understand - not so much for grey market transactions, but as a valuation used in merger/divestiture situations. If we simultaneously start making address space fungible (#nanog vocabulary word of the day!) and keep giving it away from the RIRs folks will have a choice. Choice is good. As some point, as address space becomes scarce, it will become more valuable. As it becomes more valuable, people will be willing to spend more money to get addresses. This is basic economics. We have an artificially scarce (but finite) resource - the market can fix our problems. At some point, the cost of buying enough address space for a given service provider or enterprise will become more than the cost of implementing IPv6. The market will then drive v6 implementation. Our system of allocating IP addresses is a cross between soviet-style central planning and FCC spectrum allocation. That doesn't need to occur. We can morph the RIRs into commodity exchanges and solve the following issues: - irritation with RIR procedures for getting address space - justification for address space (cash is my justification) - worries about running out of address space as folks sell their hoarded space and the market loosens - motivation for shifting to v6 - there will be a real cost to using v4 addresses, but v6 addresses will be free. We can try to regulate the heck out of this, or let the market handle it. To quote Gorden Gecko, greed is good - at least for driving IPv6 adoption. - Dan On 7/8/05 5:27 AM, Iljitsch van Beijnum [EMAIL PROTECTED] wrote: On 8-jul-2005, at 9:42, David Conrad wrote: There are some 45 - 50 /8s assigned to single organizations. Let's assume for simplicity that those can all be reclaimed. That's 4 years at a /8 a month. So far so good. Then there are 40 - 45 /8s in class B space. That means 256 times as much effort to reclaim the address space, or reclaiming about 10 class Bs a day... There is, of course, a slightly different model: As IPv4 address space becomes less freely available, there will be an increase in black and gray market transactions for that address space. Since these transactions involve actual money instead of the more difficult to account for human activity dealing with the RIRs or ISPs, there will be financial incentive both to reduce consumption as well as offer allocated but unused space via the black and gray markets. I'm not saying you're wrong (although the RIRs may do their best to stop the sale of address space, with unknown success), but I'm not sure this will make a huge difference. There are currently both holders of big chunks of address space, and holders of small chunks of address space, as well as organizations that burn up massive amounts of address space and those that use up very little. I can easily see how it makes sense for the users of relatively small amounts of address space to purchase or lease it from holders of (largely) unused /8s. At $1 per address, buying a /24 rather than jump through RIR hoops is probably a good deal for most people, while at $1 per address selling off your /8 is certainly worth the trouble. However, I don't think the likes of Comcast (which received 3 /10s or 3/4 of a /8 this year, or more than $12 million worth at our speculated $1/addr) are going to want to spend this kind of money as long as there is ANY chance they can get addresses from the RIRs. And then, think about it: how much money per address would you have to offer to someone with a spare /24 to part from those addresses? $1? $5? $10? I doubt the big ISPs that burn millions of addresses per year will be interested in that. Suddenly the transition to IPv6 (or recursive NAT...) is going to look very attractive. So basically the tradeoffs between market forces and regular reclaming are similar: easy for /8s, hard for /16s and close to impossible for /24s. And the real fun starts when people holding big blocks of address space start holding on to it because they expect to make more money that way in the future... -- Daniel Golding Network and Telecommunications Strategies Burton Group
Re: ATT CDPD
On Fri, Jul 08, 2005 at 08:00:42AM -0400, Ronald W. Jean wrote: Can anyone tell me the status of CDPD in the ATT network? Scheduled to die soon, if it hasn't already. I was a second-tier CDPD sub, via Earthlink, until about a year ago; they took a hit to move me to 1xRTT, because the underlying networks were scheduled to go down, in keeping with the general decommissioning of analog AMPS, during this calendar year, as I understand it. It was extended because of a couple of large PD's who needed more time to switch (or amortize their gear; take your pick). http://www.google.com/search?q=cdpd+decommissioning Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: OMB: IPv6 by June 2008
On the subject of how many entities should be multihomed. Any entitiy whose operations would be significantly impacted by the loss of their connectivity to the global internet. A personal example with names withheld to protect the guilty A distributor who took 85% of their orders over the internet the rest was phone and EDI the telcom coordinator got a 'great deal' on Internet service and LD from an unnamed vendor. Well we cut over our links and within a week our major customers had trouble reaching us due to the SP relying only on the public peering points to exchange traffic with other networks. At that point I set up BGP got an AS and reconnected our new provider and our old provider so that we had service from both SP's A 30 year old company almost went out of business due to being single-homed. Being dependent on a single SP is a Bad Thing (tm) At 04:02 AM 7/8/2005, Alexei Roudnev wrote: Moreover, if you are not multihomned, you can be aggregated. If you became multihome - yes, you take a slot; how many entities in the world should be multihomed? - Original Message - From: Kuhtz, Christian [EMAIL PROTECTED] To: David Conrad [EMAIL PROTECTED]; Alexei Roudnev [EMAIL PROTECTED] Cc: Mohacsi Janos [EMAIL PROTECTED]; Daniel Golding [EMAIL PROTECTED]; Scott McGrath [EMAIL PROTECTED]; nanog@merit.edu Sent: Thursday, July 07, 2005 11:02 AM Subject: RE: OMB: IPv6 by June 2008 Alexei, On Jul 7, 2005, at 9:58 AM, Alexei Roudnev wrote: What's the problem with independent address space for every entity (company, family, enterprise) which wants it? It doesn't scale. Regardless of Moore's law, there are some fundamental physical limits that constrain technology. I would contend that is not true. What says that every device inside a company, family, enterprise etc has to be available and reachable by anyone on the planet in a bidirectional fashion as far as session initiation is concerned? Once you add that bit of reality to it, the scaling requirement goes down substantially. Wouldn't you agree? Trust me, I would like to just see us get it over with as far as IPv6 is concerned, provided we have a working, palatable IPv6 mh solution. But, man, I can't pass the red face test on a lot of these hypothesis :( Thanks, Christian The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 163
icc to itu: fix the analog divide before venturing digital
The International Telecoms Union (ITU) has been told by the International Chamber of Commerce (ICC) to focus more of its efforts on stimulating the growth of fixed line voice telephony in developing countries. The Swiss-led ICC, which represents global business interests, says that the ITU devotes too much of its focus to the technical management of the internet rather than the core issue of teledensity. The ITU has recently announced plans to wrest control of internet administration from the US-based Internet Corporation for Assigned Names and Numbers (ICANN).
Re: icc to itu: fix the analog divide before venturing digital
On Fri, Jul 08, 2005 at 05:31:26AM -1000, Randy Bush wrote: The International Telecoms Union (ITU) has been told by the International Chamber of Commerce (ICC) to focus more of its efforts on stimulating the growth of fixed line voice telephony in developing countries. The Swiss-led ICC, which represents global business interests, says that the ITU devotes too much of its focus to the technical management of the internet rather than the core issue of teledensity. The ITU has recently announced plans to wrest control of internet administration from the US-based Internet Corporation for Assigned Names and Numbers (ICANN). thanks. nice word ... teledensity. one does wonder if it remains cost effective to drag bits of wire around. --bill
Re: mh (RE: OMB: IPv6 by June 2008)
On Thu, Jul 07, 2005 at 01:31:57PM -0700, Crist Clark wrote: And if you still want the protection of NAT, any stateful firewall will do it. That seems a common viewpoint. I believe the very existence of the Ping Of Death rebuts it. A machine behind a NAT box simply is not visible to the outside world, except for the protocols you tunnel to it, if any. This *has* to vastly reduce it's attack exposure. Anyone with a pointer to an *in depth* explanation somewhere of why that assumption is invalid can mail it to me off list, and I'll shut up. Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: mh (RE: OMB: IPv6 by June 2008)
On Jul 8, 2005, at 12:49 PM, Jay R. Ashworth wrote:
On Thu, Jul 07, 2005 at 01:31:57PM -0700, Crist Clark wrote:
And if you still want the protection of NAT, any stateful firewall
will do it.
That seems a common viewpoint.
I believe the very existence of the Ping Of Death rebuts it.
A machine behind a NAT box simply is not visible to the outside world,
except for the protocols you tunnel to it, if any. This *has* to
vastly reduce it's attack exposure.
Not really. Consider the logic in a NAT box:
if (state table entry exists for packet) {
translate_header();
send();
} else {
drop();
}
and the logic in a stateful firewall:
if (state table entry exists for packet) {
send();
} else {
drop();
}
This is *exactly* the core of what a NAT does, minus the header
mangling. The ping of death exposure, for instance, is identical in
both cases: The way to ping of death someone is to find a valid state
table entry and exploit it (e.g., if you could do a PoD in reverse by
using a too-large ICMP reply, and first convince the victim to ping
you).
Configuration options can change the behavior of either, e.g.,
configuring an internal host to be the DMZ host on a NAT, which
changes the logic to:
if (state table) ...
else
send_to_dmz_host();
The equivalent operation on a stateful firewall is a permit rule. A
stateful firewall can expose more internal hosts to the outside than a
NAT with only one IP address, simply because it can have more
addressable space to use (if you've only got one IP address, there's
only one person who can receive pings). But in general, the two are
nearly identical, by virtue of the state table check.
-Dave
Re: OMB: IPv6 by June 2008
On Fri, 8 Jul 2005, Brad Knowles wrote: It's cheap enough, even today. And we have not 1,000,000 routes yet. The please feel free to upgrade the entire Internet, and come back to us when you're done. You keep using the entire internet in your replies, when I was under the assumption that we were discussing the inter-provider DFZ. The only routers which could possibly be affected by the prefix bloat problem would be multi-homed and mostly inter-provider, which is a small fraction of all routers on the internet. I'm not trying to accuse you of anything, but your arguments are beginning to sound like a disingenuous straw-man. matto [EMAIL PROTECTED]darwin The only thing necessary for the triumph of evil is for good men to do nothing. - Edmund Burke
Re: mh (RE: OMB: IPv6 by June 2008)
On Jul 8, 2005, at 9:49 AM, Jay R. Ashworth wrote: A machine behind a NAT box simply is not visible to the outside world, except for the protocols you tunnel to it, if any. This *has* to vastly reduce it's attack exposure. It is true that the exposure is reduced, just as it is with a stateful firewall. The technical term for this is security by obscurity. Being obscure, however, is not the same as being invisible or being protected. It just means that you're a little harder to hit. When a NAT sets up an association between an inside and outside address+port pair, that constitutes a bridge between the inside device and the outside world. There are ample attacks that are perpetrated through that association. A NAT, in that context, is a stateful firewall that changes the addresses, which means that the end station cannot use IPSEC to ensure that it is still talking with the same system on the outside. It is able to use TLS, SSH, etc as transport layer solutions, but those are subject to attacks on TCP such as RST attacks, data insertion, acknowledge hacking, and so on, and SSH also has a windowing problem (on top of TCP's window, SSH has its own window, and in large delay*bandwidth product situations SSH's window is a performance limit). In other words, a NAT is a man-in-the-middle attack, or is a device that forces the end user to expose himself to man-in-the-middle attacks. A true stateful firewall that allows IPSEC end to end doesn't expose the user to those attacks.
Re: mh (RE: OMB: IPv6 by June 2008)
On Fri, Jul 08, 2005 at 01:15:42PM -0400, David Andersen wrote: On Jul 8, 2005, at 12:49 PM, Jay R. Ashworth wrote: On Thu, Jul 07, 2005 at 01:31:57PM -0700, Crist Clark wrote: And if you still want the protection of NAT, any stateful firewall will do it. That seems a common viewpoint. I believe the very existence of the Ping Of Death rebuts it. A machine behind a NAT box simply is not visible to the outside world, except for the protocols you tunnel to it, if any. This *has* to vastly reduce it's attack exposure. Not really. Consider the logic in a NAT box: [ ... ] and the logic in a stateful firewall: Sorry. Given my other-end-of-the-telescope perspective, I was envisioning an *on-machine* firewall, rather than a box. Clearly *any* sort of box in the middle helps in the fashion I alluded to, whether it NATs or not. Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: mh (RE: OMB: IPv6 by June 2008)
On 8-jul-2005, at 19:34, Fred Baker wrote: A NAT, in that context, is a stateful firewall that changes the addresses, which means that the end station cannot use IPSEC to ensure that it is still talking with the same system on the outside. It is able to use TLS, SSH, etc as transport layer solutions, but those are subject to attacks on TCP such as RST attacks, data insertion, acknowledge hacking, and so on, and SSH also has a windowing problem (on top of TCP's window, SSH has its own window, and in large delay*bandwidth product situations SSH's window is a performance limit). In other words, a NAT is a man-in- the-middle attack, or is a device that forces the end user to expose himself to man-in-the-middle attacks. :-) A true stateful firewall that allows IPSEC end to end doesn't expose the user to those attacks. I of course couldn't resist, so: ! ipv6 access-list out-ipv6-acl permit ipv6 any any reflect state-acl ! ipv6 access-list in-ipv6-acl evaluate state-acl deny ipv6 any any log ! (don't try this at home, kids: that deny any is dangerous because it blocks neighbor discovery) Unfortunately, IPsec (ESP transport mode) isn't allowed back in: %IPV6-6-ACCESSLOGNP: list in-ipv6-acl/20 denied 50 2001:1AF8:2:5::2 - 2001:1AF8:6:0:20A:95FF:FEF5:246E, 29 packets On second thought: how could it? The SPIs for outgoing and incoming packets are different. I suppose it would be possible for the stateful filter to snoop the ISAKMP protocol and install filter rules based on the information found there, but that's obviously not what happens.
Re: mh (RE: OMB: IPv6 by June 2008)
Jay R. Ashworth wrote: On Fri, Jul 08, 2005 at 01:15:42PM -0400, David Andersen wrote: On Jul 8, 2005, at 12:49 PM, Jay R. Ashworth wrote: On Thu, Jul 07, 2005 at 01:31:57PM -0700, Crist Clark wrote: And if you still want the protection of NAT, any stateful firewall will do it. That seems a common viewpoint. I believe the very existence of the Ping Of Death rebuts it. A machine behind a NAT box simply is not visible to the outside world, except for the protocols you tunnel to it, if any. This *has* to vastly reduce it's attack exposure. Not really. Consider the logic in a NAT box: [ ... ] and the logic in a stateful firewall: Sorry. Given my other-end-of-the-telescope perspective, I was envisioning an *on-machine* firewall, rather than a box. Clearly *any* sort of box in the middle helps in the fashion I alluded to, whether it NATs or not. Now I'm confused. Who runs *on-machine* NAT? I guess that's another nice option for firewalls. It doesn't matter whether your firewall runs locally or on a remote gateway. Also, when people here are talking about NAT, note that we are only talking about many-to-one, overloading, PAT, or whatever you want to call it. If you are using NAT pools or one-to-one NAT, it buys you no protection at all unless you add firewalling to the mix. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: mh (RE: OMB: IPv6 by June 2008)
Fred Baker wrote: [snip] A NAT, in that context, is a stateful firewall that changes the addresses, which means that the end station cannot use IPSEC to ensure that it is still talking with the same system on the outside. [snip] No, you can't use AH, but yes, you can use IPsec through NAT. See RFC3947 and RFC3948. But it is not pretty. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: mh (RE: OMB: IPv6 by June 2008)
On 7 Jul, 2005, at 21:10, Steven M. Bellovin wrote: Real firewalls pass inbound traffic because a state table entry exists. NATs do the same thing, with nasty side-effects. There is no added security from the header-mangling. To which Len Bosak quipped a few years ago: If you don't know its name, you can't curse it. Sean.
New IANA IPv6 allocation for APNIC (2400:2000::/19)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings, This is to inform you that the IANA has allocated the following one (1) IPv6 /19 block to APNIC: ~ 2400:2000::/19APNIC For a full list of IANA IPv6 allocations please see: http://www.iana.org/assignments/ipv6-unicast-address-assignments - -- Doug Barton General Manager, The Internet Assigned Numbers Authority -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCzvPowtDPyTesBYwRAlciAKCeR86MJyCmtjbP/MxviXIM6yT8ugCeL9XJ vPlR8n8sUyDaEEnsXIFm5zE= =/Kd+ -END PGP SIGNATURE-
Re: OMB: IPv6 by June 2008
Brad Knowles wrote: At 10:30 AM -0700 2005-07-08, Matt Ghali wrote: You keep using the entire internet in your replies, when I was under the assumption that we were discussing the inter-provider DFZ. The only routers which could possibly be affected by the prefix bloat problem would be multi-homed and mostly inter-provider, which is a small fraction of all routers on the internet. They're the biggest and most expensive routers on the Internet, and if the routing table were to be allowed to grow without bounds, they wouldn't be the only ones that would need to be replaced. Everyone else would very soon have the exact same problem. And there are enough of them that you'd probably spend more money upgrading them than upgrading all the other routers in the world. The biggest routers are being upgraded anyway because of even higher link speeds and port desities. A Cisco CRS-1 16-SLOT LINE-CARD CHASSIS ROUTE PROCESSOR comes with 4 GB of route memory default size. Juniper's T320 and T640 come with 2 GB of main memory default size. That should take them to some higher number of routes. On the other hand a large DFZ routing table would simply dampen its growth by itself. If it gets to costly to multihome because of the hardware requirements only few would be able to so. Ergo we have a negative feedback system here keeping itself in check. Case solved and closed. -- Andre
Re: mh (RE: OMB: IPv6 by June 2008)
On 8 Jul, 2005, at 18:34, Fred Baker wrote: A NAT, in that context, is a stateful firewall that changes the addresses, which means that the end station cannot use IPSEC to ensure that it is still talking with the same system on the outside. Only if you define IPSEC narrowly as AH in order to justify this claim. There are at least two interesting differences between a NAT and a stateful firewall deployed in front of hosts with permanent public address space. The first involves attackers knowing the topological name of a victim who may be unshielded by the firewall during narrow windows offered by the implementation, its operators, or both in combination. The second involves a predictable rendezvous point for covert communications channels. Not all NATs protect against these classes of attack, however an implementation that assigns inside-outside mappings with reasonable randomness will. One which also breaks connections on failures (by invalidating existing mappings) is more fail-safe than one that tries to preserve existing state across crashes or fat-fingerings. People who don't make use of an interoperable and well understood session protocol resilient against this variety of failure in connection-oriented transport communications (identity/locator binding invalidation) will probably disagree as their various long- lived sessions terminate abnormally... Applications-layer protocol writers without a session layer would also have to worry about: attacks on TCP such as RST attacks, data insertion, acknowledge hacking, and so on Planned renumbering may as a side effect result in all of the three such attacks you explicitly listed. They may also be flummoxed by having to invent a session layer for an application that really wants one, leading to reinventing previously discovered gotchas like in large delay*bandwidth product situations SSH's window is a performance limit Finally: In other words, a NAT is a man-in-the-middle attack, or is a device that forces the end user to expose himself to man-in-the-middle attacks. A true stateful firewall that allows IPSEC end to end doesn't expose the user to those attacks. The men in the middle are the I* officers who have refused for more than a decade to admit they don't know everything, that market forces are not always driven by evil doing architectural impurists with nothing to teach their elders (which is incongruous with early I* tensions with the former CCITT), or that they have their heads buried neck deep in NIH kitty litter (ditto). A NAT is a tool many people find useful enough to deploy, maintain and even pay money for, despite the ready availability of substitutable tools, and The IP (both flavours) network and transport layers are very badly designed with respect to host renumbering. Renumbering has been a fact of life since before the early 90s. There is no as-widely- promoted-as-TCP session layer to help mitigate renumbering's effects. There is also institutional resistence to fixing this aspect of the design of the N+T layers in I*. So, people who have actually deployed and run networks where renumberings happen, deployed NATs simply because that was one of the only solutions readily and mostly interoperably available to them. It is unsurprising that the voluntary standards organization dominated by people who have fought against technology to cope with (or even embrace) live renumbering is likewise ridden with loudmouths who call NATs attacks. What is it exactly that NATs attack, Fred? Sean.
Re: OMB: IPv6 by June 2008
On Sat, Jul 09, 2005 at 12:08:08AM +0200, Andre Oppermann wrote: On the other hand a large DFZ routing table would simply dampen its growth by itself. If it gets to costly to multihome because of the hardware requirements only few would be able to so. Ergo we have a negative feedback system here keeping itself in check. Case solved and closed. Multihomed end sites usually get away with receiving only default route or some partial routes from their upstreams. So technically you can BGP multihome with Cisco 1600 or even smaller easily (dunno where BGP support is starting to become available). Regards, Daniel -- CLUE-RIPE -- Jabber: [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- PGP: 0xA85C8AA0
Re: mh (RE: OMB: IPv6 by June 2008)
On 8 Jul, 2005, at 18:34, Fred Baker wrote: A NAT, in that context, is a stateful firewall that changes the addresses, which means that the end station cannot use IPSEC to ensure that it is still talking with the same system on the outside. Only if you define IPSEC narrowly as AH in order to justify this claim. There are at least two interesting differences between a NAT and a stateful firewall deployed in front of hosts with permanent public address space. The first involves attackers knowing the topological name of a victim who may be unshielded by the firewall during narrow windows offered by the implementation, its operators, or both in combination. The second involves a predictable rendezvous point for covert communications channels. Not all NATs protect against these classes of attack, however an implementation that assigns inside-outside mappings with reasonable randomness will. One which also breaks connections on failures (by invalidating existing mappings) is more fail-safe than one that tries to preserve existing state across crashes or fat-fingerings. People who don't make use of an interoperable and well understood session protocol resilient against this variety of failure in connection-oriented transport communications (identity/locator binding invalidation) will probably disagree as their various long- lived sessions terminate abnormally... Applications-layer protocol writers without a session layer would also have to worry about: attacks on TCP such as RST attacks, data insertion, acknowledge hacking, and so on Planned renumbering may as a side effect result in all of the three such attacks you explicitly listed. They may also be flummoxed by having to invent a session layer for an application that really wants one, leading to reinventing previously discovered gotchas like in large delay*bandwidth product situations SSH's window is a performance limit Finally: In other words, a NAT is a man-in-the-middle attack, or is a device that forces the end user to expose himself to man-in-the-middle attacks. A true stateful firewall that allows IPSEC end to end doesn't expose the user to those attacks. The men in the middle are the I* officers who have refused for more than a decade to admit they don't know everything, that market forces are not always driven by evil doing architectural impurists with nothing to teach their elders (which is incongruous with early I* tensions with the former CCITT), or that they have their heads buried neck deep in NIH kitty litter (ditto). A NAT is a tool many people find useful enough to deploy, maintain and even pay money for, despite the ready availability of substitutable tools, and The IP (both flavours) network and transport layers are very badly designed with respect to host renumbering. Renumbering has been a fact of life since before the early 90s. There is no as-widely- promoted-as-TCP session layer to help mitigate renumbering's effects. There is also institutional resistence to fixing this aspect of the design of the N+T layers in I*. So, people who have actually deployed and run networks where renumberings happen, deployed NATs simply because that was one of the only solutions readily and mostly interoperably available to them. It is unsurprising that the voluntary standards organization dominated by people who have fought against technology to cope with (or even embrace) live renumbering is likewise ridden with loudmouths who call NATs attacks. What is it exactly that NATs attack, Fred? Sean.
Re: mh (RE: OMB: IPv6 by June 2008)
On Fri, Jul 08, 2005 at 10:24:22PM +0100, Sean Doran wrote: On 7 Jul, 2005, at 21:10, Steven M. Bellovin wrote: Real firewalls pass inbound traffic because a state table entry exists. NATs do the same thing, with nasty side-effects. There is no added security from the header-mangling. To which Len Bosak quipped a few years ago: If you don't know its name, you can't curse it. Sure you can. For a human entity, get a few hairs from its head or nail clippings. For a network entity, get the bits of its externally visible IP address. -- Joe Yao --- This message is not an official statement of OSIS Center policies.
Re: OMB: IPv6 by June 2008
At 12:08 AM +0200 2005-07-09, Andre Oppermann wrote: The biggest routers are being upgraded anyway because of even higher link speeds and port desities. I'm not surprised. After all, time does march on. But it doesn't help if the largest/fastest line cards available today are made obsolete overnight by people who have no concept of what it costs to route packets at OC-192 or OC-768 line speeds, and suggest that all the routers in the world could be replaced by a small handful of no-name el-cheapo PCs. A Cisco CRS-1 16-SLOT LINE-CARD CHASSIS ROUTE PROCESSOR comes with 4 GB of route memory default size. Juniper's T320 and T640 come with 2 GB of main memory default size. That should take them to some higher number of routes. Problem is, a Tier-1 provider is still going to have hundreds or thousands of routers that have to be upgraded, and there are a number of Tier-1s. Tier-2s aren't quite as bad off, but although they buy some transit from the Tier-1s, they still have a lot of private peering and they're not that far out of the DFZ themselves. And the Tier-2s have a lot less money to pay for the ultra-expensive forklift upgrades for the BFRs and GSRs and all that other mega-million dollar equipment. Meanwhile, a surprising number of people have to try and get by with linecards having only 128MB of RAM, at least according to RFC 3869. On the other hand a large DFZ routing table would simply dampen its growth by itself. If it gets to costly to multihome because of the hardware requirements only few would be able to so. Ergo we have a negative feedback system here keeping itself in check. Case solved and closed. And Volcanoes nicely solve the population problem for those who live too close to them. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See http://www.sage.org/ for more info.
Re: OMB: IPv6 by June 2008
Daniel Roesen wrote: On Sat, Jul 09, 2005 at 12:08:08AM +0200, Andre Oppermann wrote: On the other hand a large DFZ routing table would simply dampen its growth by itself. If it gets to costly to multihome because of the hardware requirements only few would be able to so. Ergo we have a negative feedback system here keeping itself in check. Case solved and closed. Multihomed end sites usually get away with receiving only default route or some partial routes from their upstreams. So technically you can BGP multihome with Cisco 1600 or even smaller easily (dunno where BGP support is starting to become available). Technically yes, practically no. At least not for the purposes people normally want to multihome. -- Andre
Re: OMB: IPv6 by June 2008
At the risk of continuing this bad flashback... A Cisco CRS-1 16-SLOT LINE-CARD CHASSIS ROUTE PROCESSOR comes with 4 GB of route memory default size. Juniper's T320 and T640 come with 2 GB of main memory default size. That should take them to some higher number of routes. No, sorry, that's route processor memory and has nothing to do with the forwarding table. Actual forwarding in a distributed architecture has to be distributed to the line card. Further, given modern forwarding rates, typical PC DRAM (50-70ns) is vastly inadequate. Instead, higher speed SRAM (2-8ns) is a necessity. The cost differential between these two technologies is quite large. And we won't even open the subject about what that memory is *really* getting used for. On the other hand a large DFZ routing table would simply dampen its growth by itself. If it gets to costly to multihome because of the hardware requirements only few would be able to so. Ergo we have a negative feedback system here keeping itself in check. Case solved and closed. The costs for multihoming are borne by everyone *else* in the network who has to carry the extra prefixes. Further, market pressures force carriers to advertise customer prefixes regardless of the costs to the remainder of the network. Case not solved. Multihoming can never be just a small portion of the growth of the DFZ table, as multihoming so far appears to be a fixed percentage of the sites on the net. Thus, even if we solve all of the single-homed sites through good aggregation, if we do not solve the multi-homed sites properly, their numbers will continue along the same growth curve, only time shifted, and will eventually dwarf the current routing table. Before we continue this thread, folks might want to reread the CIDR archives from a decade ago. We are still having the exact same argument, with the exact same conclusions and the exact same results. Yes, the scale has changed slightly, but we are nowhere closer to a true solution. Tony
Re: OMB: IPv6 by June 2008 (OT reminder)
At 9:46 AM -0400 7/8/05, Someone wrote: We can morph the RIRs into ... As a slight aside and w/o any comment on the particular morph'ing proposed, I'd like to remind folks that 2 seats on the ARIN Board of Trustees, and 5 seats on ARIN Advisory Council will be filled later this year, and one of the best ways to morph ARIN to meet the needs of the community is the nomination of clueful folks to serve in these roles. Nominations are due by July 29th, and additional information is available at: http://www.arin.net/elections/index.html Thanks! (and you're being returned to the normal tirade, already in progress... :) /John Chair, ARIN
Re: OMB: IPv6 by June 2008
On Sat, Jul 09, 2005 at 12:52:35AM +0200, Andre Oppermann wrote: Multihomed end sites usually get away with receiving only default route or some partial routes from their upstreams. So technically you can BGP multihome with Cisco 1600 or even smaller easily (dunno where BGP support is starting to become available). Technically yes, practically no. At least not for the purposes people normally want to multihome. I cannot confirm this observation from my experience supporting a number of customers with their multihoming setups that I've either designed myself or supported as part of managed internet access solutions. I _did_ see several badly designed setups though that had full tables (and associated hardware overkill) but didn't need it. Consequence: wasted money, worse convergence times and routers falling over because of RAM depletion and fragmentation over time. Regards, Daniel -- CLUE-RIPE -- Jabber: [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- PGP: 0xA85C8AA0
Re: OMB: IPv6 by June 2008
Small detail: On 6 Jul, 2005, at 16:30, David Conrad wrote: If IPv6 had actually addressed one or more of routing scalability, multi-homing, or transparent renumbering These are the same problem, looked at in different ways. The issue is: graph-sorting scalability demands abstraction; abstraction demands abstraction boundaries; abstraction boundaries must be reflected in node names (i.e., locators); nodes are physically portable, topologically portable, or both. To be fair, mass deployment of local wireless LANs for large numbers of people with portable equipment they carry with them from meeting to hotel room to coffee shop to airport lounge to home would not have been the obvious future for anyone in the ROAD process. However, this is today's reality, and the movement of named things is more likely to increase than not. Stretchy LISes has mostly hidden the physical portable aspect of named things. Bridging is ancient and well-understood. Logical portability happens too, for individual named things and varying-sized collections of them. The stretchy LIS approach works at a cost of header overhead and inefficient traffic flow. The widespread use of VPNs demonstrates this well. The alternative is to deal with disjunctions between the named thing and its topological location. Model A: you go from office to IETF meeting, the IP address you use to talk to the world stays the same, and comes from your office's address space. You use VPN technology to make this happen. Model B: you go from office to IETF meeting, and the IP address you use to talk to the world comes from the IETF meeting's address space. Now go to your hotel room. Model A: your socket-like things are still bound to the office address, and if you walked briskly enough, your sessions are likely still alive when you reconnect to your office with the VPN tech. Model B: oops, you have a new address. You can't use the old address. Your sessions are very likely toast. Good thing there are tools like screen(1) and restartable ftp! The difference between A and B is independent of the header formats, so long as the named thing normally overloads its identity and location. Model A allows for a disjunction between the identity and location, by bridging through the real topology to connect to a distant collection of addresses, abstracted via variable-length prefixes. Model B does not allow for a disjunction in the absence of a session protocol, in which case the session layer identifier is the named thing, and the current IP address is the locator. The session layer does not have to be particularly heavyweight, it does not have to be distinctly above the network and transport layers, it does not have to be the only session support available to the other protocols in use between communicating entities. Integrating renumbering-adaptability within the lower (N/T) has some attractions especially with regard to preserving the traditional datagram and octet-stream modes, reducing the peer-to-peer handshaking in the event of renumbering of one of the parties, and in leveraging the current DNS architecture. It would also eliminate the market need for NAT as a tool to assist in -- or avoid -- large-scale simultaneous renumbering as when a single-homed site switches ISPs. Instead, IPv6 dealt with a problem that, for the most part, does not immediately affect the US market but which (arguably) does affect the other regions. I guess you can, if you like, blame it on the accountants... People should blame it on the multiplexors. There is lots of scope for multiplexing address use: not everyone is awake and powered on simultaneously; not everyone really does need to accept inbound connections from *everywhere*, at least not all the time; not everyone needs to run a particular service on the same numbered port; some services are fine with uniqueness involving network-layer-addresss+protocol+port(+possible other things). NAT, like other forms of multiplexing the Internet has benefited from (e.g. TDM, WDM, time-sharing operating systems, ...), can allow for more efficient in one's use of limited resources -- in this case, aggregated address space -- in a way accountants seem able to cope with. Yes, TANSTAAFL. Sean.
Re: OT? /dev/null 5.1.1 email
On Wed, Jul 06, 2005 at 12:08:23AM -0400, [EMAIL PROTECTED] wrote: What about setting your highest order MX and lowest order MX to point to the same set of mail servers, and hide your backup servers in the middle. Devious. ;) Another: highest MX pointing to server which only responds after 5-10 secs with 451 instead of 220-hello -- MTAs will try different MX, spammers will try to send or disconnect, but mails will be rejected anyway. p. -- Beware of he who would deny you access to information, for in his heart he dreams himself your master. -- Commissioner Pravin Lal
Re: OMB: IPv6 by June 2008
On 8 Jul 2005, at 19:26, Daniel Roesen wrote: On Sat, Jul 09, 2005 at 12:52:35AM +0200, Andre Oppermann wrote: Multihomed end sites usually get away with receiving only default route or some partial routes from their upstreams. So technically you can BGP multihome with Cisco 1600 or even smaller easily (dunno where BGP support is starting to become available). Technically yes, practically no. At least not for the purposes people normally want to multihome. I cannot confirm this observation from my experience supporting a number of customers with their multihoming setups that I've either designed myself or supported as part of managed internet access solutions. Multi-homing is a tool used in the real network to protect against various failure modes. Some failure modes (e.g. last-mile link failure) can receive protection using a small router receiving multiple defaults. Other failure modes require a full table (e.g. link failure between the ISP and its upstream, or some other partial withdrawal of connectivity). The appropriate architecture depends on the needs of the site in question. One size does not fit all. Joe
