|
| News | Profile | Code | Photography | Looking Glass | Projects | System Statistics | Uncategorized |
Blog |
Well, it's been a little bit since I've blogged anything. Sorry about that. Let's see if I can hit the high points of the last month or so.
World IPv6 Day is approaching. Yep, by approaching I mean it's next week! If you don't know anything about it, click on the link. If you're too lazy to do that, go have some sugar. Basically, World IPv6 Day is when lots of high-profile sites will become dual-stack as a widespread test flight of the protocol. It'll only last for 24 hours, and most of the sites will remove the AAAAs at the conclusion of the test flight. It's scheduled on Wednesday, June 8th from 00:00 UTC to 00:00 UTC on June 9th.
(just for the record, prolixium.com has had an AAAA record for about eight years, at this point)
When taking breaks from studying for the JNCIP-SEC exam, I've gone back to my service provider lab, and implemented some RSVP-TE and interprovider VPNs. Strangely enough, the Juniper Olive makes a great MPLS P router, if you keep Junos below 8.5. I used a Juniper SRX210, Dynamips'ed Cisco 7200 running 12.4(15)T5, and a bunch of virtual machines running Debian GNU/Linux. Here's what it looks like:
Essentially, zat's fxp4.0 can talk to martini's Untrust interface via an MPLS L2 VPN established between ori and asgard. The L3 MTU is a little low (1426), but it works. Also, I started playing with MikroTik's RouterOS, too. It seems like a fully-featured operating system (erm, lacks IS-IS, but is close enough) for low-end CPE or MPLS LERs.
In other news, I just passed the JNCIP-SEC, today. It was a bit harder than I had expected, but I still emerged victorious. For some reason Prometric made me turn all my pockets inside-out (yes, this included my back pockets) before starting the exam. I was wondering if there was going to be a pat down, too. Crazy. Now, I suppose I should register for the JNCIE-SEC, right? I may start studying for the JUCIP-SP instead, since that will serve to recertify my JNCIE-M that expires next year (actually, I think it converts the JNCIE-M to JNCIE-SP). We'll see.
I picked up Anjunabeats Worldwide 03 and Paul van Dyk's Vonyc Sessions 2010, recently. Both compliations are quite epic, and the following tracks are my favorites, so far:
On another topic, I was over a friend's house on Memorial Day, earlier this week. He's got one of the newer 240Hz Samsung LED TVs with that hideous motion interpolation feature (in the form of Auto Motion Plus). I sat through a few minutes of Star Trek Generations, which I've seen over a dozen times, before deciding to see if there was a way of disabling it in the settings. There is, and it looks much better when disabled. I don't get the appeal.. it just makes everything look like a behind-the-scenes version of the fiim. Most Engadget HD readers agree with me.
My once happy Windows Media Center setup (on isis) stopped working, the other day. Apparently one of those lovely Microsoft updates to Windows 7 started causing WMC to die after a minute or two of usage with the dreaded nvlddmkm stopped responding and has recovered message. I couldn't grab a screenshot fast enough, but it looks something like this:
My first stab at fixing the problem was to uninstall the latest batch of Windows updates, which for me were:
It worked until I upgraded the hard disk in the machine, then Windows did some driver fussing and I started receiving the nvlddmkm errors once again. My latest solution is to uninstall all Microsoft updates (excluding security updates, those are nice to keep) including service pack 1. We'll see how well that works out. I'm still using version 183 of the nVidia drivers, since they allow me to use the VGA (ie, non-digital) output for premium channels that are protected by DRM. Newer revisions of the driver require DVI or HDMI output, and an HDCP-compliant monitor, which my 24" Dell isn't. Anyway, upgrading the driver didn't help fixing the original problem, so I'm not missing much.
It's been pretty hot in Charlotte for the last week or two. I'm talking 95°F and hotter for days on end. It seems to be higher than normal for this time of the year.
I think that's about it. I'll try to keep this more updated from now on, but no guarantees!
Alright.. pick yourself off the floor. YES, IPv6 and NAT+PAT (many folks call it just NAT or NAPT but I'm calling it NAT+PAT to be as precise as possible) are in the title. Keep reading, don't be frightened.
NAT+PAT is a hack introduced in the mid-1990s to help combat IPv4 address exhaustion. It became wildly popular in residences and large enterprises that needed to attach multiple computers to an Internet connection with only a single public (PA) IPv4 address. Unfortunately it breaks end-to-end connectivity, which impacts many protocols, and provides some network administrators with a false sense of security. Bottom line is that it sucks, and it needs to go away.
Enter IPv6, the new protocol with an almost limitless address space. NAT+PAT won't be needed anymore with IPv6, they'll be a thing of the past! Well, almost. One accepted scenario where NAT+PAT will still be used is load balancing. Although, some may not even view load balancing as actual NAT+PAT, but a simple TCP proxy. Call it what you will, but the real servers in a load balanced environment (assuming no DSR) won't typically see the source address of the client hitting the VIP. They'll see requests coming from address(es) on the load balancer itself.
So, other than load balancing, IPv6 NAT+PAT isn't needed, right? Well, read on, because I'll present a somewhat common IPv6 dual-stack deployment that might be able to benefit from sugh a beast.
Enter a company called Foo and Associates. This company doesn't exist, and I'm making all this stuff up. However, the design may look strangely similar to other networks out there. Here's a diagram to start you off:
The above diagram shows Foo and Associates' network, AS64499. They've got chunks of IPv4 and IPv6 PI space and use 10.10/16 internally. There's two data centers and a few branch offices with private (MPLS, leased lines, whatever) WAN connectivity back to the DCs. The DCs have some users and servers, and the branch offices just have users. Right now, the branch offices access the IPv4 Internet through either of the two DCs, and get translated (NAT+PAT) to the external address(es) of the Internet firewalls depicted in site 1 and site 2.
There is a "dirty" segment that the firewalls live on as well as the Internet routers, which maintain connections to a few transit providers. The two Internet routers have a private WAN link between them to be used for redundancy in case the transit providers fail at one particular DC. The following diagram shows both the IPv4 and IPv6 advertisements:
Now let's talk about how IPv4 works.
The DC servers just talk to the Internet without NAT or PAT or any translation. The Internet routers statically route the appropriate subnets to the DC firewalls, and everything works properly. The IPv4 advertisements are tweaked (as you can see in the diagram) so each /23 worth of DC server space is routed symmetrically in a hot-potato fashion.
Internet access from the RFC 1918'ed campus networks goes through the Internet firewalls at each of the DCs. An IPv4 default route is followed based on WAN link costs, and traffic is translated via NAT+PAT out the Internet firewalls. If one DC dies, the branch offices that are sending Internet traffic to it just move over to the Internet firewall at the other DC. Here's a diagram of the outbound IPv4 Internet access flow:
And here's one showing the return traffic:
Let's also say some of the WAN links are a bit more latent than the others, either due to fiber routes or the geographic location of the sites of Foo and Associates. The internal routing always takes the path with the lowest latency to determine the best way to the Internet. Sure, it could be EIGRP or it could be IS-IS with some mechanism to tune link costs based on latency. The details aren't relly important, here.
Now, let's talk about what happens when Foo and Associates deploys IPv6.
After getting a /40 assignment from their local RIR, Foo and Associates deploys IPv6 right on top of their current infrastructure, essentially dual-stacking everything. The first diagram shows all the IPv6 addressing, so you might want to look at that again.
However, instead of deaggregating and sending longer prefixes to the DFZ, they Go Greenࡊ and only announce their /40 equally out of each data center. The DC servers don't have a problem with this, as there are IPv6 static routes (and advertisements in IBGP, just like there were for the IPv4 specifics in the previous section) pointing from the Internet routers at each DC to the /48s of public space. Egress traffic from the servers will exit locally, and ingress traffic can be received either locally or from the other DC, where it will be sent over the WAN link toward the correct site. The DC firewall sees both traffic flows, and everything works as expected.
What doesn't work correctly is Internet access from the branch offices. Since any part of the company could access the Internet via either of the Internet firewalls, the Internet routers have the whole /40 routed to the Internet firewalls for return traffic. Now, keep in mind that Foo and Associates has stateful firewall policies allowing internally-initiated outbound Internet traffic, but not Internet-initiated inbound traffic. Here's the outbound IPv6 Internet access:
And illustrating the specific case where things break, here's the return traffic:
Now you see the problem. If Google decided to send traffic back to Foo and Associates via transit provider B, it would get lost. The Internet firewall at site 2 doesn't have a record of the outgoing connection (SYN packet to [2001:4860:8008::68]:80) so it denies it thinking it's invalid traffic. Meanwhile, the Internet firewall at site 1 never sees any inbound traffic to the session it opened to [2001:4860:8008::68]:80. Eventually, the user's browser at site 3 times-out and falls back to IPv4.
There are a few potential fixes to the above problem. Unfortunatly, every one of them has some drawback. Let's go over them individually.
1: Deaggregate
Foo and Associates could deaggregate and advertise a whole bunch of /48s in addition to (or in place of) its /40. The /48s of the sites closest to site 1 would be advertised out of Internet router A and the /48s of the sites closes to site 2 would be advertised out of Internet router B. This would allow the firewalls at each DC to see both the outbound and inbound traffic flow. Sounds like it might work!
However, even if the ISPs accepted the longer prefixes (and their upstreams did as well), what if the latencies of the WAN links change one day, and sites that normally have their best path out of site 1 flip over to site 2? Latencies of leased lines might not move around too much, but latencies of MPLS-provisioned L2VPNs might fluctuate if the provider is building out a new ring or making network changes. So, again some sites might encounter the original problem and end up with asymmetric flows getting nuked by the firewalls.
2: Move the firewalls
An expensive way of solving this problem is to remove the Internet firewalls in the DCs and move them closer to the users. This means that the campus networks at each of the DCs would have their own firewalls, and each of the branch offices would have theirs, as well. Since there's only one way in and out from each of the campus networks, the problem goes away.
Unfortunately, even if firewalls grew on trees (or were free), there are some security implications with this design. Essentially, Foo and Associates' private WAN becomes a public one. Rogue Internet traffic can make its way into the WAN, even if it's blocked before it gets to the users. A DDoS that might normally not cause the Internet transit links to blink could consume one of the WAN links easily, disrupting operations. This option isn't too bad, but it's not going to fly if Foo and Associates happens to be a financial company. Although, Foo and Associates could just ditch the WAN and move to Internet-based VPNs, but then QoS goes out the window for any VoIP-related things, MTU becomes an issue, and bleh.
3: Link the firewalls
If the Internet firewalls in each data center support high availablity and state table sharing, it might be possible to link them together. Some vendors say that this type of setup will work up to 100 ms but it typically needs two links, jumbo (>= 9100 bytes) frame support, and no VLAN tag manipulation. So, Foo and Associates could buy two dedicated MPLS L2VPNs with jumbo frame support and a latency SLA that's below 100 ms. This way, the firewalls could maintain a common state table and know about the outgoing state even if it's been built through a different firewall.
This might work, actually. But is it a good idea? Maybe, maybe not. Session set-up time may be longer if the session table has to be updated synchronously. What happens if the provider breaks their SLA and the latency exceeds 100 ms? Session table disaster is the probable outcome.
4: Only use one site for IPv6 Internet
Another simple yet unattractive option is to tweak routing so only one DC is used for IPv6 Internet access. If site 1 was chosen, the /40 advertisement out of site 2 would be prepended, and the BGP local preference attribute would be used to influence the exit path. If site 1 drops off the map, site 2 could still be used as backup (since there would be no other routing announcements to choose from). Note that this wouldn't affect the DC servers.
The problem with this plan is obvious: latency. Sites that have the shortest path to site 2 for Internet access would go through site 1, instead. If site 4 is on the west coast and site 1 is on the east coast of the United States, this could get annoying. What if site 4 was in San Francisco and site 1 was in New York? Should the packets for UCLA's website over IPv6 really have to cross the country and back? Yeesh.
5: Forget security
The title says it all. Throw out those Internet firewalls. Let's go back to the old days when there weren't any firewalls. Seriously, if Foo and Associates is a college or university, this may be the way to go. No firewalls, no session tracking, and no problems!
Although this may be a bit unorthodox in this day and age, a compromise might be to turn of SYN packet checking on the firewalls and allow traffic on ports above 1024 to generate sessions even if the 3-way handshake was never observed. Or, replace the firewalls with routers that do stateless filtering to achieve the same goal.
6: IPv6 NAT+PAT
Here it is, folks. Add IPv6 NAT+PAT to the Internet access policy on the Internet firewalls in both DCs, and you're set. IPv6 Internet access is then optimized for latency (well, as well as it was for IPv4) and the problem with return traffic disappears. Here's a diagram:
And the return path:
Problems.. there are tons of them. This breaks end-to-end connectivity, AGAIN. It feels like the mid-1990s all over again. IPv6 NAT+PAT isn't really implemented in many devices, yet, but it's implemented in OpenBSD's PF. The simplicity of this solution is hard to deny, even with the problems (philosophical and other) it presents.
And there you have it. Are there solutions 7, 8, and 9? I sure hope so. Feedback, please. I'd love to hear it.
It's the end of 2010, and 2011's just around the corner! In the past, I've written "a year in review" types of articles about what I did and accomplished in the previous year, or post new year's resolutions that I've never kept. This time, I won't do either. Instead, here's a few predictions and comments on topics that interest me.
The US (and world) economy won't collapse in 2011 and the world won't end in 2012.
Ok, now that we've gotten that out of the way, let's continue…
We've seen some of it already (healthcare, net neutrality, talks of cap & trade, etc.), but I think the United States' government will continue to grow much larger than it's already become in the last decade or so.
Net neutrality bills and other type of broadband initiatives will be approved and implemented, requiring broadband providers to upgrade their infrastructure to certain speed requirements, while losing the freedom to engineer or block traffic. Blocking ports like TCP/80 and BitTorrent will become illegal for anyone providing Internet access (form coffee shops to large MSOs).
MPG requirements for automobiles will continue to rise, eventually prohibiting (through high taxes or special licenses) the sale of sports cars to the general public, and causing auto makers to manufacture more efficient vehicles. Electric and hybrid cars will be promoted by the federal government and an international charging standard will be created to prevent plug incompatibilities of plug-in hybrids. LED headlights might make an appearance in the automotive industry!
In some way or another, the good-intentioned fight against [childhood] obesity in America will result in the government slowly starting to dictate the eating habits of Americans. I'm not implying that bacon will be taken off the market overnight, but I do think that the suggestion of a healthy lifestyle may go too far. Just like salt is on its way to be banned in some places, we'll start to see items offered by some fast food chains drop off the menu, more and more sugar substitutes appear, and portion size at resturants regulated. Eventually, I think hamburgers will be banned (remember this seaQuest episode?), too!
Anti-terrorism screenings and procedures will result in even more invasion of personal privacy, banning more arbitrary items from planes and trains (think iPhones and laptops).
Texting will become illegal, and more cars will start to support voice recognition via an extension to the Bluetooth protocol (ie, send and receive SMS/e-mail messages, post to Facebook, etc. by voice only).
Smart grid technology will continue to be deployed in most cities and modern neighborhoods. From the data obtained by such a system, households with more than some amount of "waste" (eg, computers running w/out power saving) may be taxed in some way or another, regardless of actual power consumption.
Home-schooling will probably be banned in the next several years, due to a divergence in the curriculum used and the inability for the US DOE to control it.
More whistleblowing sites like WikiLeaks will appear, and cause companies and governments to become more paranoid with the safeguarding of sensitive documents.
President Barack Obama will be re-elected in 2012.
Overall, software will become more complex, inefficient, slower, and buggier. I just don't see this changing, at all.
Apple, Google, Amazon, and Microsoft will all continue to embrace cloud computing, and coerce everyone into storing all of their personal data on their servers.
Facebook won't kill e-mail. However, e-mail spam volume will decrease.
Newer versions of desktop operating systems (Windows, Mac OS X, Chrome OS) will start to be "locked" to users, like iOS. So-called "jailbreaking" or "rooting" will be required to access the shell and filesystems. For most users, this won't be an issue because of cloud computing. The sale of software will migrate to online "stores" like the forthcoming Mac App Store.
Laptop, tablet, and netbooks will replace traditional desktop computers and workstations. Only in high-performance computing environments will desktops and workstations exist.
Desktop Linux will continue to fail, with the majority of Linux users migrating to Mac OS X or Chrome OS (I don't consider this to be desktop Linux).
IPv6 will continue to be deployed throughout networks in the United States over the next year or two, but it will be 3-4 years before the majority of content delivered to end users will move from IPv4 to IPv6. Router and switch manufacturers will find a way to produce cheap CAM and routing table bloat will be less of a concern, resulting in the maximum prefix length allowed into BGP by most providers to be at least 48 bits. Provider independent (PI) allocations from the RIRs will be given out to small companies and individuals, and the need for multihoming hacks (NAT66, SHIM6, etc.) will be reduced dramatically.
Whitelisting of DNS servers to provide access to AAAA records (like GoIPv6) will become a bit of a fad in 2011, but drop off dramatically in 2012. DNSSEC will start to see usage among the popular sites (Facebook and Google) in 2011, as well.
The majority of TDM circuits (DS-3, etc.) will be replaced with Ethernet over the next several years, and the PSTN as we know it will go away. Voice will start to move over IP everywhere, and phone numbers will start to become obsolete.
MSOs will become nothing more than ISPs, and video will start to be more subscription-based. The concept of "TV channels" will be gone, and all content will be viewed in a web browser or on specialized hardware. There will be more NetFlix-like services available.
More and more wireless ISPs (like Verizon, Clear, etc.) will appear with LTE Advanced services offering speeds that rival FiOS and DOCSIS 3.0 cable deployments. MSOs will eventually convert to FTTx and abandon coaxial cable altogether. Some (Comporium) have already started to do this.
There will be larger credit card security breaches in the next couple years, resulting in online merchants migrating to PayPal-like services. For retail payments, NFC will be used. IT departments around the world will rejoyce and not have to deal with PCI.
Tomorrow there will be a vote on some potential network neutrality regulations. The agenda, according to the FCC, will include the following:
Open Internet Order: An Order adopting basic rules of the road to preserve the open Internet as a platform for innovation, investment, competition, and free expression. These rules would protect consumers' and innovators' right to know basic information about broadband service, right to send and receive lawful Internet traffic, and right to a level playing field, while providing broadband Internet access providers with the flexibility to reasonably manage their networks.
This is very vague, so I don't know exactly how detailed these discussions will be. If you choose to keep reading this article, be prepared that this is ALL my opinion (not the company that I work for, etc.). So, shield your eyes if you want!
Even in light of recent issues that might be viewed by some as a net neutrality problems and new services that will make it easier for ISPs to throttle, block, and charge for certain types of content, I haven't really seen a compelling reason for any government regulation.
Quite simply, if your ISP wants to block content, ports, protocols, or throttle certain types of traffic, I believe they have the right to do so. It's a free country. You, as the customer, also have every right to complain about it, and ultimately cancel your service. If that's the only service in the area (which is starting to be hard to believe with all the wireless services available, these days), then move, or deal with it.
Now, to step back a little bit, other than blocking new inbound connections to TCP/80 and throttling peer-to-peer traffic, are there any ISPs out there today in the United States that are charging extra for so-called Facebook (I say so-called because with CDNs, anycasting, and GSLB on complex sites like Facebook, it may be difficult to classify all Facebook traffic vs. advertisments or other third party media) traffic? Ok, how about blocking traffic to all search engines besides Yahoo! and Google? Ok, well, how about intentionally slowing down YouTube traffic? None?
Well, that last point can be a little more complex, since some might argue that (if you read the link above) Comcast is intentionally throttling content that transits their peering with Tata. If Twitter traffic is engineered (think BGP attributes like AS_PATH prepending, MEDs, LOCAL_PREF etc.) to traverse the Comcast/Tata link, is it considered throttling? Intentionally throttling? Well, maybe, but it doesn't really discriminate on exact content.
I do think that ISPs need to present the customer with exactly how they're blocking and throttling content. Maybe this requires some legislation, but honestly there may be cases where this isn't appropriate (for the customer or the ISP). It's difficult to predict how laws will impact things down the road.
Also, I think residential ISPs should probably change their model and charge for raw bandwidth, and I think they should have started it from day one. Your tier 1 and other large Internet backbones do it (Cogent, Level3, etc.), today, so why isn't that passed onto the residential subscribers? If you only use 10MB (ok, maybe proxy ARPs themselves amount to more than that, but anyway..) of traffic per month, why should you have to pay the same as the power user across the block who chews up 80GB per month? Why is consumption-based billing (CBB) so evil? And, if the ISP wants to charge an obscene amount for real unlimited traffic volume, then they should be able to (but guys, unlimited is unlimited, don't say unlimited and then unplug subscribers after they hit the imaginary 250GB cap).
Now, I digress, but start thinking about network neutrality and carrier grate NATs (CGNs). When the remaining /8s are handed out to the RIRs, and then the RIRs run out of blocks to give out to residential ISPs, customers are going to start receiving RFC 1918 addresses (NET-10, most likely) on their CPE interfaces. Yep, this means no more public IPs. IPv4 traffic from the customers' RFC 1918 addresses will be translated to public IPv4 addresses at hub sites or head ends (whatever you want to call it - POPs). Will network neutrality make this illegal, because ISPs are intentionally blocking inbound traffic to all TCP and UDP ports on the customers' CPE? Uh, well, there's no way around it with many-to-one NAT. Just think about it, it can get pretty ridiculous.
Also, if you want a quick summary of my views on blocking, limiting, etc. please check out my comment on Ian Gulliver's Net Neutrality? blog entry.
Although most of the time my schedule is fairly predictable, every couple days I'll shift things around and come home from the pool (or directly from work) at a different time of the evening. This, unfortunately, prevents me from creating an accurate program on my thermostat to manage the HVAC system in my condo.
I've been searching around for a decent Wi-Fi thermostat for awhile, now. I'd like to be able to control the heating and air conditioning remotely. My requirements appear simple, but apparently they're not:
I can't find anything that meets even half of these requirements!
The best I've seen so far both look really nice and sport some good features, but require management of the thermostat via a web interface running on the manufacturer's servers. Yeah, this means that all the thermostat does is create an outgoing connection to some external server and wait to receive commands. Become a statistic and give some external party access to the HVAC system and current temperature of my condo? No thanks! I want something that I can manage directly via my local network (or VPN).
So, right off the bat, these get bumped from the list:
Some of the above (I'm looking at YOU, Carrier!) even charge a recurring fee for access to the web portal functionality. Despicable!
Any ideas? Am I going to have to build my own with a microcontroller?
I had a chance to try out one of the new Sierra Wireless IntelliGo mobile Wi-Fi hotspots from Road Runner Mobile, today. The Wi-Fi hotspot is actually just a little router with WiMAX, CDMA (EV-DO), and Wi-Fi radios. The WiMAX radio represents one of the two so-called 4G cellular technologies, the other being LTE.
The Road Runner Mobile service provided by Time Warner Cable is actually Clearwire's WiMAX service, which falls back to Sprint's EV-DO network (3G) when WiMAX isn't available. It might fall back to 1xRTT, too, if 3G isn't available, but I had no easy way of testing this (well, without driving deep into South Carolina).
To set the stage, I can currently get around 2.7Mbps (megabits per second) with 79ms of varying latency on AT&T's UMTS network on a very good day.
For testing, I used wget to this URL and ran MTR to dax.
I first tried powering up this thing in my condo, and after what seemed like over 90 seconds of staring at the bootup logo, it started up.. but on Sprint's EV-DO network (at 80% signal strength)! I ran my tests anyway, and peaked around 1.3Mbps but averaging around 640Kbps. Latency sucked:
HOST: six Loss% Snt Last Avg Best Wrst StDev 1. foobarz.lan 0.0% 8 1.7 2.7 1.5 10.2 3.0 2. 68.28.249.69 0.0% 8 124.7 264.0 124.7 463.1 127.0 3. 68.28.249.91 0.0% 8 135.8 258.7 127.8 451.9 117.1 4. 68.28.251.54 0.0% 8 154.9 265.8 147.8 455.1 121.1 5. 68.28.255.9 0.0% 8 173.9 262.9 135.3 449.9 118.2 6. ??? 100.0 8 0.0 0.0 0.0 0.0 0.0 7. 68.28.253.69 0.0% 8 134.1 236.0 124.6 419.1 107.7 8. sl-crs3-fw-0-1-3-0.sprintlin 0.0% 8 169.0 229.2 122.0 383.1 85.1 9. sl-crs1-fw-0-7-0-0.sprintlin 0.0% 8 141.2 228.7 125.8 379.7 101.2 10. sl-st21-dal-1-0-0.sprintlink 0.0% 8 128.4 236.8 128.4 377.6 94.6 11. dls-bb1-link.telia.net 0.0% 8 132.3 214.7 129.1 319.1 72.3 12. atl-bb1-link.telia.net 0.0% 8 229.4 256.4 170.0 447.0 87.0 13. ash-bb1-link.telia.net 0.0% 8 240.5 272.1 173.7 449.7 109.7 14. voxel-ic-129445-ash-bb1.c.te 12.5% 8 192.0 259.2 167.7 418.9 104.3 15. 0.te6-2.tsr1.ewr1.us.voxel.n 12.5% 8 176.8 276.4 165.7 525.4 124.9 16. 842.te1-7.csr2.lga6.us.voxel 12.5% 8 168.0 297.1 168.0 607.8 145.9 17. dax.prolixium.com 12.5% 8 203.5 277.2 181.6 558.1 132.8
I had to toggle the option in the web interface to force the unit to only use 4G service. Only after I did this, it barely got a WiMAX signal and got me online. The web interface indicated I had poor signal strength at -88dBm (it rated this at 10% - I guess this is why it automatically picked 3G initially), and I agreed. I could only get roughly 360Kbps and the latency was all over the place:
HOST: six Loss% Snt Last Avg Best Wrst StDev 1. foobarz.lan 0.0% 8 1.6 2.1 1.6 3.1 0.5 2. 71-23-64-2.clt.clearwire-wmx 12.5% 8 276.1 190.1 87.4 485.0 144.0 3. 71-22-7-161.clt.clearwire-wm 0.0% 8 211.2 289.6 111.3 703.8 216.9 4. 66-192-62-1.static.twtelecom 12.5% 8 85.4 316.1 85.4 673.8 225.5 5. ash1-pr1-ge-2-0-0-1.us.twtel 0.0% 8 265.2 266.7 95.9 574.1 183.7 6. 0.te6-2.tsr1.ewr1.us.voxel.n 0.0% 8 155.2 231.1 81.1 474.5 126.4 7. 842.te1-7.csr2.lga6.us.voxel 0.0% 8 125.2 200.7 125.2 374.8 79.8 8. dax.prolixium.com 0.0% 8 124.6 167.3 98.2 297.7 76.1
DNS is slightly intercepted on the IntelliGo, since the PTR record for 192.168.0.1 was translated to $my_ssid.lan. No, foobarz is not my real SSID.
After driving around Ballantyne a little bit, I managed to figure out which tower was providing the WiMAX coverage for the area. It ended up being the one near Toringdon that's easily seen from I-485. I got the signal strength up to -47dBm (80%) by sitting in a parking lot of one of the office buildings in the area:
I could have gotten closer by walking across the grass, but I figured the orientation of the antennas would result in worse signal strength as I got closer. Oh, maybe I was just lazy.
I managed to peak at 6.76Mbps down, while the transfer rate typically hovered around 5.5Mbps. Latency was a little better, too:
HOST: six Loss% Snt Last Avg Best Wrst StDev 1. foobarz.lan 0.0% 8 1.7 6.0 1.7 18.2 7.3 2. 71-23-64-2.clt.clearwire-wmx 0.0% 8 66.1 78.1 65.3 94.4 12.4 3. 71-22-7-161.clt.clearwire-wm 0.0% 8 76.0 77.1 61.1 97.6 12.2 4. 66-192-62-1.static.twtelecom 12.5% 8 65.8 69.7 50.9 92.2 12.1 5. ash1-pr1-ge-2-0-0-1.us.twtel 0.0% 8 80.7 84.3 79.8 97.2 5.5 6. 0.te6-2.tsr1.ewr1.us.voxel.n 0.0% 8 85.6 90.7 74.8 107.6 10.0 7. 842.te1-7.csr2.lga6.us.voxel 12.5% 8 60.7 82.5 60.7 102.9 17.0 8. dax.prolixium.com 0.0% 8 86.5 92.7 82.1 105.9 9.9
Although not shown above, I managed to get one response back from the second hop (the other end of the PPP connection, no doubt) in 40ms. Supposedly LTE's RTT is in the 30s, so this certainly comes close!
Stopping at different points around Ballantyne with an average of around -57dBm got me between 3-4Mbps. Not too bad, but not that big of a jump over AT&T in the middle of the night (ie, no iPhone users).
The IntelliGo device itself is slightly disappointing. Battery life on the unit dropped to around 50% after 50 minutes of moderate use. The startup time before even starting the initialization of the radios is way too long (I mentioned 90 seconds earlier, but it could have been longer). Also, I don't know if it's just a result of the high frequency used by WiMAX (>2GHz) compared to other mobile networks or a problem with the IntelliGo itself, but I was disconnected left & right when driving and moving around. The kicker was hearing a beep (it makes certain noises for connecting & disconnecting from the mobile network, and when clients connect) consistently when I drove under overpasses!
In conclusion, I probably wouldn't buy one of these, but I don't travel too much, either. It's probably great for Internet access at airports and other public places where Wi-Fi is either not free or terribly congested.. as long as you've got WiMAX coverage, which doesn't seem to be too widespread, yet. Sprint's 3G isn't too shabby, though, but still pales in comparison to the speeds and latency of AT&T's UMTS network, even when congested with iPhones.
I've finally done it. I've washed my hands of Nokia for good. I recently picked up a Nexus One and only looked back once or twice. I figured this deserves a blog entry…
I've owned several Nokia E-series Symbian-based phones since March of 2007. I've used all of them on AT&T's network in the United States:
(yes, I would sell each previous phone on eBay for roughly half the price I paid, except for the E72.. read on to find out why)
The E61 and E61i were good phones. Maybe they were a little slow (speaking both about CPU and the data service delivered by the EDGE technology) in comparison with other things, but they were stable. There were no screen transitions, no frills, and the eMail client worked well. The QWERTY keyboard was large, and the screen was easy on the eyes, not to mention being easily viewable in direct sunlight.
The problems started with the E71, even though the hardware was a big step up from the E61[i]. UMTS (3G technology), a faster CPU, and nice 3.2 megapixel camera were the main features of the E71. Unfortunately, Nokia decided it was going to try to soup up Symbian with some extra silly features, including a camera application that was bloated beyond belief and "modes" that were supposed to help switch between personal and work mode. It also was a smaller phone, which didn't really bother me, but made me miss the size of the E61[i]. The phone also had some major bugs, and crashed quite a bit.
I don't know why I upgraded to the E72. Maybe I just wanted the faster HSDPA (10.2 Mbps vs 3.6 in the prior models, even though AT&T only offered ~7 Mbps in certain areas) and the upgraded 5.0 megapixel camera. Well, this phone was a disaster. I'm going to have to resort to a list, here:
For the eMail client, I don't know what Nokia was thinking. It doesn't support IMAP IDLE (although Nokia says that the phone supports push eMail), and reconnecting to check mail takes almost 2-3 minutes, with the eMail application crashing half the time. It's so bloated, and even the simplest of tasks appears to lock up the phone. It looks like the mail client needs tons of optimization, and was designed for a phone with a much bigger screen resolution. For the E72, it was terrible. I actually stopped using the phone to read eMail, as a result. Oh, and one other thing - if the eMail client is allowed to pull all messages from a folder (which is the default for manually-subscribed IMAP folders), it'll consume all available memory, storage, and require a HARD reset to get things back to normal (yup, reboots and deleting of mailbox definitions doesn't fix this).
As a result, the phone was a pain to use. However, it does have some good points:
Ok, maybe not too many.
I mulled over the alternatives (Android handsets, iPhone, and Nokia N900) and determined I wanted to go Android.
I knew the major struggle with this phone was going to be getting over the lack of a QWERTY keyboard. It seems that everything is moving to touchscreens these days, so I figured I should get used to it.
The phone itself is easy to use. It took me a little bit to get over the QWERTY keyboard, which is more difficult to use than the one in the iPhoneOS (erm, iOS). The voice recognition is nice, though, and fairly accurate (you can speak instead of typing, most of the time). The eMail client works (yay!), the browser is quick, and the camera (5.0 megapixel) provides decent quality. The battery life could be better.
The N1 runs Android. Android is a weird operating system. It's based on the Linux kernel, but the userland isn't what one would normally expect from a typical Linux distribution (directory hierarchy, etc.). All applications seem to stay in memory to aid in multi-tasking, and therefore the amount of free memory is quite low under normal circumstances. Android Market is a centralized shop for applications for rooted and non-rooted phones, which I found strange.
The phone runs Android 2.1_update1, and can be unofficially upgraded to 2.2. The T-Mobile N1 has an official upgrade, but the AT&T version does not, at time of this writing.
Instead of unofficially hacking 2.2 onto the N1, I unlocked the bootloaded and loaded CyanogenMod, which is a modified Android 2.1_update1 with extra features like FLAC support, OpenVPN binaries, extra Unix utilities, and is pre-rooted.
I've got OpenVPN running just fine, and am also using Sipdroid VoIP to connect to my Asterisk system. Well, Sipdroid works well over OpenVPN over Wi-Fi, but barely works over AT&T, due to the jitter on HSDPA. I'm sure if I were near a tower at 03:00, it would work fine, too. I blame all the iPhone users during the day..
I settled on QuickSSHd to allow SSH access to the phone, which lets me securely copy stuff off or onto the phone wherever I am. Much easier than plugging in USB and playing with cables. Since CyanogenMod comes with rsync, it makes it even easier.
Tethering via Wi-Fi, Bluetooth, and USB all work great. Tethering via Wi-Fi does drain the battery very quickly (much more quickly than using JokiuSpot on the Nokia E-series phones, strangely enough).
The phone does support IPv6, and it works great over Wi-Fi. I haven't tried any IPv6 tunneling on the phone, yet.
Now, onto the gripes.
There is a huge bug in Android 2.1_update1 that causes the Wi-Fi radio to shut off whenever the screen turns off. There's a "Wi-Fi Sleep Policy" option in the Wi-Fi advanced settings that supposedly allows one to control when Wi-Fi sleeps (never, only with cable connected, when screen turns off) but none of the options make any difference. There appears to be no remedy to this other than just running an application that will not shut off the screen (Wi-Fi Analyzer has an option for this, among others). Obviously this is a complete waste of power, and presents a real problem for N1 owners.
Supposedly Android 2.2 fixes this issue, and CyanogenMod 6.x will be based on 2.2 whenever the source code is released. I'll be waiting for this day!
Other than that, I've only had one other problem with the phone, which happened yesterday. I've been using Open GPS Tracker to plot routes & speed I take through Charlotte. Unfortunately, when I was driving, the phone crashed and went into an endless reboot cycle. Reading online made me think I might have to do a hard reset, but thankfully booting into safe mode then rebooting again fixed it. I was thinking Open GPS Tracker was causing the problem on bootup, but apparently not.
Normally, I would have sold my old Nokia phone on eBay (it's going around $250 at the time of writing) by now, but unfortunately it seems the security code has been changed. I don't remember changing it, and neither the default code (12345) or my old security codes work. Apparently, the only way to reset this is to send the phone back to Nokia so they can hack it, or something. I found this page which detailed a procedure to add a file to the SD card, and boot the phone. Unfortunately, it didn't work.
So, I'm left with a Nokia E72 in great condition, sitting on my shelf. I don't want to sell a phone with a locked security code.. or do I?
Over the past couple of years quite a few transition mechanisms and models have been created to ease the deployment of IPv6 into ISPs and enterprises. Some of the recent ones have very similar names, and can be easily confused with each other. I'm going to attempt to summarize them all here as concisely as possible in my own words, and possibly put them in some sort of logical order (or not).
(Update: Added 6rd and DS-Lite!)
Request for Comments: 3056
Summary: 6to4 is probably the oldest and original IPv6 transition mechanisms. It essentially allows any host with only IPv4 connectivity to communicate with IPv6 hosts using 6in4 (IPv4 protocol number 41) tunnels through one or many public 6to4 relays operated on the Internet. Each IPv4 host using 6to4 assigns itself a prefix out of 2002::/16 in the form of 2002:<IPv4 address in hex>::/48. It then forwards all (well, not 2002::/16) IPv6 traffic toward the nearest anycasted 6to4 relay (192.88.99.1).
Pros: Everything supports it, by now. It's fairly simple to setup.
Cons: Due to Internet routing issues, it's not guaranteed to work. Anycasting with BGP does not guarantee low latency. In fact, latency to the closest (AS_PATH speaking) 6to4 relay is often 100s of ms away! Whenever the host's IPv4 address changes, their whole IPv6 /48 based on that address must change, too. Also, 6to4 doesn't work through IPv4 NAT too well.
Request for Comments: 4213
Summary: 6in4 is a generic term that's used to describe the encapsulation of IPv6 packets in IPv4 packets with a protocol number of 41. In a sense, it's a manual version of 6to4, but much more flexible. In the case of two networks separated by the Internet, one dual-stack and one IPv4-only, one would build a 6in4 tunnel between the sites, and route IPv6 prefixes to the IPv4-only site to provide IPv6 connectivity. This is the main method of "do it yourself" IPv6 tunnels that are offered by several organizations (often called "tunnel brokers"). Hurricane Electric and SixXS (pronounced six-ess, like success) are two of the most popular organizations that offer these type of tunnel services with the main goal of providing end-users access to the IPv6 Internet.
Pros: It's quick and easy. Most public tunnel brokers will provide a /48 prefix of PA space to end-users.
Cons: By their definition, 6in4 tunnels are static, so the change of either IPv4 endpoints requires a re-build of the tunnel, or at the minimum a reconfiguration (although wrapping the 6in4 tunnel with OpenVPN eliminates this issue). MTU issues can exist, if both sides do not coordinate the setup correctly, or if the MTU along the path decreases in a failover scenario.
Request for Comments: 5214
Summary: ISATAP (Intra-Site Automatic Tunnel Addressing Protocol) allows two dual-stack nodes to communicate via IPv6 over an IPv4-only network. ISATAP, geared toward enterprises, was developed by Microsoft, and views the IPv4 network as one big flat link layer for IPv6. ISATAP creates link-local addresses to be used on the virtual "link" by appending 0x5efe plus the host's IPv4 address. Global addresses can be assigned on the ISATAP link via autoconfiguration or DHCPv6, as well. Clients discover the ISATAP routers by performing an IPv4 DNS query for isatap.<domain> upon connection to the network. The IPv4 transport uses protocol number 41, just like 6to4 and 6in4.
Pros: It's fairly automatic and doesn't require any configuration on the client.
Cons: Relies on IPv4 DNS, which some folks consider a circular dependency. MTU issues could also exist.
Request for Comments: 4380
Summary: Teredo is a tunneling protocol that shares a similar goal with 6to4, yet uses UDP (port 3544) instead of 6in4 to improve NAT traversal. A Teredo client will contact a server and obtain a single address consisting of a combination of the client IPv4 address, source port number, Teredo server IPv4 address, and some flags. The server handles the first packet, and then directs the traffic through a Teredo relay that's closest (AS_PATH speaking) to the IPv6 host. Relays advertise 2001:0::/32 into BGP, and this is the prefix that Teredo addresses are built from.
Pros: Simple to setup (Windows Vista/7 enables it by default if no RAs are received). It works great through all sorts of NATs. Easy to troubleshoot since the same relay is used for communication in both directions.
Cons: Only one address is allocated per Teredo client. It's so easy to setup and works so well that it may inadvertently expose hosts on a secured IPv4 network to the IPv6 Internet.
IETF Internet-Draft: draft-shirasaki-nat444-isp-shared-addr-02
Summary: NAT444 is a model that ISPs can use to deploy IPv6 to both commercial and residential customers without removing IPv4 access or replacing CPE equipment with specialized hardware. CPE (customer premise equipment) hardware can be a standard Linksys router or something with more functionality and performance. Although NAT444 can be deployed commercially, it appears to be designed around residential customers (MSO/DSL). The customer's network in NAT444 is dual-stack, with the IPv6 prefix(es) being globally-unique and assigned by the MSO, and the IPv4 addresses chosen by the customer (or more likely, the default configuration of the CPE). The IPv6 traffic is routed natively by the CPE, via the provider's backbone toward Internet peers and on to the destination. However, the IPv4 traffic encounters NAT (or more accurately: NAPT) at both the CPE and what is generically termed an LSN (large scale NAT) or CGN (carrier-grade NAT) device at the provider's edge. IPv4 traffic is translated a total of two times before it reaches the Internet. The two layers of NAT are required because NAT444 may be deployed on a new ISP at a point in the evolution of the Internet where virtually all the IPv4 space has been exhausted, and there may be no way for the provider to allocate addresses beyond the bare minimum that are required for the LSN/CGN devices. The IETF draft mentions class-E (240/4) and RFC1918 addresses that are candicates that can be used on the ISP's backbone network.
Pros: Assuming more CPEs start featuring IPv6 functionality, NAT444 is the only model that doesn't require the replacement of the CPE with some specialized hardware (and most likely centrally-managed) from the ISP. No DNS or address family translation is needed, which avoids most of the headaches and complexity common with many other migration designs.
Cons: Where do I start? Performing two sets of NAPT ("double-natting") causes large problems with numerous applications ranging from online gaming to VoIP. Unsolicited inbound connectivity may be impossible unless the ISP decides to offer some sort of customer portal service that can be used to reserve a set of ports on one or more addresses in the LSN/CGN pool for the customer. Even with this, the customer will have to configure the port forwarding on the CPE device, too. Auditing is also difficult with NAT444 because hundreds or even thousand customers could be sharing one IPv4 address. This also opens the door for botnets and spam to potentially get one or more of the LSN/CGN pool addresses blacklisted by any number of centralized RBLs (using the term loosely) on the Internet, effectively denying service to all the other customers who may be translated to these addresses.
IETF Internet-Draft: draft-mrw-behave-nat66-02
Summary: NAT66 is a method of providing flexibility for the migration of IPv6 networks that do not qualify for PI (provider independent, or in other words: portable) space between ISPs. A small network is typically provided a block of PA (provider assigned, or in other words: not portable) space when purchasing service from an ISP. However, if the network needs to change ISPs, all hosts and network devices must be renumbered, a time-consuming and hellish process. NAT66 defines a unique translation method that performs NAT between hosts on an internal network to a prefix provided by an ISP or other upstream provider. The NAT66 device does not track sessions and does not perform port translation. Additionally, an "algorithmic" approach to address selection during NAT allows for the assignment of translated addresses that cause the original and translated packets to share the same checksum. Although any prefix can be used on the internal network, it is recommended to use ULA addresses to prevent conflicts. DNS configuration must be altered whenever the PA space changes.
Pros: Somewhat easy to immplement. No state needs to be maintained on the NAT66 device.
Cons: The PA prefix must be 48 bits or less, otherwise the original and translated packets may not share the same checksum, potentially breaking some IP security imeplementations. Just like with any NAT, applications that encode the host's source address in the payload of the packets (stream) will require additional configuration or ALGs (application-level gateways) that can aid the translation of the payload on-the-fly.
IETF Internet-Draft: draft-ietf-behave-v6v4-xlate-stateful-11
Summary: Very similar to NAT-PT (RFC 2766), which has since been deprecated, NAT64 provides a mechanism for IPv6-only hosts to communicate with IPv4-only hosts through a device that implements NAT64 assisted by a DNS server that implements DNS64. NAT64 is stateful, meaning that the NAT64 device keeps track of all connections, since the addresses on the IPv4 side of the NAT64 device are obviously in short supply, and must be overloaded, using port translation. DNS64 allows IPv6-only hosts to be provided synthesized AAAA RRs that actually point to IPv6 addresses with embedded IPv4 addresses. These addresses ultimately are routed to the NAT64 device that map connections to the IPv4 host in question. New connections initiated from IPv4-only clients back to IPv6-only clients are only allowed with the definition of static mappings and optionally custom DNS records (DNS64 does not help with this).
Pros: Provides a [better] replacement for NAT-PT and NAPT-PT.
Cons: It's complicated, and only works with TCP, UDP, and ICMP. The combination of having to synthesize AAAA RRs and maintain complex session state seems to make this setup quite fragile. Communication is also only one-way by default.
Request for Comments: 5569
Summary: 6rd stands for IPv6 Rapid Deployment. It's very similar to 6to4, and even uses the standard IP protocol 41 method to encapsulate the IPv6 packets into IPv4. However, it's different because it's only used within an ISP, which doesn't need to have a dual-stack backbone. An ISP first sets up a 6rd relay at their edge, and connects it to the IPv6 Internet. It then sets aside a prefix that will be used for 6rd, and the ISP's customers use this prefix + IPv4 address to build their own prefix that can be used for SLAAC internally. The ISP anycasts their 6rd relays and preconfigures the customer's CPEs (which ends up being just a modified 6to4 implementation) to connect to tunnel IPv6 traffic to this address. Traffic destined to this prefix (return traffic) from the Internet gets routed to the customers via the 6rd relays.
Pros: Easy to implement. No need to dual-stack the whole ISP's backbone. Does not imply the need for LSN/CGN.
Cons: The 6rd address space can't be a prefix longer than 32 bits. This requires the ISP to get a prefix shorter than a /32 from its RIR. Modification of CPEs is necessary.
IETF Internet-Draft: draft-ietf-softwire-dual-stack-lite-04
Summary: Dual-Stack Lite (or shortened to DS-Lite, and sometimes slightly incorrectly referred to as NAT464) is very similar to NAT444, with the exception that IPv4 NAT is only performed once, by the LSN/CGN at the ISP's edge. Just like NAT444, DS-Lite will most likely gain popularity once all free IPv4 blocks have been exhausted. Using a custom CPE running a piece of the AFTR software, IPv4 connections from a customer's network are tunnelled over the ISP's IPv6 backbone to the LSN/CGN, where connections reach the IPv4 Internet. So, essentially, DS-Lite is like NAT444, but the IPv4 connections across the ISP's backbone are tunnelled inside IPv6. The LSN/CGN devices also add the CPE's IPv6 address to the NAT translation table for IPv4 connections, since it's likely that many residences will overlap with each other's RFC1918 space.
Pros: Eliminates the issues associated with performing NAT twice. Requires very little IPv4 addresses.
Cons: CPEs must be replaced. This is a large undertaking. MTU issues may arise due to the IPv4 tunnelling.
Displaying page 3 of 8 of 59 results
     |
This HTML for this page was generated in 0.028 seconds. |