Slashdot Mirror

That's Cogent and Hurricane Electric - Nanog thread

It's been going on a long time. Here's a peering cake from 2009.

Hmm...did you write this article? LOL! They describe the exact same situation. My Motorola 3801HGV seems to be passing IPv6; well, at least ping6 works and Google's mail server has stopped complaining after I implemented IPv6 on my mail server that's attached to the 3801HGV. But that article gives some ideas on how to get AT&T to send you a better router for free (eventually lol); just expect to spend some time on the phone. Also, if you do go that route, you can contact the "Office of the President" at rs2982@att.com; they've got several full-time staffers that handle any contacts and usually will actually call you within 24 hours and will actually try to fix whatever. I used to work as an AT&T CSR, we considered that the "nuclear option" for upset customers lol.

Not giving everyone a /48 is a daft argument. From someone who is a lot smarter than me source

"Let’s assume that ISPs come in essentially 3 flavors. MEGA (The Verizons, AT&Ts, Comcasts, etc. of the world) having more than 5 million customers, LARGE (having between 100,000and 5 million customers) and SMALL (having fewer than 100,000 customers).

Let’s assume the worst possible splits and add 1 nibble to the minimum needed for each ISP and another nibble for overhead.

Further, let’s assume that 7 billion people on earth all live in individual households and that each of them runs their own small business bringing the total customer base worldwide to 14 billion.

If everyone subscribes to a MEGA and each MEGA serves 5 million customers, we need 2,800 MEGA ISPs. Each of those will need 5,000,000 /48s which would require a /24. Let’s give each of those an additional 8 bits for overhead and bad splits and say each of them gets a /16. That’s 2,800 out of
65,536 /16s and we’ve served every customer on the planet with a lot of extra overhead, using approximately 4% of the address space.

Now, let’s make another copy of earth and serve everyone on a LARGE ISP with only 100,000 customers each. This requires 140,000 LARGE ISPs each of whom will need a /28 (100,000 /48s doesn’t fit in a /32, so we bump them up to /28). Adding in bad splits and overhead at a nibble each, we give each of them a /20. 140,000 /20s out of 1,048,576 total of which we used 44,800 for the MEGA ISPS leaves us with 863,776 /20s still available. We’ve now managed to burn approximately 18% of the total address space and we’ve served the entire world twice.

Finally, let us serve every customer in the world using a small ISP. Let’s assume that each small ISP only serves about 5,000 customers. For 5,000 customers, we would need a /32. Backing that off two nibbles for bad splits and overhead, we give each one a /24.

This will require 2,800,000 /24s. (I realize lots of ISPs server fewer than 5,000 customers, but those ISPs also don’t serve a total of 14 billion end sites,
so I think in terms of averages, this is not an unreasonable place to throw the dart).

There are 16,777,216 /24s in total, but we’ve already used 2,956,800 for the MEGA and LARGE ISPs, bringing our total utilization to 5,756,800 /24s.

We have now built three complete copies of the internet with some really huge assumptions about number of households and businesses added in and we still have only used roughly 34% of the total address space, including nibble boundary round-ups and everything else."

A revoked certificate or a mess up by the RIR will *not* result in an unreachable network. It's possibly the biggest misconception about RPKI. http://mailman.nanog.org/piper...

I think you need to learn how routing protocols work. I will give you a hint, unless they are using 20+ year old protocols like RIP v1

I don't think you have worked for a real provider for quite a few years. RIP v1 (which is way more than 20 years old) has been effectively dead for years. Every provider has used either OSPF or ISIS for years. A few smaller providers may still use EIGRP, a pretty good proprietary protocol developed by Cisco. This goes back to at least the beginning of the commercialization of the Internet in the late 90s.

But these shortest-path protocols are only used for "interior" routing. That is, within a single administrative domain, like Verizon or Comcast or the University of California at Berkeley. (All of these entities actually have more than one administrative domain to make things manageable or to deal with organizational requirements.)

Between these domain a border protocol, BGPv4 is universal. It is also fairly stupid as it has no information on the interiors of the networks it is talking to. Instead it has a set of metrics that decide what routes to prefer and filter to control what routes are even accepted from neighbors (usually called 'peers'). There are very few metrics. the main one is called AS path length, or the number of administrative domains between points. It is fairly common to edit this path to make one or another path preferred, usually to prefer less expensive paths. Use the free or cheap path if you can and only use the relatively expensive path when there is no other choice. This is a gross over-simplification, but his i not a networking class.

