Not too long ago, we got a tablet, an Asus Transformer Infinity. Initially it was loaded with Android 4.0, but there was an upgrade waiting from Asus to 4.1, so we didn't use 4.0 very long.
This isn't a review of the tablet itself, but rather some things I've discovered about 4.1 and how it works on tablets that I'm not exactly thrilled with.
Flash: Technically, as of 4.1, Android no longer supports Flash. However, since we downloaded and installed it before we upgraded to 4.1, it's still on the tablet. Chrome won't load any flash anymore, but the built-in Android Browser will...sorta. Honestly, I think the decision to drop support for flash was premature. I think flash is a crap program, and a security hole, and a resource hog, but there are simply too many websites that still rely on it for fundamental functions. Part of the reason I didn't want an iPad is the lack of support for flash that makes trying to use the web on a tablet a frustrating experience. We bought this tablet as a replacement for a dead laptop, and the lack of flash support means that we are still reliant on a PC for some websites. Saying, "well, websites shouldn't use flash, they should use HTML5" just doesn't solve the problem.
Chrome: In addition to the Chrome/flash thing, mobile Chrome has one major problem- it sends the same user agent string whether it is on a mobile phone or on a tablet. Therefore, some sites insist on redirecting you to the mobile optimized site, despite the fact that the tablet has higher resolution (1920x1080) than either my desktop PC or my laptop. Chrome has a menu item called "request desktop site" but it is site specific rather than a default option, and some sites ignore it and still send you to the mobile site, so I think perhaps they need two different user agent strings to differentiate, or the ability to change to a different user agent string like you can with Dolphin. It'd also be nice if Chrome supported the same plugins that it does on the desktop so that you truly has the same experience on both platforms.
Apps: I imagine this is a common problem with apps whether iOS or Android, but a lot of apps aren't properly optimized for the resolution and capabilities of a tablet. The Facebook app is almost useless because the layout is so mobile-optimized, but since you can get to the desktop version, that's not a huge loss.
Keyboard: The Jellybean keyboard on a tablet is a good bit different than on a phone. (I've been using the Ice Cream Sandwich keyboard on my phone for a while, so I'm not doing a direct comparison...) The keys don't pop out to register touch, and the keys are larger, more like a real keyboard, at least in landscape mode. It takes up about half of the screen in landscape, and touch-typing actually isn't impossible once you get used to the weird hovering hand position you have to use. Two main things that make touch-typing difficult: The first is that the space bar is a bit narrow. Specifically, android has a notification/menu area at the bottom of the screen, but it is blank in the area just below the space bar, and so you end up pressing the blank area instead of the space bar if you aren't careful with your thumb placement. The second is that it's not a full qwerty keyboard so you end up inadvertently pressing the enter or backspace key or shift key with your pinky. Additionally, there isn't a dedicated row of numbers nor do they retain the ability to long-press on the top row to get a number without switching to the number/symbol keyboard, which makes entering passwords sort of laborious. In portrait mode, the keyboard takes up about a third of the screen, layout is the same, just smaller keys better suited for thumb typing. It bothers me that they didn't include a split keyboard option for either orientation, because I think that'd be a nice option to have for quick typing in landscape. The auto correct and predictive text work well, but I've noticed that the keyboard is laggy at times, and I think it's due to the overhead of the prediction engine. If a Tegra quad-core can't handle it, it's not really ready for primetime.
For the most part, I like the UI, these are just the little nits I've noticed that I hope they fix in the next version.
Sunday, October 21, 2012
Thursday, August 30, 2012
IPv4, Carrier-Grade NAT, IPv6 deployment, Standards Bodies, Politics, and Religion (aka, “Things to avoid discussing during dinner…”)
Normally this blog is mostly personal, a lot of travel log stuff, and a few bits of personal geek musings. So I’ll warn my usual readers (all both of you) that this one is a republish of a professional article that I wrote a few months ago for one of the technical journals that I read. It’s long, technical, full of jargon and likely to be boring to most people who aren’t already involved in Internet Plumbing, but I wanted to republish it here in a slightly less “printy” format than the PDF (restore the hyperlinks, etc).
A version of this article was first published in The Internet Protocol Journal (IPJ), Volume 15, No. 2, June 2012. For more information about IPJ, please visit http://cisco.com/ipj
Shared Transition Space: Is it necessary?
by Wesley George, Time Warner Cable
Recently, the Internet Engineering Task Force (IETF) approved [1] and the Internet Assigned Numbers Authority (IANA) allocated [2] a new IPv4 address block (100.64.0.0/10) designated for use as “Shared Transition Space” in support of the IPv6 transition. This decision was highly controversial within the different standards and policy bodies that discussed the idea. The author would like to note that people have been debating this topic for years, and nearly everyone within the broad stakeholder community seems to have a strong opinion on the matter, including me. Despite the best of intentions, some of my opinions and biases may appear within the article. I did not intend this article to be a definitive conclusion on the matter, but rather a summary of the recent discussion. Whether the standards bodies involved came to the “right” or “wrong” conclusion—as well as the veracity of the arguments on both sides—is an exercise for you, the reader.
Internet Service Providers (ISPs) and users have significant investments in equipment and applications that must be updated to support IPv6. Progress is accelerating with regard to IPv6 availability in hardware, software, and access, though broad availability remains a long-term problem. In the interim, IPv4 will continue to be an important capability for providing users with access to Internet resources. As a consequence, considerable effort has been expended in conserving the increasingly scarce IPv4 resources while maintaining “business as usual.” This conservation has taken the form of policies for address allocation and management [3], as well as new protocols and technologies. It is likewise important to note that ISPs must manage IPv4 exhaustion in a way that is least disruptive to users while undertaking full IPv6 deployment—two completely different and parallel activities. Any business that relies entirely on efforts to extend the useful life of IPv4 without executing on an IPv6 deployment plan is merely delaying the inevitable effects on their customers and ultimately their profitability.
IPv4 “life extension” is an area that remains controversial. Some believe that any effort to extend the useful life of IPv4 and allow the IPv4 Internet to keep growing beyond its original design limitations will seriously affect the timeliness of reaching critical mass with IPv6. The idea that many opponents of the “life-extensions” methods are supporting is that IPv4 exhaustion and the resulting transition from IPv4 to IPv6 is going to be disruptive to customers and operations no matter when it actually occurs. From this perspective it is preferable to have a brief—but significant—disruption and transition completely to IPv6. This plan is akin to the idea that it is better to just rip the bandage off and have a moment of pain than removing it slowly in an attempt to reduce the pain.
The counterpoint to this argument is that we must look at the situation pragmatically with the goal of maintaining business continuity, growth, and customer satisfaction.
IPv4 Exhaustion
The impending IPv4 address exhaustion [4]and the problems it will create has been the topic of much discussion in many different areas of the Internet community. The need to deploy IPv6 has figured prominently in the discussion, because it is the proper long-term solution. However, the unfortunate reality is that deploying IPv6 is a parallel activity to any work that provides continuity to the existing IPv4 network in order to keep it operational and able to grow to meet demand. As an Internet community, we are not where we need to be in terms of critical mass of our IPv6 deployments, in terms of either available, deployed equipment that supports IPv6 fully or applications that are able to use IPv6 when it is available.
IPv6 deployment is a requirement, but most ISPs do not have control over all variables affecting IPv6 deployment, and they have limited influence on progress outside of their network boundaries. This reality is especially true with residential services, where customers often purchase IP-enabled hardware directly from retailers to connect to their home networks. Consumers generally do not care about whether a device supports IPv4 or IPv6, so they do not make purchasing decisions based on such features. Customers should not be required to be technology experts in order to get their devices to work properly for their intended use. Customers generally are not interested in their ISP dictating the equipment that they may use in their home, and they do not like being told that they must replace “obsolete” gear, especially if they purchased it recently. The service provider sells “Internet” service, so customers expect their “Internet” devices to work—period. As a result, if an ISP wants to continue to grow, that ISP must continue to offer IPv4 services until the existing equipment without IPv6 support ages out of the network and is replaced.
The IETF recently released a Best Current Practice (BCP) document [5] that provides some guidance for implementers that support for IPv6 on “IP-capable” devices is going to be a necessity, and the Consumer Electronics Association (CEA) now has a working group on IPv6 Transition [6]. In conjunction with events like World IPv6 Launch [7], there are near-constant improvements in the availability of IPv6-capable hardware, software, access, and services. The result of this situation should be that critical mass of IPv6 deployment will happen soon and reduce reliance on IPv4 and IPv4 life-extension technologies.
Because of the costs, operational complexities, performance concerns, and effects on customers that most IPv4 life-extension technologies create, service providers should focus on reaching IPv6 critical mass in essential areas.
When IPv6 has become sufficiently ubiquitous, the need for IPv4 life-extension technologies will be reduced along with the scale of deployments. Because a lot of the costs of deploying IPv4 life-extension technologies are initial costs, there is some truth to the argument that after they are deployed they are unlikely to disappear anytime soon. Why would a carrier invest significant time and money in deploying something only to pull it back out a short time later? Therefore the best method to reduce the cost of Carrier-Grade NAT (CGN) deployment is to work to deploy less of it.
ISPs are different when it comes to their expectations for growth, and their IPv4 addressing reserves or consumption rates differ accordingly. Some have areas of their internal network where they can make changes and reclaim globally unique IPv4 addresses for reuse to support customers, some have addresses that can be reclaimed via auditing and improved efficiency of allocation, and still others have already undertaken many of these projects and do not have much address space left to reclaim. Further, new IPv4 address availability as a combination of policies and demand may be different for each Regional Internet Registry (RIR). To summarize, the need for IPv4 address life-extension technologies is different on each network. The costs of deploying, the complexity of supporting, and the growth rate all figure into how widely service providers will have to deploy one or more technologies to extend their remaining IPv4 resources.
NAT444
Network Address Translation (NAT) [28], [30] is already widely used for translating one IPv4 address to another, usually to provide separation or address sharing between a private network with multiple hosts and a public network or the Internet. In the context of IPv4 and IPv6 transition, these types of NAT are commonly referred to as NAT44, because they translate between IPv4 and IPv4 (vs. IPv4 to IPv6, IPv6 to IPv6, etc.). There is a proposed extension to NAT intended to preserve even more IPv4 resources. This proposal is called Carrier-Grade NAT (CGN) [8]. The “Carrier Grade” in the name originates from the position of the NAT within the topology. Instead of NAT between a private and public network at the edge of a single network such as a home or business office, CGN is implemented inside of an ISP’s network and serves many customers simultaneously. These CGN implementations are typically scaled to handle thousands of simultaneous customer endpoints, often resulting in millions of simultaneous sessions. The RFC [8] does not advocate the use of CGN; it describes how an ISP forced to deploy CGN can use it during IPv6 transition.
This sort of implementation addresses the need for an individual, globally unique IPv4 address for each of the ISP’s customers by allowing the ISPs to allocate each customer an IPv4 address that may not be globally unique and employ NAT to give them access to resources on the IPv4 Internet.
This sharing often allows ISPs to see oversubscription of public IPv4 addresses anywhere from 2:1 to more than 10,000:1 based on the type of applications behind the NAT and their simultaneous application layer port allocations and session counts. Most commonly, a CGN is used in conjunction with a local NAT on the customer’s home network, creating two layers of NAT to traverse between the home network and the Internet. This model is commonly referred to as NAT444, because there is a translation layer between three sets of IPv4 addresses end to end.
A known problem with NAT is that it makes end-to-end communica-tion and visibility between hosts more difficult, because it essentially hides hosts behind address translation. Because NAT is so common (nearly every home network and many commercial networks use NAT), networking applications have adapted so that they can discover the presence of a NAT and then change their behavior in order to maintain communications in the presence of NATs. However, the addition of this second layer of NAT often interferes with those workarounds, and undesirable or unpredictable results may occur [9].
Over time it is likely that applications will again adapt to the impediments created by multiple layers of NAT, but it is not possible to anticipate and correct every potential problem that may be generated by adding this second layer of NAT. This reality should serve as a warning to those who provide services over an Internet connection: IPv6 support is extremely important. IPv6 is important because CGN means that ISP-controlled equipment will be actively involved in the path between content or application providers and their end users, making that relationship reliant on the service provider and the service provider’s CGN vendor to an extent that was not necessary in the past. If the CGN implementation breaks something, it not only reflects on the CGN vendor and the service provider, it also reflects poorly on the relationship between the end customer and the service that that customer is using—and may cause that customer to form a negative opinion of the brand itself.
In other words, if a consumer uses an Internet-enabled application on a new Brand X smart TV and it does not work well, regardless of whether it is a problem with the CGN, the service provider, or something else entirely, the consumer may form the opinion and share via an online review that, “Brand X’s TVs are ok, unless you try to use any of their fancy new features. I would not buy one if I were you, because Company X clearly does not know what it is doing.” CGN represents a potentially significant increase in the amount of testing that must be done, especially in implementations that are uncommon, such as small, corner-case deployments, and closed architectures. Although using IPv6 is dependent on support at the client, the content or application provider, and the ISPs in between, if this support is present, it allows the content or application provider and client to bypass the service provider’s CGN machinery—as well as any IPv4 NAT that may be present—and have a true end-to-end connection. This scenario restores control over the user experience back to the brand, and allows the ISP to resume supplying bit carriage.
IPv4 Addressing Requirements
Independent of the potential connectivity problems that NAT444 may create, it generates additional problems for the implementing ISP because of its need for IPv4 addresses. Because the CGN requires two sets of addresses—one for the inside (private) network and one for the outside (public) network—the ISP must identify address ranges to use for both. In order for its customers to be able to reach the Internet, the external pool must use globally unique IPv4 addresses. The number of addresses required will depend on the implementation of CGN, its scale profile, the topology of the network (how many hosts are behind each CGN instance), and the usage profile of the customer traffic. If the service provider has few or no available globally unique IPv4 addresses, it will have to either make changes in its network in order to reclaim addresses from elsewhere or make a request for a new allocation from its RIR [29].
However, depending on the number of addresses that the RIR has available and its policies for justification, it may not be possible to obtain sufficient address space with this method. For example, in the Asia-Pacific region, the austerity policies in place mean that no matter how many IPv4 addresses they might have been able to justify using previous rules, most requesters are eligible for only a few hundred IPv4 addresses as their final allocation ever [10]. This situation then requires the ISP to source IPv4 addresses via the IPv4 address transfer market [11], adding additional cost to an already expensive deployment. In fact, if the service provider must source addresses via the transfer market, it may be more cost-effective to simply obtain more addresses and continue with business as usual without deploying CGN at all.
Internal Pool: Private Addressing Alternatives
When addresses are sourced for the public address pool, the service provider must also identify a pool of private addresses that is large enough for the provider to allocate one to each customer behind the CGN. Depending on the size and scale of the CGN, and how much the service provider is willing to segment and separate different sections of its network, this number could be a large block of addresses, perhaps even a/8 or more.
The most obvious choice might be to simply use address ranges reserved for private network use [12], because there is a /8, a /12, and a /16 available for this purpose. However, this address space has some drawbacks. First, because of the prevalence of RFC 1918 addressing within most enterprise networks, there is a significant chance that the chosen address blocks may conflict with existing use of RFC 1918 space for management systems and other internal resources. Depending on the size of the CGN implementation, it may be necessary to instantiate multiple segments of the network where the entirety of RFC 1918 space is used, and in order for those segments to talk to one another or to talk to devices with conflicting numbering, significant additional complexity is required.
On the customer side, remote workers could experience problems where the address that they have been assigned is in a block that is already in use on their company’s enterprise network, meaning that it may cause problems connecting to those hosts via a Virtual Private Network (VPN), or problems accessing some of the resources from the remote network. It may be possible to change the address assigned to the end user in an attempt to eliminate this conflict, but this approach is not necessarily scalable because it likely requires manual intervention in an automated address-assignment system, and there are limits to the number of times that a change of address can “fix” this problem without creating a problem for another user.
The other problem with the use of RFC 1918 space in the CGN is that it may conflict with the address space used by the customer’s local network and NAT. For example, if a customer has a local network numbered out of 192.168.1.0/24 and the customer’s router is allocated the external address of 192.168.1.85, the router may fail to function properly because it has the same address range on both the internal and external interface. It may be possible through analysis to identify and carefully allocate addresses so that the portions of RFC 1918 commonly used by default in home gateway devices are not allocated. However, anecdotal evidence [13] suggests that because of the wide variety of devices and implementations available—plus the fact that many users reconfigure their networks to use a different IP address range than the default configuration of the device—there simply may not be enough RFC 1918 addresses not in use to make this option viable.
“Squat” Space
Another alternative is to unofficially reuse one or more portions of the existing range of allocated globally unique IPv4 addresses as private addresses. In a network that does not talk directly to the Internet, such as a private network or VPN, the existing allocations of IPv4 space do not have any meaning, and so it is not strictly necessary to stick to RFC 1918 address space for numbering resources that are only internally accessible. Reuse of allocated IPv4 addresses has the benefit of not conflicting with in-use RFC 1918 addresses, but comes with its own set of problems. If the provider’s own space is reused, the provider must carefully separate the private use from the public use to avoid conflicts, and managing this overlap may require additional complexity such as the use of VPNs as a method to separate the networks. The more common method is to reuse a block of addresses that is not currently allocated to the network using them; in other words, squatting on “someone else’s” address space. Usually providers select space to use in this manner based on a low likelihood that either the owner will begin announcing the space on the global Internet or the users behind that network will need to connect to the users behind the ISP’s NAT.
This method requires extreme care. The service provider must ensure that the routes for those prefixes are not inadvertently leaked to the global Internet, because such a leak could potentially cause a route-hijack denial-of-service attack, albeit an unintentional one. This method is even more risky if the ISP has one or more partners who have connections into the private portion of its network, because it may not have complete control of the announcement boundaries. Certainly there are safeguards such as tagging the announcements with Border Gateway Protocol (BGP) communities such as no-advertise or no-export [14], but these solutions are not always practical, and they are not completely fail-safe. Depending on the chosen address space, the effects could be significant based on the true owner of that space—no service provider really wants to risk a public relations nightmare because it inadvertently caused an outage affecting the critical infrastructure of a large government agency or multi-national corporation whose space it “borrowed” and then leaked to the Internet.
As a result of the IPv4 transfer market, it is quite likely that some of the address blocks that are not visible on the global Internet today and that some consider “safer” to squat on may end up being transferred to another party who plans to begin using them on the public Internet, and potentially requiring those squatting on the space to renumber to a different address block. ISPs can mitigate this risk somewhat by selecting multiple candidate blocks that are all preconfigured in the network such that it is relatively straightforward to make a rapid change from one block to another if the current block in use suddenly becomes unacceptable. Many ISPs use this method today, but because of the risks, it cannot be considered a real solution to the problem. Further, because it essentially encourages large service providers to violate the spirit—if not the letter—of the very policies that govern IP address allocation and use, standards bodies such as the IETF or policy organizations like RIRs cannot officially recommend such a solution.
Class E Addresses
A final alternative is to repurpose the reserved space in 240/4 [2] and make it available for this use. There have been several failed attempts to repurpose this reserved space within the IETF in the past few years [15],[16].The primary challenge with this alternative is that because the Class E space has been reserved for many years, many networking implementations are explicitly configured to reject this address space as invalid. Getting this problem fixed in software, and more importantly, getting those software upgrades deployed widely, may require a similar level of effort to that which is required to deploy IPv6, and deploying IPv6 would be a more effective use of the resources required to implement software and hardware changes.
Even in situations like a CGN where more of the implementation is under central control, this solution would be attractive only to a service provider that owns and operates the Customer Premises Equipment (CPE) routers for all of its customers such that it could work with a small number of vendors to get software patches to enable use of this space. Therefore this solution is also too limited in applicability to be seen as a general solution that a body like the IETF could recommend.
Shared Addresses
Although the solutions previously discussed may be acceptable in some applications, the risks and deficiencies make it necessary for other applications to find another source for the IP address blocks to be used on the private side of a CGN. It is possible to use “public” (globally unique) IPv4 addresses on the private side as well, but the challenges to obtaining additional public IPv4 addresses that were discussed previously are exacerbated by the even larger number of addresses required, so this solution is far from practical. Additionally, expecting each service provider that implements CGN to obtain its own address space for its inside pools would end up using a significant amount of the remaining IPv4 resources in a way that does not necessarily require globally unique addresses. However, because each service provider has different needs, growth rates, and applications, it is unclear that simply expecting each service provider to request space from the RIRs for its internal CGN pools would create a doomsday scenario where a few networks would use up all of the remaining available IPv4 space in a short time. Because CGN creates additional costs and complexity to implement and support, and could be viewed as “second-class” IPv4 service, most service providers are not likely to implement it across the entire network and all tiers of customers, instead preferring to implement it only as widely as absolutely necessary.
Service providers could choose to implement it only for net new customers (that is, growth above turnover); they could choose to implement it only in certain markets or for certain types of service where it is less likely to cause support problems and adversely affect the service. All of these things reduce the number of addresses that may be needed for the interior CGN address pool. Nevertheless, using globally unique addresses in an application that does not require unique addresses is not a good use of a very limited resource. That is why the idea of having a shared and reserved block of addresses specifically for use as an interior (private) pool on a CGN keeps resurfacing.
One alternative to formally reserving a shared transition space was to have a third party request a block of sufficient size from one or more of the RIRs and then make it available for use as a shared block by anyone who wishes to do so.
Given the “last /8” policies in effect at each of the RIRs, it would likely be quite difficult to justify sufficient space to be useful, and the cost involved in receiving and maintaining such a delegation would likely be prohibitive. There would also be challenges addressing potential abuse concerns.
Reserving a block via the standard IETF/IANA process meant that IETF would have a chance to document the problems and recommend best practices that must be considered when implementing something that uses this shared space. This policy would help to ensure that service providers and implementers are aware of these guidelines and recommendations. For example, many implementations make certain assumptions about address scope based on the address itself, such as assuming that RFC 1918 addresses are locally scoped, and then adapt their behavior accordingly. With things like squat space or an unofficially shared CGN space, implementers would not know that this space should be treated in a specific way, and the result may be more network breakage. The officially declared shared space must still wait for implementers to make changes to their products, and that may not always happen, but the chances are still better than if it had been done in an unofficial manner.
As you can probably see, this problem does not have a clear-cut and straightforward solution, and this situation has led to vigorous discussion within the standards and policy bodies that have discussed it. The next section gives a brief history of the activity in those bodies that ultimately led to the space being allocated.
Some History
Shared transition space proposals have been controversial each time a variant of the idea has come up for discussion. As IPv4 exhaustion became a reality and IPv6 deployment continued to lag, more people realized that IPv4 life-extension technologies such as CGN may be a necessary evil. When people saw CGN as a likely response to the gap between IPv4 exhaustion and wide IPv6 support, they began to understand the need for the shared transition space, and thus support for allocating that space has gradually grown.
Although variants of this discussion may be much older than the items discussed in the following paragraphs, this article focuses specifically on the history of the idea to allocate shared address space specifically for CGN. There was an unsuccessful proposal in 2005 [17] to update RFC 1918 with an additional three /8s, but this proposal was not specifically focused on CGNs, unlike some of the other proposals. The most recent set of proposals regarding shared CGN space first came up in the APNIC Policy Special Interest Group (SIG) in early 2008, where Policy Proposal 058 was discussed. APNIC members abandoned the proposal and recommended that the authors take the idea to the IETF, because that is the body that typically directs IANA to reserve IP address blocks for special uses such as this one [18].
This recommendation resulted in a pair of Internet drafts [19], [20], hereafter referred to as shirasaki in late 2008. The draft originally requested four /8s, with a minimum size of a /12, but subsequent revisions of the draft revised the request to only one /10. The draft never gained much traction within the IETF, but the authors continued to update it to keep the discussion going. In mid-2010, a second IETF draft [21] was published, requesting that a full /8 be reserved for this purpose. It contained references to the shirasaki drafts, but provided additional justification and noted that a /10 may not be enough addresses for many of the large service providers.
The draft went through several revisions in the following months, eventually being replaced by a different draft [22], hereafter referred to as draft-weil, which reduced the /8 requested down to a /10. Attendees of the IETF 79 meeting in Beijing, China, discussed the draft across two different working groups. People expressed strong opinions both in support of and in opposition to the idea, but the draft did not achieve clear consensus. With the future of the draft unclear, one of its authors submitted policy proposal 127 to the American Registry for Internet Numbers (ARIN) [23]. The ARIN Advisory Council (AC) accepted this policy proposal as draft policy 2011-5 [24] in early 2011, and vigorously discussed it with participants at the ARIN XXVII public policy meeting and with members of the mailing list. At the conclusion of the discussion, the ARIN AC recommended the policy to the ARIN board for adoption.
This discussion took on additional urgency because during this time the IANA officially announced that it had exhausted the free pool of IPv4 addresses and delegated the last of the /8s to the RIRs in accordance with policy [4]. The side effect of this exhaustion meant that it was no longer possible for IETF to direct IANA to reserve space unless IANA was directed to repurpose an existing reservation, because it had no unreserved address blocks of sufficient size to meet the request. Therefore, the IETF and one or more of the RIRs would have to work in concert to make a suitable IPv4 address block available, instead of it being solely under IETF’s purview. ARIN staff reached out to the IETF’s Internet Architecture Board (IAB) for guidance, because by strict interpretation [25], ARIN was not authorized to make this allocation by itself. IAB reaffirmed this interpretation, and recommended that the matter be brought back to the IETF for (re)consideration [26]. With this guidance, the authors revised draft-weil-shared-transition-space-request and reintroduced it for discussion. For a period of time, the document was split into two, with most of the long-form discussion of pros and cons being moved to a second draft [27].
As of the publication date of this article, the secondary draft has expired without progressing, but most of the important information contained there was incorporated back into draft-weil. The document was not adopted by any IETF Working Group. Instead, an IETF Area Director sponsored it as an individual submission.
It went through its first IETF “Last Call” to gauge consensus and receive comments in August 2011. The subsequent discussion, revisions, and secondary last calls (October 2011 and January 2012) generated hundreds of messages on the IETF discussion list and a total of 12 versions of the document before it was approved for publication in February 2012.
The reason why the debate on this shared transition space was so spirited can be traced to a few critical concerns. First, although consensus-based RFCs documenting CGN [8] were already approved, this draft allocating space specifically to facilitate its deployment became a referendum within the IETF on whether NAT444/CGN should even be used. If you believed that NAT444 and CGN were bad ideas, it was likely that you would also be against a shared transition space. From that perspective, shared transition address space provided a more complete solution to a problem that had been created by a “Bad Idea” that should not have been allowed to proceed in the first place. There was also resistance to what was deemed “waste” of the limited remaining blocks of IPv4 addresses to solve a problem that not everyone agreed was a real or important problem. Also, although IETF participants do not speak for their companies per se, this proposal had consistent support from numerous individuals employed by large residential broadband providers. As a result, some saw it as those service providers looking for a way to bail themselves out of a problem that they created by not deploying IPv6 rapidly enough to avoid having to use CGN. On the converse side of the argument, those in favor saw CGN as a largely foregone conclusion, and saw this proposal as simply a practical solution to a real problem.
The Internet Engineering Steering Group (IESG) ultimately sent a note to the IETF discussion list acknowledging the difficulty of coming to a decision on this matter and noting that some explanatory text would be added to RFC 6598:
“Colleagues,
The IESG has observed very rough consensus in favor of the allocation proposed in draft-weil-shared-transition-space-request. Therefore, the IESG will approve the draft. In order to acknowledge dissenting opinions and clarify the IETF position regarding IPv6, the IESG will attach the following note:
“A number of operators have expressed a need for the special purpose IPv4 address allocation described by this document. During deliberations, the IETF community demonstrated very rough consensus in favor of the allocation.
While operational expedients, including the special purpose address allocation described in this document, may help solve a short-term operational problem, the IESG and the IETF remain committed to the deployment of IPv6.”
In many ways, the final decision came down to the difference between theory and practice in the IETF’s desire to make the Internet work better. Theoretically, making a CGN easier to implement has the potential to make the Internet work much more poorly, and could be seen as rewarding bad behavior (failing to deploy and support IPv6 in a timely fashion). However, in practice, making CGN harder to implement causes unnecessary pain and effort for operators and potentially for users, while having little or no effect on IPv6 deployment. Approving this shared transition space avoids the appearance that IETF is trying to punish operators or users for perceived past “sins” and helps to reinforce the idea that IETF is responsive to operational concerns and therefore still relevant to the operator community. It is unlikely that the result of this decision will have much bearing on an operator’s plan for how widely, when, where, or even if it will deploy CGNs, and this article makes no such recommendations. However, I will reiterate that IPv6 is the long-term solution, and that the smallest CGN deployment possible will make for a less complex and less expensive network for the continued support of traditional IPv4 devices.
Acknowledgements
Special thanks to Ole Jacobsen for suggesting that I write this article, to Kirk Erichsen and Jason Weil for their review and comments, and to all involved in the discussion of the referenced IETF drafts and ARIN policy for giving me plenty to write about!
References
[1] Victor Kuarsingh, Chris Donley, Jason Weil, Marla Azinger, and Christopher Liljenstolpe, “IANA-Reserved IPv4 Prefix for Shared Address Space,” RFC 6598, April 2012.
[3] RIR Policies triggered by IPv4 Depletion:
[5] Chris Donley, Christopher Liljenstolpe, Wesley George, and Lee Howard, “IPv6 Support Required for All IP-Capable Nodes,” RFC 6540, April 2012.
[8] Sheng Jiang, Brian Carpenter, and Dayong Guo, “An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition,” RFC 6264, June 2011.
[9] Chris Donley, Lee Howard, and Victor Kuarsingh, “Assessing the Impact of Carrier-Grade NAT on Network Applications,” Internet Draft, work in progress, November 2011,
draft-donley-nat444-impacts-03
[12]Daniel Karrenberg, Yakov Rekhter, Eliot Lear, and Geert Jan de Groot, “Address Allocation for Private Internets,” RFC 1918, February 1996.
[15]Vince Fuller, “Reclassifying 240/4 as usable unicast address space,” Internet Draft, work in progress, March 2008, draft-fuller-240space-02
[16]Paul Wilson, George Michaelson, and Geoff Huston, “Redesignation of 240/4 from ‘Future Use’ to ‘Private Use,’” Internet Draft, work in progress, September 2008, draft-wilson-class-e-02
[17]Tony Hain, “Expanded Address Allocation for Private Internets,” Internet Draft, work in progress, February 2005, draft-hain-1918bis-01
[18]Shirou Niinobe, Takeshi Tomochika, Jiro Yamaguchi, Dai Nishino, Hiroyuki Ashida, Akira Nakagawa, and Toshiyuki Hosaka, “Proposal to create IPv4 shared use address space among LIRs,” prop-058, January 2008,
[19]Jiro Yamaguchi, Yasuhiro Shirasaki, Shin Miyakawa, Akira Nakagawa, and Hiroyuki Ashida, “NAT444 addressing models,” Internet Draft, work in progress, January 2012, draft-shirasaki-nat444-isp-shared-addr-07
[20]Ikuhei Yamagata, Shin Miyakawa, Akira Nakagawa, Jiro Yamaguchi, and Hiroyuki Ashida, “ISP Shared Address,” Internet Draft, work in progress, January 2012, draft-shirasaki-isp-shared-addr-07
[21]Jason Weil, Victor Kuarsingh, and Chris Donley, “IANA Reserved IPv4 Prefix for IPv6 Transition,” Internet Draft, work in progress, September 2010, draft-weil-opsawg-provider-address-space-02
[22]Victor Kuarsingh, Chris Donley, Jason Weil, Marla Azinger, and Christopher Liljenstolpe, “IANA-Reserved IPv4 Prefix for Shared Address Space,” Internet Draft, work in progress, February 2012. (Became RFC 6598[1]), draft-weil-shared-transition-space-request-15
[23]ARIN Public Policy Mailing List (PPML), “Shared Transition Space for IPv4 Address Extension,” ARIN-prop-127
[25]Brian Carpenter, Fred Baker, and Michael Roberts, “Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority,” RFC 2860, June 2000.
[26]Internet Architecture Board, “Response to ARIN’s request for guidance regarding Draft Policy ARIN-2011-5,”
[27]Stan Barber, Owen Delong, Chris Grundemann, Victor Kuarsingh, and Benson Schliesser, “ARIN Draft Policy 2011-5: Shared Transition Space,” Internet Draft, work in progress, September 2011,
draft-bdgks-arin-shared-transition-space-03
[28]Geoff Huston, “Anatomy: Inside Network Address Translators,” The Internet Protocol Journal, Volume 7, No. 3, September 2004.
[29]Daniel Karrenberg, Gerard Ross, Paul Wilson, and Leslie Nobile, “Development of the Regional Internet Registry System,” The Internet Protocol Journal, Volume 4, No. 4, December 2001.
[30]Geoff Huston, “NAT++: Address Sharing in IPv4,” The Internet Protocol Journal, Volume 13, No. 2, June 2010.
[31]The Internet Protocol Journal, Volume 14, No. 1, March 2011. This issue of IPJ is entirely devoted to the topic of IPv4 address depletion and IPv6 transition.
[32]Michelle Cotton and Leo Vegoda, “Special Use IPv4 Addresses,” May 2012, draft-vegoda-cotton-rfc5735bis-02
WESLEY GEORGE has been working in IP networking for approximately 13 years, across operations, engineering and capacity planning, architecture, and design in large wired and wireless networks. He has been heavily involved in IPv6 evangelism and deployment for a surprisingly long time. He has been an active participant in IETF for 5 years, including serving as former co-chair of the IPv6 Renumbering (6renum) working group and current co-chair of the sunset4 working group. He was active in ARIN’s policy development process during the time that the policy discussed in this article was being addressed. He currently works for Time Warner Cable, but this article represents his views alone, and should not be mistaken for his current employer’s official stance on anything.
Tuesday, February 14, 2012
San Diego
NANOG was meeting in San Diego this past week. Normally, in an attempt to reduce my travel, I don't go to NANOG, because there are several other folks from my company that go, and I can catch the sessions that I think look interesting via streaming video. However, this time there was another meeting happening directly after NANOG such that I figured if I was going to fly out to San Diego anyway, I should just go for the week. This was my first trip to San Diego. Generally it was a pretty good trip. A couple of brief impressions about San Diego. First of all, the weather was lovely! It was in the 70s most of the week, and actually hit 75 the last night I was there. One day of rain, the rest were all sunny. This was a good thing, because San Diego is a pretty walkable city, at least the area where I was. I did have to take a cab to and from the airport, but that was mainly because getting away from the airport involved a freeway with no sidewalk, not distance - it was something like 2.5 miles, which would have been quite doable if it had been safe to do so.
The conference was located at the Westin in Gaslamp Quarter. There were no rooms left in the block by the time I booked, so I ended up staying at the Sheraton Suites at Symphony Hall. It's about .5 mile from the Westin. It was a servicable hotel, but as a recent Starwood convert (previous employer had corporate contracts with Hilton), I have noticed one thing - both of the Sheratons that I have used have been overpriced by comparison with their competitors, have been a bit dumpy (in need of a remodel), and have had internet service that was borderline useless that they still insist on charging you $9.95 a day for. I like Aloft and Westin, but I think I'm going to start avoiding Sheratons where I have an option.
Anyway, there are a lot of dining options in the Gaslamp Quarter area, so when we'd break for lunch, I pretty much just pulled up Yelp and looked for something interesting each day. Here's the short rundown of the places I tried:
Hodad's - this is a burger joint that was featured on Diners, Drive-ins, and Dives, and the episode featuring them was rerunning about a week or two before I left on this trip, so it was in the front of my mind. I didn't go to the original (the one actually featured on DDD), but the burger and fries were still good, and I had a tasty local copper ale to wash it down. I got their Blue Jay Burger, which is a Bacon Cheeseburger with Blue Cheese cooked into the patty, topped with grilled onions. Those flavors worked really well together.
Bite M.E - This is a cutely named Mediterranean food place. I sat outside, and had a really good falafel plus some pickled vegetables. I've had plenty of kebab and the like, but I'd actually never tried falafel. Also, the pickled vegetables included carrots and celery, which is the first time that I've had either of them pickled. I've never met pickles I didn't like, so of course I enjoyed it.
Micho's - This is sort of a strange setup, because it's actually co-located with a bar called the Stage Bar, but
it came highly regarded. I had a fish taco and a carnitas taco, both were excellent, and quite cheap. I think that the whole meal including drink was less than $10. Additionally, they were using the bar's sound system to play XM 80s on 8, and it was having an exceptional day as far as music goes. I spent a lot of the time I was waiting for food singing along to the music.
Bandar - This was a Persian restaurant that came well-recommended from some colleagues. I had a beef and chicken kabob, and could barely finish it the portions were so huge. It was well spiced and tender, and I had a tasty yogurt sauce that was made with scallions (instead of the normal cucumber) plus flatbread on the side.
Lucy's Taco Shop - Breakfast was provided during the conference, so Thursday was the only day I needed to grab breakfast before my meeting. This place was right around the corner from the hotel where the meeting was being held, and so I grabbed a breakfast burrito from here. It came with a nice spicy salsa roja, and was quite tasty.
Karl Strauss Brewery Restaurant - Several of the social events that happened in the evening featured Karl Strauss Brewery products as their local feature, I tried their Amber Lager, as well as their Red Trolley Ale, and enjoyed both quite a lot - here is a microbrewery that doesn't over-hop everything for a change! When I saw on Yelp that the restaurant happened to be around the corner from where I was for my meeting, I knew that was the place for lunch. Beer, of course, featured heavily on the food menu, and I had a hamburger with beer-braised bacon and onions. On a whim, I tried their Oatmeal Stout, even though I am not normally a big fan of stouts, but this one was excellent. Very roasty and malty instead of hoppy, and it went really well with the burger. They also gave us a sample of their Anniversary brew, which tasted like it had a very high alcohol content and was aged in bourbon or whiskey barrels. Good stuff, but not something you'd want to drink a lot of in one sitting. A note to some of my friends who brew their own, I saw several of their kegs had a sticker with the slogan, "make beer, not war!" and if they sold them, I would have purchased several for you, but alas, the wait staff admitted that "we don't sell them because we suck." So there you go.
Dinner the first two nights was part of the conference's social event. The second night was a private event at the USS Midway, which was very cool. I would have liked to be able to see it during the day, but even at night it was really interesting.
Three nights there was proper dinner. First, one night a vendor took a few of us out to Nobu for sushi. I love sushi, but this was especially good. They had a lot of what they called "new-style" stuff that was not your standard sushi and sashimi. Lots of high quality fish, lots of good flavors. I don't even remember a lot of the things we tried, because someone else was doing most of the ordering, but I didn't have anything that wasn't tasty.
Stouts - I was on my own for dinner Wednesday night, as a lot of folks had already left town, and the conference ended mid-day, so I spent the afternoon working in my hotel room, and surfaced long enough to grab some dinner. This place looked good because it specialized in Irish Pub food. Turns out that it was the local hockey hangout, so while it's an Irish bar (and therefore serves what you'd expect at such a place) it also is the local Canadian expat hangout, and therefore had different hockey games on every screen, serves several Canadian beers, and poutine. I was trying to behave myself as far as dinner was concerned, so I skipped the poutine and ordered a reuben sandwich. That may have been a mistake. The corned beef (which is supposedly made onsite) was dry and flavorless, the saurkraut was timid, and while it was a decent rye bread, the bread was over-buttered and greasy, so it was a bit unrewarding. I don't know if their other food is better or not. They did have a good selection of beer, which helped, but I've been craving a good reuben ever since. Any recommendations?
Cafe Chloe - This was dinner on Thursday night. A friend from college had made some recommendations when I told him I would be in San Diego, and this was the one that he said was a must. Conveniently, it was nearby (most of the other places that he recommended were on North Side, which would have required a cab ride), and I'm very glad I took his recommendation. This is un-fussy French food. It was still almost 70 degrees out, so we had dinner outside on their patio. A cheese and olive plate, braised short ribs with brussels sprouts, and a good bottle of red. I got to try my colleague's mussels, which were cooked in a Belgian ale cream sauce. Not good for your health, but damn good for your mental health.
A few other things that I noticed about San Diego. First, it seemed odd to me that there weren't more motorcycles. This is a place where year-round riding is definitely possible, and since it's California, you can lane-split, meaning that navigating the traffic would be easier. Yet, I only saw one or two motorcycles each day. I see more on my commute when the weather cooperates here. Second, San Diego seems to have a pretty significant homeless population, a lot of whom seem to have mental health problems. I don't know if it was the area where I was in the city, or the temperate climate, or a combination of a bunch of things, but there were a lot of folks sleeping on the street, and I saw several buildings being rehabilitated as second-chance housing. The interesting thing is that it'd be in clusters - you'd walk for several blocks and not see anyone, then you'd walk two blocks and see 10 people.
The conference was located at the Westin in Gaslamp Quarter. There were no rooms left in the block by the time I booked, so I ended up staying at the Sheraton Suites at Symphony Hall. It's about .5 mile from the Westin. It was a servicable hotel, but as a recent Starwood convert (previous employer had corporate contracts with Hilton), I have noticed one thing - both of the Sheratons that I have used have been overpriced by comparison with their competitors, have been a bit dumpy (in need of a remodel), and have had internet service that was borderline useless that they still insist on charging you $9.95 a day for. I like Aloft and Westin, but I think I'm going to start avoiding Sheratons where I have an option.
Anyway, there are a lot of dining options in the Gaslamp Quarter area, so when we'd break for lunch, I pretty much just pulled up Yelp and looked for something interesting each day. Here's the short rundown of the places I tried:
Hodad's - this is a burger joint that was featured on Diners, Drive-ins, and Dives, and the episode featuring them was rerunning about a week or two before I left on this trip, so it was in the front of my mind. I didn't go to the original (the one actually featured on DDD), but the burger and fries were still good, and I had a tasty local copper ale to wash it down. I got their Blue Jay Burger, which is a Bacon Cheeseburger with Blue Cheese cooked into the patty, topped with grilled onions. Those flavors worked really well together.
Bite M.E - This is a cutely named Mediterranean food place. I sat outside, and had a really good falafel plus some pickled vegetables. I've had plenty of kebab and the like, but I'd actually never tried falafel. Also, the pickled vegetables included carrots and celery, which is the first time that I've had either of them pickled. I've never met pickles I didn't like, so of course I enjoyed it.
Micho's - This is sort of a strange setup, because it's actually co-located with a bar called the Stage Bar, but
it came highly regarded. I had a fish taco and a carnitas taco, both were excellent, and quite cheap. I think that the whole meal including drink was less than $10. Additionally, they were using the bar's sound system to play XM 80s on 8, and it was having an exceptional day as far as music goes. I spent a lot of the time I was waiting for food singing along to the music.
Bandar - This was a Persian restaurant that came well-recommended from some colleagues. I had a beef and chicken kabob, and could barely finish it the portions were so huge. It was well spiced and tender, and I had a tasty yogurt sauce that was made with scallions (instead of the normal cucumber) plus flatbread on the side.
Lucy's Taco Shop - Breakfast was provided during the conference, so Thursday was the only day I needed to grab breakfast before my meeting. This place was right around the corner from the hotel where the meeting was being held, and so I grabbed a breakfast burrito from here. It came with a nice spicy salsa roja, and was quite tasty.
Karl Strauss Brewery Restaurant - Several of the social events that happened in the evening featured Karl Strauss Brewery products as their local feature, I tried their Amber Lager, as well as their Red Trolley Ale, and enjoyed both quite a lot - here is a microbrewery that doesn't over-hop everything for a change! When I saw on Yelp that the restaurant happened to be around the corner from where I was for my meeting, I knew that was the place for lunch. Beer, of course, featured heavily on the food menu, and I had a hamburger with beer-braised bacon and onions. On a whim, I tried their Oatmeal Stout, even though I am not normally a big fan of stouts, but this one was excellent. Very roasty and malty instead of hoppy, and it went really well with the burger. They also gave us a sample of their Anniversary brew, which tasted like it had a very high alcohol content and was aged in bourbon or whiskey barrels. Good stuff, but not something you'd want to drink a lot of in one sitting. A note to some of my friends who brew their own, I saw several of their kegs had a sticker with the slogan, "make beer, not war!" and if they sold them, I would have purchased several for you, but alas, the wait staff admitted that "we don't sell them because we suck." So there you go.
Dinner the first two nights was part of the conference's social event. The second night was a private event at the USS Midway, which was very cool. I would have liked to be able to see it during the day, but even at night it was really interesting.
Three nights there was proper dinner. First, one night a vendor took a few of us out to Nobu for sushi. I love sushi, but this was especially good. They had a lot of what they called "new-style" stuff that was not your standard sushi and sashimi. Lots of high quality fish, lots of good flavors. I don't even remember a lot of the things we tried, because someone else was doing most of the ordering, but I didn't have anything that wasn't tasty.
Stouts - I was on my own for dinner Wednesday night, as a lot of folks had already left town, and the conference ended mid-day, so I spent the afternoon working in my hotel room, and surfaced long enough to grab some dinner. This place looked good because it specialized in Irish Pub food. Turns out that it was the local hockey hangout, so while it's an Irish bar (and therefore serves what you'd expect at such a place) it also is the local Canadian expat hangout, and therefore had different hockey games on every screen, serves several Canadian beers, and poutine. I was trying to behave myself as far as dinner was concerned, so I skipped the poutine and ordered a reuben sandwich. That may have been a mistake. The corned beef (which is supposedly made onsite) was dry and flavorless, the saurkraut was timid, and while it was a decent rye bread, the bread was over-buttered and greasy, so it was a bit unrewarding. I don't know if their other food is better or not. They did have a good selection of beer, which helped, but I've been craving a good reuben ever since. Any recommendations?
Cafe Chloe - This was dinner on Thursday night. A friend from college had made some recommendations when I told him I would be in San Diego, and this was the one that he said was a must. Conveniently, it was nearby (most of the other places that he recommended were on North Side, which would have required a cab ride), and I'm very glad I took his recommendation. This is un-fussy French food. It was still almost 70 degrees out, so we had dinner outside on their patio. A cheese and olive plate, braised short ribs with brussels sprouts, and a good bottle of red. I got to try my colleague's mussels, which were cooked in a Belgian ale cream sauce. Not good for your health, but damn good for your mental health.
A few other things that I noticed about San Diego. First, it seemed odd to me that there weren't more motorcycles. This is a place where year-round riding is definitely possible, and since it's California, you can lane-split, meaning that navigating the traffic would be easier. Yet, I only saw one or two motorcycles each day. I see more on my commute when the weather cooperates here. Second, San Diego seems to have a pretty significant homeless population, a lot of whom seem to have mental health problems. I don't know if it was the area where I was in the city, or the temperate climate, or a combination of a bunch of things, but there were a lot of folks sleeping on the street, and I saw several buildings being rehabilitated as second-chance housing. The interesting thing is that it'd be in clusters - you'd walk for several blocks and not see anyone, then you'd walk two blocks and see 10 people.
Monday, February 13, 2012
Musings on the Washington Auto Show Part 3
Last post talked about the cars on my shortlist and my impressions of them from the brief time I spent checking them out at the Auto Show. Today, it’s on to the cars that already didn’t make the cut – those which have been eliminated or drastically demoted on the shortlist, or were never on it to begin with and I just feel like ranting about them.
I sat in a new BMW 3 series, because I thought that perhaps a 335i or a Diesel might be a good mix of fun to drive and economical, but I don’t love the most recent exterior redesign, and the console interferes with my shin. Plus, it’d be nearly as expensive as the S4 which I like a lot better, so I guess that’s out.
A postscript on Volvo – the S60 R had a place on my list (near the bottom), but I discovered that unlike in the C30, their lovely floating center console is placed such that my knee/shin rubs against it in an uncomfortable way, so it’s officially off the list too. Sensing a theme here?
I’m so disappointed with Honda. They used to be the leaders when it came to using efficiency and technology to make cars that were fun to drive and still economical, but it’s as if someone pressed the Pause button on their drivetrain development for the last ten years. We went from the NSX and its ground-breaking VTEC engine to the S2000 and its motorcycle-like 9500 RPM redline, both among the first normally aspirated engines to break the 100 hp/L barrier, to the Acura TL and its great V6 + manual transmission combo to… nothing. Those engines are all still making about the same power output as they were 5+ years ago. In the meantime, the cars have gotten heavier, meaning that fuel economy has suffered, and all of their competitors have embraced direct injection, continuously variable valve timing, forced induction, etc, and are getting more HP out of their four cylinder engines than Honda is getting from six. It makes me sad that there’s nothing from Honda’s product line that I care about, especially since I used to own an Acura RSX Type-S. Even then, it felt underpowered, but it handled great, and had second-to-none driver ergonomics – easily the best manual transmission and steering wheel that I’ve ever used. The Acura TSX is interesting, especially the wagon, but the only way I can get one of Honda’s fantastic manual transmissions is to get it with their underwhelming four cylinder. The V6 is only available with an automatic. The least they could do is add the turbo four from the RDX, but that got pretty abysmal fuel economy for not too much better output. All of that aside, the console in the TSX interferes with my leg, which makes it a no-op anyway. I also really wanted to like the TL, which is interesting on account of the SH-AWD, but it’s an expensive car, the mileage isn’t great, and it’s underpowered compared with its competitors.
Toyota is trying really hard to pretend that they don’t just build driving appliances, but other than the Lexus LFA, they’ve got a long way to go when they bring out commercials like this “…the rush of 200 hp…”
I also was looking at a Nissan Maxima. I think with this version, Nissan finally got the styling right, as I think that it’s a very handsome car again, but the decision to have the CVT as the only available transmission makes it a deal-breaker. The VQ engine has gotten sort of thrashy on the top end of the rev range as they continue increasing the displacement, and having it ramp up to 4500 or 5500 RPM and stay there when I bury my foot does not sound like a recipe for aural enjoyment. To confirm that this wasn’t the right car for me, I found the seats uncomfortable – not enough padding on the cushions.
Scion didn’t bring their FR-S (the closest thing they make to an enthusiast car), but Subaru did bring their BRZ. They’re both mildly different versions of the co-designed FT-86. It was locked, so I couldn’t sit in it, but I’m not really seriously considering the car anyway, at least not yet. Currently it’s only available with a 200 hp NA flat four, so the performance is a bit below my threshold for “interesting.” Maybe if/when they bring it out with a Turbo I might be more interested, but for now, Toyota still remains an appliance maker in my book, at least ever since they discontinued the MR2, Celica, and Supra.
For whatever it's worth, it seems that I'm not the only one a bit disillusioned with HonTossan and their exceedingly boring cars.
I sat in both a Chrysler 300 SRT8 and a Jeep Grand Cherokee SRT8, and I looked at the Dodge Dart (on the turntable). I don’t understand the decision to resurrect the Dart nameplate. All I know of that car is that it has been made fun of for 20+ years by Click and Clack, and I don’t think I’ve ever heard anyone fondly remembering them. This one has nice styling, but the performance specs are such that it’s not really on my radar. I’ll have to say that the new interiors in the 300 and the new GC make a big difference, but they’re still not really on my consideration list. If I’m going to buy another car that gets gas mileage in the teens, I’m going whole-hog and buying a Cadillac CTS-V wagon.
In addition to looking at cars I might want to purchase, the auto show is also a great way to sit in and ogle cars that I’m unlikely to ever own, either because of their impracticality, their expense, or both. So when automakers choose not to participate or not to bring certain models, they deserve to be called out. For the second year in a row, Nissan didn’t bring a GT-R to the show. Last year, they said it was because they didn’t have any of the new ones after the redesign. This year, I didn’t even bother asking why. If I had the money burning a hole in my pocket, I would very seriously consider a GT-R before a Porsche, but I haven’t even been able to *sit* in one yet to see if I can fit (and equally important, if my kids even sort of fit in those tiny back seats). I guess I should have harassed the dealer in Manassas when we drove past and they had one sitting in the showroom last year. Since I mention Porsche, as much as of a Porschephile as I am, I have to take Porsche to task for being a complete no-show for the second year in a row at the auto show that is in their new corporate owner’s (VAG) US HQ’s backyard. I can just hear some stuffy Porsche exec saying “ze auto show in Vashington iss not vorth ze expense. Zose who are interested in our cars are velcome to come to our dealership to sit in ze vehicles.” C’mon guys, there’s no good reason for this. While some cosmetics may suffer, the show cars take less abuse than your press fleet, and you’re missing a huge opportunity to have a little kid (or a big kid) who isn’t likely to go anywhere near a Porsche dealership sit in one and say, “I’m going to own one of these someday.” Meanwhile, your competitors over at the Audi, BMW and Mercedes booths are happily letting the unwashed masses crawl all over their similarly-priced wares. I’m also sad that Mitsubishi has so utterly given up on the US car market that they also pulled a no-show for the second or third year. The Evo is on my list, but I’m starting to be hesitant to consider a carmaker that’s doing so poorly. It’d be just my luck that I’d buy one, and then they’d exit the US car market and leave me with no warranty to cover all of the magic technology that makes the car so amazing.
So if you actually stuck through all of this, congratulations. I’ll likely be posting driving impressions as I start to do test drives later in the year.
I sat in a new BMW 3 series, because I thought that perhaps a 335i or a Diesel might be a good mix of fun to drive and economical, but I don’t love the most recent exterior redesign, and the console interferes with my shin. Plus, it’d be nearly as expensive as the S4 which I like a lot better, so I guess that’s out.
A postscript on Volvo – the S60 R had a place on my list (near the bottom), but I discovered that unlike in the C30, their lovely floating center console is placed such that my knee/shin rubs against it in an uncomfortable way, so it’s officially off the list too. Sensing a theme here?
I’m so disappointed with Honda. They used to be the leaders when it came to using efficiency and technology to make cars that were fun to drive and still economical, but it’s as if someone pressed the Pause button on their drivetrain development for the last ten years. We went from the NSX and its ground-breaking VTEC engine to the S2000 and its motorcycle-like 9500 RPM redline, both among the first normally aspirated engines to break the 100 hp/L barrier, to the Acura TL and its great V6 + manual transmission combo to… nothing. Those engines are all still making about the same power output as they were 5+ years ago. In the meantime, the cars have gotten heavier, meaning that fuel economy has suffered, and all of their competitors have embraced direct injection, continuously variable valve timing, forced induction, etc, and are getting more HP out of their four cylinder engines than Honda is getting from six. It makes me sad that there’s nothing from Honda’s product line that I care about, especially since I used to own an Acura RSX Type-S. Even then, it felt underpowered, but it handled great, and had second-to-none driver ergonomics – easily the best manual transmission and steering wheel that I’ve ever used. The Acura TSX is interesting, especially the wagon, but the only way I can get one of Honda’s fantastic manual transmissions is to get it with their underwhelming four cylinder. The V6 is only available with an automatic. The least they could do is add the turbo four from the RDX, but that got pretty abysmal fuel economy for not too much better output. All of that aside, the console in the TSX interferes with my leg, which makes it a no-op anyway. I also really wanted to like the TL, which is interesting on account of the SH-AWD, but it’s an expensive car, the mileage isn’t great, and it’s underpowered compared with its competitors.
Toyota is trying really hard to pretend that they don’t just build driving appliances, but other than the Lexus LFA, they’ve got a long way to go when they bring out commercials like this “…the rush of 200 hp…”
I also was looking at a Nissan Maxima. I think with this version, Nissan finally got the styling right, as I think that it’s a very handsome car again, but the decision to have the CVT as the only available transmission makes it a deal-breaker. The VQ engine has gotten sort of thrashy on the top end of the rev range as they continue increasing the displacement, and having it ramp up to 4500 or 5500 RPM and stay there when I bury my foot does not sound like a recipe for aural enjoyment. To confirm that this wasn’t the right car for me, I found the seats uncomfortable – not enough padding on the cushions.
Scion didn’t bring their FR-S (the closest thing they make to an enthusiast car), but Subaru did bring their BRZ. They’re both mildly different versions of the co-designed FT-86. It was locked, so I couldn’t sit in it, but I’m not really seriously considering the car anyway, at least not yet. Currently it’s only available with a 200 hp NA flat four, so the performance is a bit below my threshold for “interesting.” Maybe if/when they bring it out with a Turbo I might be more interested, but for now, Toyota still remains an appliance maker in my book, at least ever since they discontinued the MR2, Celica, and Supra.
For whatever it's worth, it seems that I'm not the only one a bit disillusioned with HonTossan and their exceedingly boring cars.
I sat in both a Chrysler 300 SRT8 and a Jeep Grand Cherokee SRT8, and I looked at the Dodge Dart (on the turntable). I don’t understand the decision to resurrect the Dart nameplate. All I know of that car is that it has been made fun of for 20+ years by Click and Clack, and I don’t think I’ve ever heard anyone fondly remembering them. This one has nice styling, but the performance specs are such that it’s not really on my radar. I’ll have to say that the new interiors in the 300 and the new GC make a big difference, but they’re still not really on my consideration list. If I’m going to buy another car that gets gas mileage in the teens, I’m going whole-hog and buying a Cadillac CTS-V wagon.
In addition to looking at cars I might want to purchase, the auto show is also a great way to sit in and ogle cars that I’m unlikely to ever own, either because of their impracticality, their expense, or both. So when automakers choose not to participate or not to bring certain models, they deserve to be called out. For the second year in a row, Nissan didn’t bring a GT-R to the show. Last year, they said it was because they didn’t have any of the new ones after the redesign. This year, I didn’t even bother asking why. If I had the money burning a hole in my pocket, I would very seriously consider a GT-R before a Porsche, but I haven’t even been able to *sit* in one yet to see if I can fit (and equally important, if my kids even sort of fit in those tiny back seats). I guess I should have harassed the dealer in Manassas when we drove past and they had one sitting in the showroom last year. Since I mention Porsche, as much as of a Porschephile as I am, I have to take Porsche to task for being a complete no-show for the second year in a row at the auto show that is in their new corporate owner’s (VAG) US HQ’s backyard. I can just hear some stuffy Porsche exec saying “ze auto show in Vashington iss not vorth ze expense. Zose who are interested in our cars are velcome to come to our dealership to sit in ze vehicles.” C’mon guys, there’s no good reason for this. While some cosmetics may suffer, the show cars take less abuse than your press fleet, and you’re missing a huge opportunity to have a little kid (or a big kid) who isn’t likely to go anywhere near a Porsche dealership sit in one and say, “I’m going to own one of these someday.” Meanwhile, your competitors over at the Audi, BMW and Mercedes booths are happily letting the unwashed masses crawl all over their similarly-priced wares. I’m also sad that Mitsubishi has so utterly given up on the US car market that they also pulled a no-show for the second or third year. The Evo is on my list, but I’m starting to be hesitant to consider a carmaker that’s doing so poorly. It’d be just my luck that I’d buy one, and then they’d exit the US car market and leave me with no warranty to cover all of the magic technology that makes the car so amazing.
So if you actually stuck through all of this, congratulations. I’ll likely be posting driving impressions as I start to do test drives later in the year.
Subscribe to:
Posts (Atom)