The North American Network Operators Group (NANOG) has several excellent tutorials on routing protocols free on-line if you want to learn more, but, as simple s BGP is, the actual ways it is implemented get very arcane.

Netflix would probably be interested in evidence that Verizon is deliberately limiting traffic. I'm sure that they would be delighted to hear from anyone who can provide things like records of chats or e-mail where Verizon employees makes statements demonstrating this.

I think you need to learn how routing protocols work. I will give you a hint, unless they are using 20+ year old protocols like RIP v1

I don't think you have worked for a real provider for quite a few years. RIP v1 (which is way more than 20 years old) has been effectively dead for years. Every provider has used either OSPF or ISIS for years. A few smaller providers may still use EIGRP, a pretty good proprietary protocol developed by Cisco. This goes back to at least the beginning of the commercialization of the Internet in the late 90s.

But these shortest-path protocols are only used for "interior" routing. That is, within a single administrative domain, like Verizon or Comcast or the University of California at Berkeley. (All of these entities actually have more than one administrative domain to make things manageable or to deal with organizational requirements.)

Between these domain a border protocol, BGPv4 is universal. It is also fairly stupid as it has no information on the interiors of the networks it is talking to. Instead it has a set of metrics that decide what routes to prefer and filter to control what routes are even accepted from neighbors (usually called 'peers'). There are very few metrics. the main one is called AS path length, or the number of administrative domains between points. It is fairly common to edit this path to make one or another path preferred, usually to prefer less expensive paths. Use the free or cheap path if you can and only use the relatively expensive path when there is no other choice. This is a gross over-simplification, but his i not a networking class.

The North American Network Operators Group (NANOG) has several excellent tutorials on routing protocols free on-line if you want to learn more, but, as simple s BGP is, the actual ways it is implemented get very arcane.

Netflix would probably be interested in evidence that Verizon is deliberately limiting traffic. I'm sure that they would be delighted to hear from anyone who can provide things like records of chats or e-mail where Verizon employees makes statements demonstrating this.

Agreed, the "super powers" aren't that super. On the other hand there are some very simple things that many people screw up. For example, people often get inbound and outbound confused, and forget that "me to X" and "X to me" are often separate problems. Asymmetric routing, where networks hand packets off early to the network with more detailed knowledge of the destination, is a great thing, but many people don't get it. Traceroute is a great tool for getting information, but the return path trips people up all the time. Here are some great notes on interpreting it.

Why just 400Gbps if they figure they need 1Tbps by the year after next?

It's down to what is possible in the next few years. 100G was originally implemented as 4 lanes of 25Gbit/s, which was challenging on the electronics side. There is also now a cheaper technology with 10 lanes of 10Gbit/s. To get further you need both more parallelism and higher speed serialization-deserialization. However, increasing either of these numbers comes with a cost. 400G looks possible with 16 lanes of 25Gbit/s, but an increase to 25 x 40Gbit/s would be very difficult indeed. Here's a link to a NANOG presentation - http://www.nanog.org/meetings/nanog52/abstracts.php?pt=MTc2MSZuYW5vZzUy&nm=nanog52

One of the biggest hold ups to IPV6 implementation is those IP (tier 1 and above) companies that own IPV4 addresses. Now a salable commodity the IPV4 addresses are becoming more valuable as scarcity increases. The volume of IPv4 traffic makes it a more lucrative revenue stream. Implementing V6 will make those V4 addresses worthless, and so where is the incentive to change? Politics and people

Come to think of it, I don't really think IPv6 is going to fare any better if efficiency is not enforced.

The short answer is we have 16 billion billion networks (with many hosts on each), compared to 4 billion unique host addresses.

The longer answer (from someone at HE who has done the math): http://mailman.nanog.org/pipermail/nanog/2012-July/050298.html

The calculation shows how long it might take to use up one eighth of the possible space. Our grandchildren can always change the policies at that stage. It depends what you mean by "efficiency", but it takes a lot of effort to run out when giving out /48s to end users and businesses.

It seems that we have been running out of addresses for 10 years or something and everyone has been talking about moving to IPv6 since the late ninteties ?

When the internet was initially developed it used a simple but horriblly wasteful system known of as classfull routing. Addresses were divided into classes and from each of three classes* blocks of a particular size were allocated. This system meant that many organisations ended up with a block far bigger than they really needed (many of which are being sold now) and it meant that a particular size of block could run out before all addresses did.

In the early ninties it became clear that if this system was continued addresses would quickly run-out and it was replaced in the ninties (afaict the actual replacement was somewhat gradual) by the more efficient classless system we have today where blocks of any power of two size can be allocated anywhere in the unicast address space. This improved efficiency and combined with many institutions choosing to use NAT rather than public IPs for most of their systems it bought us some time.

Unfortunately rather than spending that time ensuring that all new network equipment was suitable for** IPv6 and pushing IPv6 to customers as soon as the infrastructure was ready most providers sat on their hands waiting for everyone else to move first. CPE vendors also formed a blockage to getting IPv6 to end users natively.

So here we are, it's 2012, the IANA and APNIC have run out of v4 addresses for regular allocation. RIPE and ARIN still have some supply but will be running out within the next couple of years if current trends continue [1]. AFRINIC and LACNIC have longer projections but once RIPE and ARIN run out i'd expect to see some "RIR shopping" action deplete their pools as well . Meanwhile a large proportion of end users either lack access to the IPv6 internet or have it through the fragile nat poking automatic tunnelling system known as teredo.

Worse due to microsofts refusal to backport SNI support to XP and google inexplicablly not including it in andriod 2.x SSL websites still require dedicated IPs (which as mentioned above need to be IPv4).

Given the current levels of IPv6 penatration and the time it takes to push major changes through there will still be a real need for V4 addresses in hosting when RIPE and ARIN run out of addresses. At that point the only real option for hosting will be to buy IPs on the open market at gradually increasing prices (I wonder just what price it will take to make it worthwhile for the end-luser ISPs to deploy ISP level NAT to free up addresses for sale)

I am sure there is a limited range of numbers and the issue is real but also seems like fodder for sensationalist tech journal articles.

Well yeah that is what journalists do, the sky isn't going to fall tomorrrow but if you are planning a new network deployment or an extention to an existing one you should be thinking about this stuff and in particular you should be thinking that if your plans require new V4 IPs that you may find them difficult and costly to obtain.

* There were two other classes, one for multicast and one reserved (which can't be used because a lot of software will reject such addresses).
** As comcast found out [2] a vendor claim of IPv6 support was not sufficient to make the equipment suitable for IPv6, actual acceptance testing was (and probablly still is) required.
*** Note: because of the way IP allocation works it's not in an ISP's interest to start doing this until AFTER the pool of addresses at their RIR runs out. If they do it today they will just end up with a smaller slice of the pie in the end.

[1] http://www.potaroo.net/tools/ipv4/index.html
[2] http://www.nanog.org/meetings/nanog37/presentations/alain-durand.pdf

If only all ISP added filter to filter the announce prefixes we would have been safe from hijacking prefixes on the Internet today.

However, it turn out that the ISP:s around the world don't give a shit about it.

Terrorist, every prefix is up for grab! Just announce whatever you like and use that when you are going to hack the U.S.

Here is my original thread on NANOG on this. Please remeber that NOBODY REPLIED.

do not filter your customers - part2

There's no guarantee that your mac address is unique. Manufacturers have been known to reuse addresses for different shipments (or even accidentally the same batch).

Looking through the presentation archives of the NANOG meetings ( http://www.nanog.org/presentations/archive/ ) has some great stuff on undersea cables and also ISP peering, etc.

that they don't block The Pirate Bay.

http://mailman.nanog.org/pipermail/nanog/2011-May/036088.html

Comcast, for one.
IIRC they are offering tunnels to everyone but only offering native v6 in trial areas. Not sure if that counts.

And comcast are an ISP with far more motivation than most to go IPv6, their "control plane" network has already filled 10.0.0.0/8 and has spilled over into using public IPs! This makes deploying conventional carrier grade NAT rather difficult. From what I can gather they will be using "ds-lite" for providing v4 connectivity to those they can't give a public IP ("ds-lite" has the advantage over traditional nat of not needing a large private IP space within the ISP).

http://www.nanog.org/meetings/nanog37/presentations/alain-durand.pdf

You're right that the article doesn't delve into the technical specifics - but the report the article is describing, available via this link provides more details.

The essence of the issue is that DDoS attacks are attacks against capacity and/or state. Even the largest firewalls commercially available or that one can build have limited state-table sizes.

Placing stateful firewalls in front of client access networks makes sense - when your Web browser requests the TCP/IP stack on your client device to set up a three-way TCP handshake with example.com, there's an outgoing SYN request which traverses the stateful firewall, and the stateful firewall makes a note of this in its state table. When the SYN-ACK response comes back from the example.com server, the stateful firewall checks to see if there's a corresponding outbound request and that the incoming response conforms with the firewall policies - if the answers to both questions is 'yes', then the firewall passes the server response packets. If the answer to either question is 'no', the stateful firewall drops the inappropriate server response.

When we're talking about Web servers, DNS servers, et. al., however, basically every incoming request is unsolicited - therefore, there is no state to inspect. This is why it makes zero sense to put a stateful firewall in front of servers.

Instead, the server OS and apps (Apache, BIND, sendmail, whatever) should be hardened, tcpwrappers should be deployed on the server to provide onboard stateless policy filtering, and stateless Access Control Lists (ACLs) should be implemented on your hardware-based routers and/or layer-3 switches in order to enforce network access policy - e.g., allow TCP/80 and TCP/443 for a standard SSL-enabled Web server, allow UDP/53 and TCP/53 for a DNS server, etc., and then disallow anything else from the outside.

Here's a .pdf presentation from a recent NANOG conference which makes the same point.

When stateful firewalls are used to enforce these polices which ought to be enforced by stateless ACLs per the above, the state-table limitations of even the largest firewalls form a significant DDoS chokepoint. Attackers can craft well-formed attack traffic which will conform to the firewall rules, but which will 'crowd out' legitimate requests from users, and which in many cases causes an error condition on the stateful firewall which causes it to stop forwarding packets altogether. This leads to a DoS of the firewall itself and all the servers behind it.

I've seen this over and over and over again, even with very large firewalls. It's far easier to DoS the largest firewall in existence than it is to DoS well-tuned, hardened server TCP/IP stacks.

Servers should be protected from DDoS attacks via source-based remotely-triggered blackholes (S/RTBH), flowspec, and/or intelligent DDoS mitigation systems (IDMS) specifically designed for this application.

Load-balancers are also a DDoS state vector, but in many environments are a necessary evil. When they must be used (note that there are many ways to achieve clustering/load-balancing without making use of single-point load-balancers), they must be protected by the same stateless ACLs in terms of enforcing network access policy, and must furthermore be protected from DDoS by S/RTBH, flowspec, and/or IDMS.

'Application-layer firewalls', with their 'protocol inspectors', and so-called 'IPSes' are even worse. They carry even more state, and the protocol inspectors offer a broadened attack surface for exploitation and device compromise (you can find numerous examples of publicly-acknowledge buffer overflows, etc. which comprise security vulnerabilities in the inspectors of both commercial and open-source firewalls and 'IPSes'). Consequently, they fall over during even a moderate DDoS attack even more qui

Comcast has a slightly unusual situation. They are so massive that their "control plane" network has exhausted 10.0.0.0/8. That means afaict they are now using public IPs not just for customers but for internal use as well. The space that most ISPs would use to put their customers on ISP level NAT is ALREADY TAKEN for their "control plane" network.

http://www.nanog.org/meetings/nanog37/presentations/alain-durand.pdf

Given that they have little choice but to go IPv6 for thier internal networks (or "federate" the network but that is a large management headache) before IPV4 addresses run out it is not that surprising that they are proposing to offer it to customers as well.

In fact, there are quite a few people out there using Anycast for TCP-sessions. It's really a matter on what timescale you're looking at. The networking guys see TCP as something to use for long-living connections - e.g. a BGP session running for days, weeks or even months. A flapping route in this setup will result in a broken session. But: what does this really mean to you? If your CDN distributes downloads which are "done" within a few minutes, such a rarely flapping route will result in a few broken sessions once a day out of millions of downloads successfully served. Compared to issues like non-working DNS, overloaded servers and filled lines, that's nothing and can actually enhance the overall CDN service.

A nice paper to read is this one from Matt Levine. He's working for a CDN provider using TCP-Anycast for years now and sums up the most important issues on TCP-Anycast.

Basically the most important one is that your anycasted servers really have to be spread far enough so that flapping routes at some peering point won't matter. As a rule of thumb, put one CDN loadbalancer on the US east coast, one to the US west coast, another one to western europe, one to Australia and one in Hong Kong. If you'd like to put multiple CDN loadbalancers to one continent, leave space between them, e.g. one box for each country/state.

More info on my above point. If Akamai were to use HTTP instead of DNS for load balancing, complexity would increase in having to manage redirect clusters, as you couldn't anycast them over UDP like you can with DNS.

As someone who has setup TCP anycasting. Just ensure that your anycasting routing is stable, that prevents pretty much any 'hop' issues.

See also, http://www.nanog.org/meetings/nanog37/presentations/matt.levine.pdf

And one last URL for this issue that actually sounds reasonable:

http://mailman.nanog.org/pipermail/nanog/2010-November/028387.html

Summary: Level3 wants to be a CDN but also charge Comcast for the additional traffic it will incur due to Level3 winning the Netflix contract. Unlike other CDNs, notably Akamai, Level3 doesn't want to delivery the content to the customer network without charge. They expect to charge both Netflix for CDN services and Comcast for bandwidth used to delivery content on their CDN.

Is that it? Seems reasonable...

This kind of thing happens all of the time. Subscribe to the operators list at http://www.nanog.org/ and you will see reports of mis-announced prefixes every month or two. This is just China bashing and media sensationalism. (Which I do mind very much, thank you)

You did, and it was comcast

I was confused until I read this.

http://mailman.nanog.org/pipermail/nanog/2009-July/012198.html

If IP source headers are spoofed to somewhere else, say to AT&T networks, it makes sense to block them

Your comments imply you don't know very much about IPv6. Practically noone plans to do stateful DHCP for IPv6.

Comcast, for one, does plan to use stateful DHCPv6. See this presentation from NANOG 46 for more. (Ironically, the very story we're discussing comes from Comcast's announcement at NANOG, including plenty of technical details. ) One must remember that DHCPv6 can also be used for prefix delegation, something an ISP has a need to do for each subscriber.

Release/renew won't do a thing, because the address is generated by your computer, not the DHCP server.

Perhaps, but once a user has a IPv6-capable CPE, the IP address could likely change upon RELEASE/RENEW. (See RFC 4941) You're right that once a subscriber receives a prefix, they can do whatever they want with it, and perhaps many will end up using SLAAC. But it's really difficult to say without a bunch of consumer devices on the market, and DHCPv6 is needed in most environments to augment SLAAC anyways. Unless you have a crystal ball as to how CPE devices will behave, I think you could perhaps be a bit more educational in your responses instead of berating someone who is possibly misguided, but genuinely curious.

It's not universal, but a substantial number of ISPs do filter the routes of their customers. A few of us gave a tutorial on the subject at the NANOG 43. Unfortunately, most ISPs don't filter their peers, so once a bad route gets injected somewhere, it'll tend to get passed on repeatedly. The IRR projects, as well as both SO-BGP and S-BGP are designed to try to mitigate that.

P2P "efficiency" can be viewed from several perspectives.

P2P is always "efficient" from the content server's perspective, because data is delivered between peers instead of central servers (or CDN) reducing delivery costs quite a bit.

P2P consumes the content consumer's uplink, so it's "inefficient" in that sense, but generally uplink is an underutilized resource, and contributing uplink lets p2p work, giving access to large files that couldn't otherwise be provided, because the cost of delivery would be prohibitively high.

The issue is more complex for ISP's. For "traditional" P2P (e.g. BitTorrent) the p2p network is "network oblivious" and picks random data sources. This means that even though someone next door might be able to serve you, you will probably download from all over the planet, not from your neighbor. This makes p2p traffic cost ISP's more than CDN delivery (for example). If the P2P network knows about the ISP's network, then data can be delivered much more efficiently.

The P4P Working Group has many major P2P companies (BitTorrent, Pando, Solid State, Grid, LimeWire, Joost, Verlcix, etc.) and ISP's (Verizon, AT&T, Telefonica, etc.) working together to optimize p2p traffic within ISP infrastructures. So far the early results look very good - users get much faster downloads, while transit between ISP's drops dramatically, and the distance that data moves within ISP's becomes much shorter, thus consuming less of the ISP's network infrastructure.

There's an overview of P4P at http://www.pandonetworks.com/p4p, and a presentation on P4P that was just presented at NANOG at http://nanog.org/mtg-0802/presentations/PopkinPasko_Presentation.pdf. The presentation covers the technology and the numbers in more depth than a post on Slashdot can. :-)

Current membership is P4P Working Group:

AT&T
Bezeq Intl
BitTorrent
Cisco Systems
Grid Networks
Joost
LimeWire
Manatt
Oversi
Pando Networks
PeerApp
Solid State Networks
Telefonica Group
Velocix
VeriSign
Verizon
Vuze
University of Toronto
Univ of Washington
Yale University

P4PWG Observers:

Abacast
AHT Intl
AjauntySlant
Akamai
Alcatel Lucent
CableLabs
Cablevision
Comcast
Cox Comm
Exa Networks
Juniper Networks
Lariat Network
Level 3 Communications
Limelight Networks
Microsoft
MPAA
NBC Universal
Nokia
Princeton University
RawFlow
RSUC/GweepNet (?)
SaskTel
Solana Networks
Speakeasy Network
Stanford University
Thomson
Time Warner Cable
Turner Broadcasting
UCLA
Universite Catholique de Louvain

For more information, contact: co-chairs Laird Popkin (laird@pando.com), Doug Pasko (doug.pasko@verizon.com), or Martin Lafferty (marty@dcia.info). Participation in the P4P Working Group is free for ISP's and P2P companies.

Go read the thread on NANOG. Or read the timeline here: http://www.renesys.com/blog/2008/02/pakistan_hijacks_youtube_1.shtml

The way this happened is the result of a fundamental weakness in BGP. A more specific prefix will trump a less specific one, so anyone who has a valid peer can advertise a more specific route and hijack IP space. This is frequently used by Cybercriminals to squat on unused IP space in larger netblocks.

There have been proposals to address this issue for some time. Maybe, now that a major site has fallen victim, something will actually be done about it.

Of course, we could solve the problem the way it was when the Internet was first designed: only allow trusted entities to connect at all. IMNSHO, if the Islamic world don't want to be in the 21st century, that's their choice, but they can't have their cake and eat it too. Unless and until they agree to the basic principles of the Internet: freedom of association and speech, they shouldn't be allowed to connect at all.

This was discussed yesterday, but somehow the mods didn't control the discussion degenerating into a debate about circumcision.

And you magically know about backbone routing? Sure, you rule because your small network took you an hour to do. Sweet.

I know about backbone routing because hmm... gee- look at that- it happens to be my day job. Woo! Go me! Had you read any of my other posts you might know that.

One of my edge routers:
sh ip bgp summ:
xx.xx.xx.xx 4 xxxx 1106300 59252 4186546 0 0 6d13h 217958 ...
and so on.

Add that to a router with 200K routes. I think its going to take a bit more than that.

Wrong. Period. Try it some day. That was my entire point.

The story about my personal network was simply me relating the day it dawned on me how simple the migration to IPv6 is.

Oh yes, do you magically cut off ipv4? or do you slowly phase over?

You phase over obviously- the IPv6 routing table is a LOT smaller than the IPv4 table- the blocks were allocated more sensibly and aggregation is a lot better.

The real problem is the manpower and hardware expense to actually cut over / tunnel / nat /dns updates whatever you wanna do to make it happen.

The cost is a joke- you get an allocation- you sit down and plan- then just start enabling it- it doesn't have to run everywhere- you're not shutting down IPv4. Just start setting it up- you'll find it is a LOT simpler than you think.

I worked for UUNET back in 2000 on back bone routers. Its a headache to allocate a new circuit let alone completely redesign A LIVE NETWORK of that scale.

Why the hell would you allocate a new circuit? You're simply adding additional IP's to the interfaces.

Please don't act like this is hard. C&W made the switch a while back and encountered no significant problems- they even have customers already using it. See:
http://www.nanog.org/mtg-0505/steinegger.html
for details.

-sirket

The subject is slightly below the charter, but many great links get posted.
http://www.nanog.org/mailinglist.html

People like yourself that live in Linux la-la land where everything is Microsoft's fault are going to be the most problematic when/if desktop Linux actually gains any traction among home users. The same group of people who can't be bothered to buy a $25 NAT router and keep their machines patched. What, do you figure botnets just take machines over by osmosis?

Of course it would be ridiculous to claim that Windows is not part of the problem here, but the problem is not as simplistic as you like to portray it.

When you're talking about larger switches and routers and not the cheap linksys/dlink crap most people call a "router, there was actually a good presentation at NANOG last year. You can watch it(real video) from the link (and view slides). Most of the efficency in these larger devices has already been done. (obviously excluding that whole google + pc power supply discussion). Check it out if you are truly interested in this space.

See this mailing list message, which points to this PDF presentation.

That is sooo funny because it's sooo blatently wrong. Dead opposite, dead wrong.

Comcast exhausted the entire 10 net last year and are deploying IPv6 for their management addresses. Just check out their presentation at the recent NANOG (North American Network Operators Group) titled "IPv6 @ Comcast Managing 100+ Million IP Addresses" http://www.nanog.org/mtg-0606/pdf/alain-durand.pdf . Their situation is dire just with managing HSD "high speed data" devices (aka cable modems) already and going to get MUCH worse with their "triple play" deployment. Since they are management addresses, NAT is impractical, whether it's externally accessible or not. They don't have a choice. IPv6 is the only practical answer for them.

Comcast, themselves, are saying the exact opposite of what you are claiming. They use private address space, but that's NOT the way it's going to stay. The address shortage is a pointed issue with them. They're already moving to IPv6. IPv6 to the customer is on the horizon.

You loose. Thank you for playing.

That is sooo funny because it's sooo blatently wrong. Dead opposite, dead wrong.

Comcast exhausted the entire 10 net last year and are deploying IPv6 for their management addresses. Just check out their presentation at the recent NANOG (North American Network Operators Group) titled "IPv6 @ Comcast Managing 100+ Million IP Addresses" http://www.nanog.org/mtg-0606/pdf/alain-durand.pdf . Their situation is dire just with managing HSD "high speed data" devices (aka cable modems) already and going to get MUCH worse with their "triple play" deployment. Since they are management addresses, NAT is impractical, whether it's externally accessible or not. They don't have a choice. IPv6 is the only practical answer for them.

Comcast, themselves, are saying the exact opposite of what you are claiming. They use private address space, but that's NOT the way it's going to stay. The address shortage is a pointed issue with them. They're already moving to IPv6. IPv6 to the customer is on the horizon.

You loose. Thank you for playing.

In it, Geoff points out that for a very long time, telecommunication companies were monopolies or in some cases oligopolies (a few companies controling the market). They owned everything from the handset on one end to the handset on the other end and any feature like "call waiting" or "answering machines" had to be bought from them.

Depending on what part of the world you lived in, from the 70s to the 90s, these companies were forced to change from market monopolies to competative markets of differentiated goods. This is almost always a very rough transition to make and many companies, in any industry, often go bankrupt before they can make the structural, political, technical and cultural changes need to survive in such markets. The telecommunication industry is no different.

While the telecommunication companies are still trying to deal with competing in a differentiated market, e.g. the 80's slogan from AT&T "they are making second class phones!", to the huge number of options on cell phones, Geoff points out that they are really facing an even harder transition. They are having to go from a competative market of differentiated goods to a market of commodities. Even companies that are used to competative markets have a hard time successfully transitioning to commoditiy markets, again, they require even more changes to the organization. People just want to push packets.

Telecommunication companies thought they could create differentiated products like "video on demand" where everyone would get their TV, movies and music from the telecommunication companies. Instead, P2P systems have taken care of those needs, with the result of people not wanting huge downloads from a central company, but rather they will download from other "end users". But, even TV shows and Movies are just the tip of the iceberg. People are generating their own content and are bypassing the both the traditional media companies and the telecommuncation companies. They are creating pictures of their kids, and porn, They are creating blogs and small business websites. New features of the net are not added by the big companies under careful regulation, but spring forth from millions of places. The amount of data that is being passed around that has nothing to do with the big companies is mind boggling, and it is just going to get bigger.

People don't want content from the ISPs, they want packets pushed around, and that means a commodity market for packet delivery. Telecommunication companies that can adapt to a commodity market will survive. Ones that can't will talk about how they need to charge people for their "enhanced content".

The list above thoroughly distorts the "benefits" of IPv6 - this list has become a troll which shows up during every debate. I challenge the author or anyone else to actually show how to configure all of those things.

For information about how broken routing is, take a look at NANOG - enterprises can no longer multihome.

For information about how broken autoconfiguration is, take a look at Running IPv6 by Iljitsch van Beijnum.

For information about how broken IPv6 is with regard to speed of routing and transmission, look at cisco - most IPv6 is software-forwarded, as opposed to hardware forwarded.

The other items in the list are things which IPv4 does AT LEAST as well as v6 (yeah, try getting AES-256 to work with IPv6 on an existing VAM2, without using IPv4 anywhere, and then talk to me about IPSec-v6...)

There are good and bad things about the protocol, but it's NOT the greatest thing since sliced bread, and that list is a heap of garbage.

-David

Anyhow, I myself was curious about if/when IPv6 would be rolled out. One of the talks was about how to deal with IPv4 space running out, and a lot of the talk revolved around such things as multiple web sites running on the same IP (which was very uncommon then) and other ways to use less address space. Some audience members gave other suggestions for conserving IP space such as ways to use Network Address Translation to limit public IP use. I would say the feeling in the hall was that this was not a problem, and that people had to go the route of IP sharing, and aside from the need for more IP sharing, everyone pretty much liked the situation as it was, which was in contrast to the prevailing attitude in the world outside the hall. One audience member rose his hand and said, "What about IPv6?" The response to this was the entire audience broke into laughter - it was the funniest thing they had heard that week. After that I began thinking about IPv6 more along the lines of projects such as MBONE (anyone remember the hooplah over that years ago?). Not that IPv6 will never be implemented, but this story that IPv6 was needed straightaway could have been written 8 years ago. I haven't seen much headway in it in the past 8 years, except for products promising they were IPv6 compatible, just in case. Not that IPv6 will never be rolled out on a large scale, but I'm not holding my breath.

Check out the presentations and the resources links.

Check out the presentations and the resources links.

However, it's fine for non-personal email such as high-volume public mailing lists. I use gmail to receive my subscription to NANOG, the North American Network Operators List, which also means that I can participate in Internet infrastructure discussions without using either my work email address (where there can be bureaucratic issues like conflict of interest) or my main personal home email address, which is already in too many easily-harvested mailing list archives. Gmail's mail indexing isn't extremely sophisticated, but it works pretty well for this sort of discussion list.

For those who think that BGP is useful just on routers have some catching up to do. When doing IP anycast, it is essential to have some kind of dynamic routing protocol working on the anycast hosts. The host constantly need to communicate their reachability to the router facing the rest of the world. If the host goes down when there's a satic route, the traffic is null routed.

Thus the resurgence in development of quagga after forking it from zebra. OpenBGPd, i am sure will have more IP anycast nodes running it then someone running it as pure edge routers.

One of the most important reason for BGP to work on host based system i

North American Noise and Off-topic Gripes

From a recent post on NANOG:

Date: Wed, 30 Jun 2004 17:35:54 -0400
From: Matthew Crocker
To: "'nanog@merit.edu'"
Subject: Re: E-Mail Snooping Ruled Permissible

I know Brad Councilman, This all happened in my back yard. He ran a competing ISP with me (www.valinet.com). Not only was he reading his customers e-mail and harvesting Amazon.com orders he also hacked into 4 of the local area ISPs. I still remember the day I received a call from the FBI office in Boston. 'Sir, you are not in trouble but we would like to talk to you about an important matter. I'll be out tomorrow, when will you have time?' He came in with a old copy of my /etc/passwd file (this was hacked from me back in '95,'96). I was happy when the arrested him, he is a jerk. The ISP he ran has since been sold to another company, still local and run as an honest business.

Sorry for the rant, I just wish he got more than a slap on the wrist. They didn't prosecute him on the hacking attempts because the e-mail theft was a bigger crime.

Grrrrr

-Matt

These things have been around for awhile, but known as Network Telescopes. The largest (AFAIK) is at UCSD, which is just a tad larger than a /32 (like, say, a /8). They collected some interesting data off the thing during all the Blaster rampages (Google cache of HTML'ed PDF here).

Also, see the NANOG guide to setting them up here, and the home for the CAIDA/UCSD telescope here.

So in short, nice job to the Welsh for implementing it, but there's bigger elsewhere for y'all to play with.

I'm not paying them to mess with my connection to their own advantage. If they started doing this I'd be on my way to another provider in a heartbeat.

Really? Well, go read Norton's "The Art of Peering - The Peering Playbook" to see how providers mess with your connection to their advantage on a pretty regular basis.

Good luck finding a provider that doesn't either a.) play this game themselves or b.) purchase wholesale bandwidth from an upstream who plays

More information here.

This has increased my public requests for microsoft to send postcards or CDs to people who have registered their product. Since this is mandatory (is my understanding, I don't actually have XP installed because I refuse to buy a new copy of windows each time I upgrade my system), it should be fairly easy. It will matter little to their bottom line to pay for postage and printing of a postcard (or CD if they want to take a more expensive route).

I've found that people do not believe that their slow DSL or dial-up connections are worth hacking/infecting. The thing is it doesn't take many of them before you create enough traffic to DoS a well connected site/system off the network.

If ya'll are interested in real technical discussion about Verislime's actions and the damage it has caused then I encourage you to read the archives of the North American Network Operators mailing list for the past week or so. I would not recommend joining the list and asking questions though. The list is comprised of professionals who really don't have time for novice questions. Not to sound harsh but that's the truth. The list FAQ points it out as well (see #3).

If ya'll are interested in real technical discussion about Verislime's actions and the damage it has caused then I encourage you to read the archives of the North American Network Operators mailing list for the past week or so. I would not recommend joining the list and asking questions though. The list is comprised of professionals who really don't have time for novice questions. Not to sound harsh but that's the truth. The list FAQ points it out as well (see #3).