Ipv6 Deployment: the Internet Society As Part of Its Fellowship to the IETF Programme

Volume 4, Issue 2 IETF Journal October 2008 A report from IETF 72, July 2008, Dublin, Ireland. Published by the Internet Society in cooperation with Inside this issue the Internet Engineering Task Force*

Focus on IPv6 at IETF 72...... 1 Focus on IPv6 at IETF 72 IETF Meetings Related to Peer-to- From the Editor’s Desk, by Mirjam Kühne Peer and Bandwidth Management...... 1 Set against the beautiful backdrop of a golf resort near Dublin, IETF 72 offered an opportunity to revisit many of the same themes discussed at prior meetings. Message from the IETF Chair...... 2 IPv6 was, once again, a hot topic, most notably during the Wednesday plenary, for which the Internet New BoF Meetings..... 2 Architecture Board organized a panel to discuss IPv6. Words from Panelists consisted of a number of IPv6 operators and the IAB Chair...... 3 experts, each of whom described their experiences de- IETF 72 ploying IPv6 within their networks and organizations. Facts and Figures...... 3 The panel discussion, moderated by Gregory Lebovitz,

Plenary Report ...... 5 is described in detail on page 17.

Real-Time Text...... 9 In this issue, Shane Kerr takes a look at the IETF response to the DNS vulnerability that was discovered Citywest Hotel Convention Centre Talking with Jorge L. by Dan Kaminsky and that is often referred to as the near Dublin, site of IETF 72. Contreras...... 11 Kaminsky Attack (see page 31). While the discussions The Internet and within the IETF took place primarily within working groups, Shane offers a good look at the history Bandwidth-Intensive of DNS security and a brief review of recent DNS security work as well as a compilation of IETF Activities ...... 13 responses.

IETF 72 Welcomes Stepping outside the usual technical discussions, the IETF Journal sat down with IETF lawyer ISOC Fellows...... 14 Jorge Contreras, who discussed his work with the IETF and, in particular, the latest developments in the field of intellectual property rights. The interview with Jorge appears on page 11. Joining the IETF Fold...... 16 Once again, the IETF meeting played host to a number of engineers from various parts of the developing world. Their participation at IETF 72 was made possible through generous support by IPv6 Deployment: the Internet Society as part of its Fellowship to the IETF programme. This was also the first time Lessons from the that some of the earlier fellows returned to attend their second IETF meeting. See more about the Trenches...... 17 fellows and their experiences on page 14. IPv6 Transition at Thank you to the contributors to this issue. We wish everyone fun reading. And as always, we IETF72...... 25 welcome both your comments and your contributions for future issues. IETF Response to the Kaminsky IETF Meetings Related to Peer-to-Peer DNS Vulnerability....31

IRTF Report...... 33 and Bandwidth Management

Recent IESG By Leslie Daigle Document and Protocol Actions...... 35 As bandwidth management has become an important topic, the IETF has held a handful of meetings to discuss the issues it involves and possible IETF work items that might address them. One of Calendar...... 36 those meetings was a one-day workshop organized by the Real-time Applications and Infrastructure (RAI) area and held at Massachusetts Institute of Technology at the end of May 2008. Following that were two BoF (birds-of-a-feather) sessions, held at IETF 72 in Dublin. Continued on page 4

* The articles published in the IETF Journal are not intended to reflect the opinions or the position of the IETF or the Internet Society. IETF Journal IETF 72 • October 2008 • Volume 4, Issue 2

Message from the IETF Chair By Russ Housley

Held at City West in Dublin, in July 2008, IETF 72 was by all measures a highly successful meeting. With 1,183 people from 48 different countries in attendance, the week was filled with the usual mix of working group (WG) meetings, BoF (birds-of-a-feather) sessions, research group (RG) meetings, and, as always, many side meetings. Our host, Alcatel-Lucent, certainly made everyone Russ Housley, IETF Chair feel welcome, and we had a wonderful time at the Guinness Storehouse on Tues- day evening. The network connecting City West to the rest of the Internet was provided by eircom, and the local network was provided by Alcatel-Lucent, with considerable support from volunteers. Since IETF 71, 5 new WGs were chartered and 11 WGs were closed, leading to approximately 115 chartered WGs in total. Between the meetings, the WGs and their individual contributors produced 475 new Internet-Drafts and generated 1,071 updated Internet-Drafts. The Internet Engineering Steering Group New BoF Meetings approved 134 Internet-Drafts for publication as RFCs and the RFC Editor published 88 new RFCs. Descriptions and agendas for all BoF meetings can be found at One of the hot topics during IETF 72 was the coexistence of IPv4 and IPv6. http://www.ietf.org/meetings/past. The discussions about requirements for NAT-PT (network address translation– meetings.html. protocol translation) in the Internet Area were especially lively. To aid in the discussion, an IPv6-only network was available throughout the week so people Applications Area could see what the Internet would be like without IPv4. While the topic was not morg: Message Organization resolved, an interim meeting is being organized for early October in Montreal to Internet Area continue the discussions. The meeting will cover topics that affect work ongoing explisp: Experimentation in LISP in a number of WGs, including SOFTWIRE, V6OPS, and BEHAVE. Routing Area At IETF 73, we expect to conduct a scheduling experiment that we hope will alto: Application-Layer Traffic lead to the creation of additional meeting time for WGs. Instead of ending at Optimization 11:30 on Friday, we will end at 15:15. The after-lunch meeting slots will mean more than 16 additional hours of session time for WGs. Following the meeting, Transport Area the IETF will evaluate the results of the experiment and determine whether a ippm: IP Performance Metrics, longer meeting is something we want to continue in the future. Next Steps tana: Techniques for Advanced I look forward to IETF 73 in Minneapolis, which is scheduled for 16–21 Networking Applications November 2008, and will be hosted by Google, and to IETF 74 in San Fran- cisco on 22–27 March 2009, which will be hosted by Juniper Networks. Sched- uling information for future IETF meetings may always be found at http:// www.ietf.org/meetings/meetings.html. I look forward to seeing you at the meetings.

2 IETF Journal IETF 72 • October 2008 • Volume 4, Issue 2

Words from the IAB Chair By Olaf Kolkman

“To the universal deployment of IPv6” is the toast to which some of our colleagues have raised their glasses for nearly 10 years. That toast can be heard during unofficial events and gatherings at IETF meetings that have taken place since IETF 43, when, after an IPng working group session, some folks retreated to empty a few bottles of Scotch. The relevance of this factoid is linked to the Olaf Kolkman, IAB Chair technical plenary at IETF 72, during which the Internet Architecture Board (IAB) expressed interest in IPv6 deployment issues. In the context of the emerging completion of the IANA IPv4 registry, the IAB asked itself a number of questions such as, What are the actual deployment barriers in various environments ranging from Internet service providers (ISPs) IETF 72 to application service providers, to business enterprises, to end users? What are Facts and Figures the approaches toward IPv4 completion contingency planning? What are the success factors inherent in the actual deployment of IPv6? and, What can the Registered attendees...... 1,183 IAB do to hasten IPv6’s deployment? Countries...... 48 With those questions in mind, the IAB organized a plenary discussion to New WGs...... 5 which we invited a number of folks who have key roles in the deployment of Closed WGs...... 11 IPv6 in their organizations. Our intention was not only to try to address the WGs Chartered...... 115 questions asked here but also to inspire participants to go back home and assess New Internet-Drafts...... 475 how they could play their part in an IPv6 rollout. A report by the moderator, Gregory Lebovitz, appears on page 17. Updated Internet-Drafts...... 1,071 On a personal note, it was difficult to find engineers who could shine a light IETF Last Calls...... 105 on the deployment issues within business enterprises. I wonder how much that Approvals...... 134 has to do with the fact that IPv6 has not yet made it onto those corporations’ (March–June 2008) agendas. To a certain extent, I understand how deployment of a new IP address 97 RFCs published of which family might not make it onto the agenda. It shouldn’t have to; IP infrastructure • 44 standards tracks should just work. However, I find it hard to believe that at the chief technology officer (CTO) level, no conscious decision has been made about how to move • 4 BCP forward with IPv4. It seems clear to me that as soon as IANA’s IPv4 registry is 107 Internet–Drafts submitted completed, the landscape of IPv4 allocation and assignment is going to change. for publication If I were a CTO, it would make sense to me to have already made an analysis • 79 submitted by the IETF of how to move forward within that landscape. Could it be that CTOs are not IANA Actions tuned in to the issue? An entirely different and somewhat plausible explanation (March–June 2008) for the difficulty in finding engineers with experience in enterprise-scale IPv6 Processed 1,422 IETF-related deployment is that those engineers are not participating in the IETF. The root requests of which: cause for both of those explanations may be that IP addressing is a typical ISP • 775 Private Enterprise issue and that engineers at ISPs may be more attuned to IPv4 address comple- Numbers tion than are their counterparts in the business enterprises sector. • 66 Port Numbers These personal musings aside, the IAB is interested in hearing more adoption • 67 TRIP ITAD Numbers stories, specifically those in which barriers were encountered and overcome. We also want to hear about barriers that persist—especially those cases in which • 11 media-type requests some IETF-related work might help, whether it’s a protocol, a best-current- practices document, informational material, or experimental work. In a future plenary we plan to report on both the lessons and the outstanding issues that we learned from those stories. Please send your stories to [email protected]. If your story speaks best to universal adoption of IPv6, then the tradition described in the first paragraph will be honoured and you will be provided with either a bottle of single-malt Scotch or a nonalcoholic beverage of your choice.

3 IETF Journal IETF 72 • October 2008 • Volume 4, Issue 2

Peer-to-Peer, continued from page 1 of the complexities they face in order to BoF in Dublin at IETF 72. Chaired by deliver the reliable and quick file sharing Enrico Marocco and Vijay K. Gurbani, RAI Peer-to-Peer Infrastructure for which BitTorrent is known, they said the discussion focused on (1) possible Workshop there is a point where P2P and network approaches to exposing certain aspects The one-day workshop began with a dis- operations sometimes run at odds with of network topology to applications and cussion that was designed to frame the each other. When attempting to locate (2) how P2P technologies might be en- issue and that included both the Inter- sources of file chunks, P2P networks hanced to take advantage of that infor- net service provider (ISP) and peer-to- look for the least common chunks, and mation. peer (P2P) service operator viewpoints, they figure out where to get them. These According to draft-marocco-alto as well as input with regard to additional are the less available chunks of what -problem-statement-02.txt, “Many of scoping. you’re downloading. However, from the existing overlay networks are built a network perspective, the location of Jason Livingood and Rich Woundy on top of connections between peers these chunks may not be the most de- provided some technical perspective that are established regardless of the sirable. Stanislav and Eric observed that from their vantage point at Comcast, underlying network topology. In ad- efficient choosing of peers could reduce the cable service provider. Participants dition to simply achieving suboptimal transit traffic by more than 50 percent. learned that Internet service providers performance, such networks can lead to are observing enough P2P application The afternoon presentations show- congestions and cause serious inefficien- traffic in their networks to impact cus- cased proposals for moving forward. cies. . . . [T]raffic generated by popular tomers’ delay-sensitive applications and Some of the proposals focused on P2P P2P applications often crosses network services, such as VoIP. The unacceptable technologies and oracles, such as P4P: boundaries multiple times, overloading customer experience occurs when one Provider Portal for (P2P) Applications, links which are frequently subject to or more of a subscriber’s delay-sensitive by Haiyong Xie and Laird Popkin; Traf- congestion.” applications are noticeably degraded in fic Localization, by Yu-Shun Wang; Both the presentations and the dis- performance because other subscrib- and ISP-Aided Neighbour Selection in cussion at the meeting focused on issues ers’ P2P applications are consuming P2P Systems, by Vinay Aggarwal. Oth- surrounding caching and peer selection all available bandwidth—that is, in ers focused on network and bandwidth (P2P application questions), as well as excess of network planners’ expecta- management approaches, such as Bob on bandwidth costs. A draft charter for tions. While the ideal solution might Briscoe’s Solving This Traffic Manage- a working group was proposed and dis- be to ramp up the bandwidth for each ment Problem . . . and the Next, and cussed. However, while there was sup- customer, there are both technical and the Next, which can be found at http:// port for moving forward with this topic business reasons that such a solution is www.cs.ucl.ac.uk/staff/B.Briscoe/pubs. area, the sense of the room was that the not generally feasible. For one, some html#p2pi-solutions>. draft charter did not adequately capture P2P systems literally know no bounds, The end of the day brought no imme- a clear problem statement that partici- thereby making aggressive use of all diate conclu- available bandwidth. sions for IETF Comic BoF Jason and Rich’s goals for a better fu- action items, ture include the following: but it did increase aware- • Optimize to provide the best possi- ness and set ble network experience for the broad- the stage for est set of customers, which means minimizing or eliminating cross-cus- BoF sessions tomer service quality impacts. to be held two months later at • Enable continued Internet evolu- IETF 72. tion in a manner that avoids a game of cat and mouse—that is, detection and ALTO BoF mitigation of specific protocols. The RAI area On the other side of the issue were held the Ap- Stanislav Shalunov and Eric Klinker of plication-Layer BitTorrent, who offered the P2P per- Traffic Optimi- spective. After walking through some zation (ALTO)

4 IETF Journal IETF 72 • October 2008 • Volume 4, Issue 2

Plenary Report By Mirjam Kühne

Note: This is not a complete report of the plenary sessions; rather, it is a summary of the highlights of the discussions. All IETF 72 presentations can be found at http://www.ietf.org/meetings/past.meetings.html. ven though Irish is the native language of Ireland, English has become the dominant language, just like IP is the dominant language of networking,” Mirjam Kühne said“E Kevin O’Callaghan, Ireland’s leader of Alcatel Ireland, which served as host organization for IETF 72. Kevin welcomed participants to Dublin and said he was honoured to address the meeting. “It is fundamental to allow Nets around the world ply new technologies with a view toward to communicate,” he said. “The impacts on society have been truly beneficial.” reduction of energy use. He said he’s On behalf of Alcatel-Lucent, which playing catch-up in the areas of domes- very encouraged by this type of meeting, played a significant role in shaping the tic and public use of the Internet. How- because the IETF has a model that uses telecom infrastructure in Ireland, Kevin ever, a new era of investment has been democratic processes at its very core. expressed his delight in having the op- ushered in, and Ireland is becoming Peter O’Connell, director of strategy portunity to host and sponsor the IETF recognized as a place where companies and regulation at eircom, the company in Dublin. He was impressed by the can more easily invest in connectivity. that provided connectivity at the IETF number of people attending, the variety Mobile broadband pickup has acceler- in Dublin, said it was impressive to see of organizations represented, and the ated at a comparatively high rate, and an so many people of so many backgrounds number of languages being spoken. open-access system has allowed flexible agreeing on standards. Ireland’s Green Party’s minister of development of new applications. This Compared with similar companies energy Eamon Ryan, who oversees has clearly given the country an advan- worldwide, eircom may be small, but it communications, energy, and natural tage in the area of digital services. is big by Irish standards. The company resources, addressed the group, saying In his address, Minister Ryan echoed used to focus on voice, but now it fo- that for politicians, the objective is to the sentiment of Vint Cerf, who sug- cuses on broadband. Peter described the provide access and ubiquitous connec- gested at a recent conference of the Or- government as supportive of investment. tivity that society can use for critical is- ganisation for Economic Co-operation “A policy platform that encourages in- sues, such as health care, education, and and Development (OECD) that the vestment is essential to the development enterprise. There have been difficulties development of the open-access system of the Internet and to making both the in achieving that goal in Ireland, and might necessitate a newer regulatory Internet and the content that is available the move to ubiquitous connectivity system than the one that grew up under on the Internet accessible and affordable has been slower than desired. In fact, in the old phone systems. Minister Ryan to the users,” he said. the past few years, the country has been said Ireland has challenged itself to ap- Continued on next page

Peer-to-Peer, continued According to http://www.ietf.org/ troduce into the network and a protocol pants could support as IETF work. It internet-drafts/draft-shalunov-tana using it and was sent to the mailing list for refine- -problem-statement-01.txt: 2. a document describing the cur- ment. “The TANA BoF is held to explore rent practice of peer-to-peer apps’ use TANA BoF the problem space, to gauge the inter- of multiple transport connections and est in the problems within the Transport recommendations in this space.” The Transport Area held the Techniques area, and to see if the community and Discussion between those in the for Advanced Networking Applications the area directors believe that it makes group included Jason’s review of ISP (TANA) BoF, chaired by Stanislav sense to form a TANA working group requirements and Laird’s review of P2P Shalunov and Gorry Fairhurst. The ses- within the Transport area chartered to application requirements. A number of sion focused on some of the transport- work on issues and angles were also discussed, layer possibilities for supporting band- 1. standardizing end-to-end conges- and at the end of the meeting there was width-intensive applications. tion control that enables advanced ap- clear support for moving forward with plication to minimize the delay they in- work on the first item.

5 IETF Journal IETF 72 • October 2008 • Volume 4, Issue 2

Plenary, continued from page 5 holm, hosted by Netnod and Arceo. The can be found at http://www.isoc.org/ retreat was designed as a workshop at pubpolpillar/docs/oecd-technical IAB Update which everyone brought up topics they -community-memorandum.pdf. wanted to discuss and after which a Following Internet Research Task Force The IAB also participated in a techni- work plan was developed. A discussion (IRTF) chair Aaron Falk’s update cov- cal forum on the future of the Internet on evolution of the IP model, including ering recent developments in the IRTF Economy, which was organized prior to assumptions regarding which IP models (details on page 33), Internet Architec- the OECD Ministerial meeting. are valid and which are not, was led by ture Board (IAB) chair Olaf Kolkman Dave Thaler. A discussion on peer-to- Olaf reminded the audience that gave an update of IAB activities as fol- peer architecture was led by Gonzalo the IAB is responsible for maintaining lows: Camarillo. Gregory Lebovitz is leading and defining the RFC Editor model, What Makes for a Successful Protocol an ongoing discussion on IPv6 deploy- whereas the IAOC is responsible for the has been published as RFC 5218 (see a ment. implementation of the agreement be- related article in the IETF Journal, Vol- tween the IETF and the RFC Editor. In addition, there have been a number ume 3, Issue 3, December 2007). Design The RFC Editor contract will be up for of organizational activities. Bert Wijnen Choices While Expanding the DNS is bids in 2009. To guarantee continuity, a stepped down as IEEE 802.1 liaison technically approved, but it needs one comprehensive model is needed. To that and has been replaced by Eric Gray. more round of editorial review before end, the RFC Editor function will be John Klensin has been appointed liaison sending it to the RFC Editor. split into four functions: within ISO/TC46. Lars Eggert is suc- Independent Stream Approver ceeding Mark Twonsley as IESG liaison • to the IAB. The IAB thanks Bert for his • RFC Editor many years of good service. IAB liaison • Production House shepherds are successfully helping track • Publisher and communicate the activities of the IAB liaisons. The RFC Editor and Independent Stream Approver roles are new compo- Olaf showed a diagram of the struc- nents. They may all be part of one ven- ture of the joint working team on dor, or they could be separate. The ques- multiprotocol-label-switching (MPLS)

thberg tion is, How do we select the functions ö extensions from the plenary session or vendors? One possibility is through a at IETF 71. He then reported on the request for proposals; another is through joint working team of the ITU-T and a NomCom process. The IAB welcomes the IETF, which is discussing issues re- Photo by Peter L suggestions. Alcatel–Lucent managing director lated to MPLS. The team has issued a Kevin O’Callaghan. statement saying a transport profile for The discussion took place on the MPLS (MPLS-TP) will be developed RFC interest list, and a conclusion was planned for end of August. More details A number of documents are now that will take into account the ITU-T can be found on the IAB Web site. works in progress, including Principles transport network requirements. The of Internet Host Configuration, for ITU-T will integrate MPLS-TP into Finally, Olaf which a call for comments will be issued the transport network and will align pointed out that shortly. The document titled Headers the current transport MPLS (T-MPLS) the IAB has a and Boilerplates is related to the work ITU recommendation with MPLS-TP. new logo, which on RFC 3932bis (Procedures for IESG Further work on T-MPLS will be ter- was designed by and RFC Editor documents) and the minated. IAB executive IRTF stream definition. It is expected Another new organizational de- director Dow Street. that these documents will reduce the velopment is the IETF’s involvement Typically, at IETF meetings an necessity for IESG statements by pro- with the OECD in cooperation with open-microphone session is part of each viding clearer guidelines for document the Internet Society (ISOC). Together plenary. At IETF 72, the open-mic ses- authors. with ISOC and 15 other technical or- sion was replaced by a technical panel There was quite a bit of activity in the ganizations, the IAB cosigned a memo- titled IPv6 Experiences from the Field, area of Internet architecture. This past randum on the future of the Internet in in which five panellists described their April, the IAB held a retreat in Stock- a global economy. The memorandum experiences with IPv6 deployment in

6 IETF Journal IETF 72 • October 2008 • Volume 4, Issue 2

their particular environment. (See arti- Another new organizational development is the IETF’s involve- cle page 17.) ment with the OECD in cooperation with the Internet Society Administrative Updates (ISOC). Together with ISOC and 15 other technical organiza- IETF Trust administrative procedures tions, the IAB cosigned a memorandum on the future of the have been revised, reviewed by the com- Internet in a global economy. munity, and adopted. The RFC series has been assigned an ISSN (Interna- contingency budget of USD 50,000 re- training on timely or controversial is- tional Standard Serial Number), which mains intact. sues or should the training focus on the will make it easier for libraries and other technical knowledge needed to produce archives to identify them. Jonne also announced that during the remainder of 2008 and in 2009, a high-quality IETF specifications? The Intellectual Property Rights number of RFPs would be announced, The Edu team is seeking feedback (IPR) working group (WG) has been including those for the meeting network on those questions and would welcome working on legal provisions for IETF contract, the RFC editor, and the IETF e-mail sent to [email protected]. documents. Even though a licence for secretariat. code was previously developed by vol- IESG Open Mic unteers—the Nonprofit Open Source Edu Team Report During the open-mic session on Thurs- Licence 3.0 (OSL)—several issues have The Edu team is responsible for organiz- day, a lengthy discussion focused on been raised by employees at for-profit ing the tutorial sessions on the Sunday both the process and the usefulness of enterprises. In the end, the trustees de- prior to each IETF meeting. Its mission so-called PROTO write-ups—a par- cided to replace OSL with the Berkeley is to manage the internal education ac- ticular way of providing feedback for Software Licence for volunteer code. tivities of the IETF and to offer train- Internet-Drafts submitted to the IESG. (Additional details on this subject can ing and other educational material that The IESG said the PROTO write-ups be found on page 11.) “improves the effectiveness of the IETF provide feedback that is helpful to IESG Jonne Soininen, chair of the IETF operations.” While the Newcomers Tu- members, especially in areas where an Administrative Oversight Committee, torial might be the best-known, there IESG member is not expert in the sub- and Ray Pelletier, IETF administrative are three different types of tutorials: ject area. A discussion followed about director, gave an update on the financial • Process-oriented topics: bringing the practice of having the IESG make status of the IETF and announced hosts new work into the IETF and docu- decisions during telephone chats and via of future IETF meetings. IETF 74 will ment life cycle other means—a practice that may not be hosted by Juniper and take place in be as transparent to the community as • Training on tools: XML2RFC and San Francisco. IETF 75 will be hosted it could be. IETF tools by Swedish country code top-level do- According to Russ Housley, the main .se and take place in Stockholm. • Technical topics such as security, IESG’s use of Data Tracker has made IETF 76 will be hosted by the WIDE DNS, routing, and IPv6 Continued on next page project and take place in Hiroshima, The Edu team also organizes topical Japan. trainings for WG chairs during each The high-level financial overview for IETF meeting. 2008 looks fairly positive. A total of Recently, the Edu team Web site was USD 650,000 in meeting sponsors has transitioned to a new wiki site, which been secured by the Internet Society. makes it more stable and easier to up- Those three meetings will contribute date. USD 1.1 million to be invested in other One open issue that comes up from secretariat activities, IETF Adminis- time to time among Edu team members trative Support Activity (IASA) activi- is the role of the technical tutorials and ties, and RFC editor activities. ISOC

what the tutorials should cover: Should thberg will contribute USD 1.55 million to ö they be introductory-level cross-train- IASA’s 2008 budget from its organiza- ings for IETF participants or should tional member contributions and other they cover in-depth training on spe-

sources. Expenses are projected to be Photo by Peter L cific technologies? Should there also be slightly under budget for 2008, and the IETF 72 participants meet in hotel lobby.

7 IETF Journal IETF 72 • October 2008 • Volume 4, Issue 2

Plenary, continued from page 7 commented on the subject were opposed mainstream TCP implementations over to that suggestion and made some other a longer time frame, like five years.” This the entire process much more transpar- suggestions instead. For instance, one would recognize the tension that exists ent. “Now, anyone can see the status participant suggested the meetings start between the IETF, which makes long- of the review and see what comments earlier in the mornings or that there be term standards, and the companies that need to be resolved for the document to more calls between meetings. In gen- want to ship products. progress,” he said. eral, it was felt that more work needs to On the other hand, Dave Oran sug- be done outside the three meetings that While most participants agreed that gested that the community proceed are held each year. the tracker is a valuable tool, some sug- with caution with regard to congestion gested it could be enhanced so that it The discussion continued on mail- control algorithms. “There is a balance can be used more consistently. Russ con- ing lists following IETF 72, and in the to be struck,” he said. “Involvement of firmed that review of the tool is already meantime, the IESG has decided to the sponsoring ADs and the relevant on the to-do list for the IESG. proceed with the suggestion at IETF 73 ICCRG [Internet Congestion Control in Minneapolis and to Research Group] is important. Let’s provide meeting slots move with much speed and low haste.” until 15:15 on that Then should one use UDP for peer- Friday. to-peer communication between peers IAB Open Mic that are stuck behind NAT gateways, and TCP for everything else? During the IAB open mic session, a partici- No, said Stuart, who answered that pant asked what the one can have NAT-to-NAT peer- thberg ö IAB thinks about add- to-peer communication equally well ing new congestion- with either TCP or UDP. “The reason control algorithms to TANA wants a new congestion control

Photo by Peter L TCP: Do we view an algorithm is that they want something Internet pioneer Vint Cerf chats with IETF 72 attendees. aggregated UDP/IP less aggressive than today’s TCP,” he header as just the lay- said. “It has nothing to do with NAT IESG member Magnus Westerlund er 3 datagram layer over which we run gateways.” pointed out the need for more bottom- this TCP implementation, as opposed Scott Bradner remembered that when up review. “Cross-area reviews need to to sticking with TCP? Or are we using he was a transport AD, many people be happening,” he said. “Many of the is- another congestion-controlled transport wanted to use UDP, that usually, it was sues that come up in a DISCUSS should like SCTP or DCCP? This issue came a way to say that TCP was too heavy and be addressed early on in the review up in the Techniques for Advanced too slow. He cautioned that one should process.” A DISCUSS is a certain way Networking Applications (TANA) BoF “be very concerned about the underlying for the IESG to provide feedback for an that met during IETF 72. excuse.” author of an Internet-Draft. A variety of views were expressed IAB member and liaison to the IETF by the IAB in response. On one Loa Andersson said the problems that h a n d , S t u a r t were being discussed stem from a rela- Cheshire said he tively small number of DISCUSSes. He thought it would be said he felt that, overall, the work is be- a good approach to ing done well. “I have been a WG chair “experiment with for some time, and I have experienced this at the user a number of area directors,” he said. level running over “Usually, the DISCUSS comments have UDP. Then, when thberg

helped improve the document.” the algorithm is ö At the end of the IESG open mic ses- worked out, it can sion, the suggestion was made that the be standa rdized and then gradu-

IETF consider extending the meetings Photo by Peter L to Friday afternoon. Most of those who ally made into the Shuttle takes IETF participants to Dublin.

8 IETF Journal IETF 72 • October 2008 • Volume 4, Issue 2

Real-Time Text By Arnoud van Wijk

hen we want to communicate electronically, most of us use voice and, at an increasing rate, video. When we do, such communications occur in real Wtime1; that means that we send and receive audio and video continuously as we communicate, and we consider this as the normal way to converse with each other. For most of us, text is a static medi- typed and are then displayed immedi- To the deaf or hard of hearing, real-time um. We use it to read newspapers and ately to the receiving person(s). This al- text feels more like conversation. Web sites; we exchange text messages by lows text to be used in the same conver- using mobile phones; and we use instant sational manner as voice. It’s like talking 3261) and the session description pro- messaging on our computers to commu- by using text. tocol (SDP) (RFC 4566). SIP is used nicate with each other while doing other Real-time text that runs over IP without any alteration; there is no dif- tasks. When we need efficient conversa- networks is designed around the ITU ference between real-time text and VoIP tion, we pick up the phone and call the T.140 real-time text presentation layer for SIP. The real-time text encoding is person. protocol. T.140 allows real-time edit- identified by using the SDP media defi- But what do we do if we’re unable to ing of text, even in cases of backspacing nition m=text. use a telephone because we can’t hear or and retyping. T.140 is based on the ISO To ensure proper technical implemen- speak or because we’re in an environment 10646-1 character set, which is used by tation and use of real-time text, RFC or a situation where the use of voice is most IP text specifications, and it uses 51943 lists the essential requirements for inappropriate, such as in a restaurant or the UTF-8 format. This allows any lan- real-time text and defines a framework during a meeting? What if we find our- guage to be used with real-time text, infor implementation of all required func- selves in danger and need to contact the cluding English, Chinese, and Russian. tions based on SIP and RTP. This in- police without being heard? Real-time text uses the same real- cludes interworking between real-time The solution is real-time text. For the time transport protocol (RTP) as voice text and existing text telephony on the majority, this will be a valuable addi- over IP (VoIP) and video over IP. The public switched telephone network and tional communication medium besides text is encoded according to IETF RFC other networks. audio and video. Real-time text can be 4103 (RTP Payload for Text Conversa- The ECRIT IETF working group used either as the only communication tion), which supports an optional error- defines real-time text as one medium mode or together with audio and video, correction scheme based on redundant in the access to emergency services (see which is called total conversation.2 transmission (as described in RFC RFC 5012, draft-ietf-ecrit-phonebcp For those who are deaf or hard of 2198). This results in a very low end-to- and draft-ietf-ecrit-framework). With hearing or who have a speech impair- end character loss across IP networks the growing number of people with ment, real-time text is an essential com- that have moderately high packet loss. hearing and/or speech impairments, it munication capability. This is especially (It also makes it very good for wireless would be prudent for multimedia emer- true in the current era. Every day, we all accesses.) gency public-safety answering points in depend more and more on the telephone To improve efficiency, the text is buff- Europe (which uses 112) as well as in for immediate contact. Social contacts ered for 300–500 milliseconds before it the United States and Canada (which are maintained, business is conducted, is sent while still meeting the real-time use 911) to support real-time text. and even our safety depends on the tel- text performance requirements of RFC Mainstream Use of Real-Time ephone. With real-time text as a main- 4103. The traffic load of real-time text Text stream communication feature, Internet at 30 characters per second is between 2 The use of real-time text will not be telephony is for everyone. and 3 kilobits per second depending on limited to those who cannot use speech. the language used (including the over- The Technology Behind Real- Like captioning on TV, real-time text heads for RFC 4103 with the maximum Time Text will be used more by people without level of redundancy, RTP, UDP and disabilities than by those who have Real-time text works by sending and re- IP). ceiving text on a character-by-character them. On phone calls, people can type Real-time text uses the standard ses- basis. The characters are sent immedi- in phone numbers, addresses, names, sion initiation protocol (SIP) (RFC ately (within a fraction of a second) once Continued on next page

9 IETF Journal IETF 72 • October 2008 • Volume 4, Issue 2

Real-Time Text, continued from page 9 via gateways between different network es, gateway services, network intercon- borders. This means that alternative nection services, and emergency servic- and other information better passed in real-time text protocols may be used, es. All of those services are enriched to text than dictated—especially when the but they must be able to interconnect higher usability via support of real-time two communicators have different ac- via gateways with real-time text to en- text together with voice and sometimes cents. When using one line or otherwise sure full interoperability. This will make video. Open-source components are occupied in a conference, a person can possible the goal of real-time text being available and should be continually im- answer a second line in text only and available everywhere. proved when possible. receive a quick message or have a quick The R3TF will help facilitate the • Include real-time text in 112/911 text conversation. When talking to an development of interworking test beds emergency services when they move to IP networks. Authorities are already elderly parent, for example, a person can that will enable implementers to test pushing for this in the European Union use text to supplement voice to make how well their solutions comply with the and the United States. sure important information has been standard. Moreover, the task force will understood. In interactions with an in- facilitate the distribution of information • Become an R3TF sponsor and en- teractive voice response system, instead about the technology, about the tech- courage employees to participate in of having to wait while the voice slowly nology’s user requirements, and about projects. reads out all the choices, real-time text the technology’s implementation, and it References can provide an almost instant list of the will act as an educator on related issues. choices visually so users can immediately 1. The International Telecommunica- The Web site of the R3TF is http:// read and select the number they want to tion Union (ITU) defines real time in www.realtimetext.org. press. These and a myriad of other uses ITU-T F.700 Section 2.1.2.1. Real-time will become common as real-time text The R3TF Is for Everyone text is defined in ITU-T F.700 Annex gets deployed as a natural and always A.3 and ITU-T F.703 Section 5.3.2.3. What can you do to help the R3TF? present parallel communication mode 2. Defined in ITU F.703 Section 7.2 on any voice phone call. • Add your knowledge and expertise to and specified for the next-generation- those of the R3TF so that the task force The Real-Time Text Taskforce network IP Multimedia Subsystem in can grow real-time text and remove bar- 3rd Generation Partnership Project TS Launched on 30 July 2008, the Real- riers to its implementation. 26.114, Multimedia Telephony, Media Time Text Taskforce (R3TF) is an in- • Help prevent SIP networks from Handling and Interaction. dependent open forum for engineers, blocking real-time text traffic, even if motivated individuals, experts, compa- they block VoIP traffic for internal rea- 3. RFC 5194 was published by the nies, and organizations that wish to help sons. In SIP networks and products, IETF as an informational document. test, implement, and advance the wide- real-time text support, as described in 4. The Real-Time Text Taskforce is a spread adoption of the real-time text RFC 4103, should be regarded as nor- project group separate from the IETF. framework.4 Its goal is to ensure that mal mainstream and possible now. Real- real-time text is as readily available as time text not only works now; it also is voice for all users. The Internet Society part of next-generation-network system Arnoud van Wijk is disability projects is assisting in the effort by serving as an specifications. coordinator for the Internet Society. Along incubator of the R3TF. • For non-SIP network and products, with other researchers, Arnoud documented the technique for real-time text described Having a single real-time text stand- ensure that the real-time text proto- in this article, combining existing IETF ard that is used everywhere would make col/service used does interoperate with standards to facilitate text streaming over access to communication services easier, RFC4103. IP networks. He and Guido Gybels, direc- and it would eliminate any potential in- • Build on the open-source client that tor of New Technologies at RNID (http:// terworking issues. Unfortunately, with supports real-time text (as well as VoIP www.rnid.org.uk), with contributions the diverse types of communication net- and video) to implement clients for mo- from other experts in communication works and devices that are in use today, bile/cellular terminals as well as com- and accessibility for people with disabili- this is not possible. puters. ties, edited and coauthored Framework Include real-time text in your design The R3TF will promote real-time • for Real-Time Text over IP Using the and development of new services, such text as the real-time text standard that Session Initiation Protocol, which the as voice and videoconference services, most terminals and networks can either IETF recently published as information answering machine services, call centre use native or easily interconnect with document RFC 5194. services, language interpretation servic-

10 IETF Journal IETF 72 • October 2008 • Volume 4, Issue 2

Talking with Jorge L. Contreras

The attorney for the IETF talks with the IETF Journal about intellectual property, licensing, and what makes the IETF so unusual in the world of copyrights and copylefts.

IETF Journal: How did you get involved in the IETF? Jorge L. Contreras: My firm, WilmerHale, has provided legal advice for the IETF from the early days. I took over from a partner who left about 10 years ago and have been working with IETF since then.

IJ: Did you ever think you would be inter- IETF is just a forum in which partici- ested in Internet standards? pants can develop standards. IETF it- JLC: I have an undergraduate degree in self does not make or sell products, so electrical engineering, so I was always it cannot actually infringe a patent. It is

interested in technical issues. But the the implementers of a standard, who sell Photo by Mirjam Kühne IETF attorney Jorge L. Conteras law that applies to standards organiza- a product that implements the standard, tions was much less developed when I who can be accused of infringing. began practicing law in 1991. The first That is not to say, though, that IETF case to draw significant attention to in- is never involved in patent litigation. Be- or GPL, but commercial enterprises of- tellectual property issues in standards cause patents are increasingly important ten have an aversion to the GPL because organizations involved Dell Computer. to the companies that send participants it is viewed as risky when distributed In 1998, Dell participated in an SDO to IETF meetings, there are sometimes with proprietary software. As part of [standards development organization] lawsuits between those companies. If the process, we helped develop a new that was creating a video bus standard. the lawsuits involve patents covering variant of the Open Software License They did not comply with the IP policy standards that were developed at IETF, [OSL] that could be used with nonprofit of the SDO and then later tried to en- the IETF is often called upon to provide enterprises. There were objections to force their patents against other SDO evidence regarding the IPR policies that the license from for-profit enterprises. participants. The U.S. Department of were in effect at the time, the partici- Finally, we settled on using the open- Justice brought an action against Dell, pants in certain working groups, and the source BSD licence, but it took many with the result that Dell’s patents were contributions that various parties made rounds of discussion to get there. no longer enforceable. It was a signifi- to a standard. In such cases, the IETF cant result and one that really shook up is not a defendant but merely acts as the IJ: Is working with the IETF different the world of standards law. provider of information that is essential from working with other organizations? Today, most companies that come to to resolution of the case. JLC: Oh, yes, the IETF is unique. Of- ten, it is not actually clear who the client the IETF are aware of the Dell case and IJ: What other legal matters do you handle is. The IETF is more a concept than an a number of more recent cases that have for IETF? elaborated on the issues first raised in entity. The Internet Society [ISOC] is Dell. JLC: I advise IETF on a wide range the organizational home of the IETF, of legal issues. One issue that has got- and ISOC signs most of the contracts for IETF participants often have patents ten attention recently is the licensing of services that the IETF needs, including that affect standards developed at IETF, IETF software tools to the community. everything from the RFC Editor and and so long as they disclose these pat- The tools can be created by companies IETF Secretariat to contracts for hotel ents in compliance with the IETF IPR contracted by the IETF—like the IETF venues and network services. [intellectual property rights] rules, they Secretariat—or by volunteers. There is a The IETF Trust is a different legal are fine. If they violate the rules, how- strong desire to release the tools on an entity altogether. It is the custodian ever, they risk the loss of patent rights, open-source basis, and I have worked of the IPR owned by IETF, including just as Dell did. with the tools team, the IAOC and software code, the IETF trademarks the IETF Trust to evaluate various ap- IJ: Has the IETF ever been sued under and logo, written records, and, most im- proaches that might satisfy the many patents? portant, the RFC series itself. constituencies involved with the IETF. JLC: No, the IETF has never been sued For example, certain open-source devel- Continued on next page for patent infringement. An SDO like opers favour the General Public License,

11 IETF Journal IETF 72 • October 2008 • Volume 4, Issue 2

Jorge L. Contreras, continued from powered to grant licences—subject to processes. These include both the in- page 11 specific guidance that has been given by house lawyers of IETF participants and Now that the IETF Trust is up and the IETF community. lawyers for litigants that involve IETF running, it is also available to adminis- IJ: How about the IETF’s patent policy? standards, parties that IETF contracts ter rights in older RFCs. Those rights with, and others. JLC: The patent policy is now codified are generally still with the RFC authors, at BCP 79. The IETF has a process IJ: What about your book? Will there be a but the Trust has set up a lightweight whereby participants have to disclose version 2? process for authors to license their old their patents if the patents are related RFCs to the Trust. A number of com- JLC: I’m chair of the Technical Stan- to work that is ongoing in an IETF panies and individual authors have al- dardization Committee of the Ameri- working group. You can also disclose ready done that, and we are encouraging can Bar Association’s Section of Science other people’s patents if you know they other active IETF participants to follow and Technology Law. In that capacity, affect the work in a WG. If you know suit. I served as editor of our committee’s of a third-party patent that could affect Standards Development Patent Policy IJ: Outside of the IETF, do you work with the development of a certain protocol or Manual, which was published last year other standards bodies? standard, you can disclose it. and is intended to offer a set of- an JLC: I work for numerous companies In this way, the IETF is unusual: It notated, policy-neutral language that that are involved with other standards does not require a patent holder to li- SDOs, consortia, and others can use in groups, both large SDOs like IEEE cense its patent. The patent holder has developing their own patent policies. A and smaller consortia and special inter- to disclose it, but it is not obligated to number of IETFers worked on the book est groups. I also get involved in projects license it. This has not discouraged project, and I am grateful for all of their that affect Internet standards groups, companies from sending participants to help and insights. like ISOC’s establishment of the Public IETF meetings, however. And in fact, As is often the case, right after the Interest Registry to become the domain many companies license their patents publication there were changes to laws name registry for the .org top-level do- covering IETF standards for free. In and regulations, new cases came up, and main. That was an interesting project, some areas, however, there are lots of so on. So, yes, it will need an update, and I continue to advise organizations patents, and people do pay royalties on and I’m currently looking for volunteers in that area. them. to help with that project! Not long ago, some IETF participants IJ: What’s been happening in the IETF’s said they believed that a certain compa- IPR Working Group recently? ny’s patent would cover all of IPv6. It For more information about Jorge L. JLC: The IPR WG has nearly complet- caused quite a stir in the community. I Contreras, please see http://www.wilmer ed a revision of the IETF IPR policy had several discussions with the com- hale.com/jorge_contreras/. For a list of related to copyrights [currently at BCP pany and tried to get them to commit to publications, visit http://www.wilmer 78]. The revised policy will make a lot of licence it for free. Eventually, they never hale.com/publications/whPubsList. things easier to manage. For example, if specified what they thought the patent aspx?Attorney=685d7e20-d9c6-4a01 someone wants to evolve an IETF RFC actually covers, and to my knowledge, -82f3-5712e6929245 in an SDO other than IETF, there’s they never licensed it. But I’m also un- Jorge is the author of Standards Devel- no way for IETF to grant that permis- aware that they have ever tried to en- opment Patent Policy Manual (paper- sion today. The other SDO must seek force the patent against implementers of back), which can be found at http://www. permission directly from the original IPv6, so that’s where it stands today. amazon.com/Standards-Development document authors. In some cases, that -Patent-Policy-Manual/dp/1590319281. is very difficult, because authors have IJ: It sounds as if a lot of what you do is Note: Standards Development Patent left their companies, moved on to other to manage people’s expectations about the Policy Manual can also be found on Google projects, or, in some cases, passed away. IETF, is that right? Books. For example, in one case, we transferred JLC: Yes, the IETF is an unusual orga- some of the 802.11 MIB work to IEEE. nization, and even though it’s very well- That took some doing, because some of known, not many people—especially the RFCs were quite old. In that case, other lawyers—really understand how it IEEE had to go and contact the authors, all works. So I spend a lot of time talk- so things took a little while. Under the ing to other lawyers about the IETF new policy, the IETF Trust will be em-

12 IETF Journal IETF 72 • October 2008 • Volume 4, Issue 2

The Internet and Bandwidth- As we engage in IETF activities on the topic—including BoF sessions and, Intensive Activities eventually, working groups—it’s important to keep a few simple realities in By Leslie Daigle mind. First, it’s not strictly about P2P technology itself. Second, the network cattered across the globe, a number of networking issues are being noted that impact might be local (as in, “My P2P can loosely be classed as stemming from bandwidth-intensive activities. These participation is wrecking my neighbour’s Sare applications and services that cause traffic that is higher in bandwidth, that fol- VoIP [voice over Internet protocol]”) or lows paths neither anticipated nor desired by the network architect and operator, transit (such as spikes in peering costs and that has an impact on other network activities traffic. As a result of the degrada- due to unexpected load). Third, there are tion in service the situation causes for other users, network providers often turn to different classes of reasons that the net- bandwidth management in an attempt to curtail or restrict the excessive flow. work operator may have no reasonable In the United States, one such situa- P2P technology. By definition, peers incentive or ability to adjust the net- tion emerged when network service pro- and peer connectivity are not tied to work to meet demand. These include the vider Comcast and P2P file sharing ser- network topology, so traffic does not constraint of dealing with significant, vice BitTorrent wound up at odds over necessarily follow expected network unmatched expenses (such as no addi- whether Comcast’s bandwidth manage- paths. Furthermore, P2P file-sharing tional revenue to offset the capital cost) ment activities were unduly restricting services are designed to store and share or dynamically changing bandwidth de- the BitTorrent service. The case was not large chunks of data, so they tend to use mands. As an example of the latter, net- unique, but it shed light on the situation all available bandwidth in data transfer work operators have little or no control and prompted a healthy discussion at between peers. over which peer becomes a supernode in the Real-time Applications and Infra- These are not new problems. The a P2P network. structure area’s peer-to-peer (P2P) In- Internet, in its global reach and local Note that none of this is to be con- frastructure Workshop, which was held reality, has been dealing with, at least, fused with traffic unintended by any in May 2008 (see page 1). pockets of exorbitant demand for band- local customer (unwanted traffic, denial As the IETF considers the work it width since its inception. Typically, the of service, etc.), which does not need ac- might undertake to address these types demand has been dealt with as a net- commodation so much as remediation. of issues, some of the questions on work operational issue, not a technolog- In today’s Internet, the broader im- people’s minds are, What is the basic ical issue. To use an example from the pact of dealing with existing problems problem? Is it an issue with a particu- all-but-forgotten past, FTP traffic was, through traffic shaping, with its unin- lar application (P2P)? Or is it a question at one time, one of the largest sources of tended consequences, or through tiered of network providers’ inability or lack expensive, transoceanic link traffic from Internet access has the potential for a of interest to reprovision network seg- Europe to the United States. Paying for chilling effect on openness and innova- ments? a European Archie anonFTP archive tion. The answer is not simple. From a index for the purpose of giving prece- The long view is that this sort of stretch technology perspective, the Internet is dence to European sites mirroring the in network demand is normal and, on a activity agnostic. Therefore, in principle, same files made sense as a way of reduc- 1 global level, healthy. By making a net- any popular application or service could ing that traffic demand. work to ship packets around, the model run traffic in directions that have noth- The best path forward appears to be is about packet shipping; it’s not about ing to do with the way actual networks a dual-pronged approach—in other making and maintaining highly special- are built. In fact, more data-intensive words, finding ways to allow such appli- ized connections. To address the current (and network-topology-independent) cations as P2P technology-based ones issues, we need to consider approaches applications and services are rolling out to (1) fine-tune their use of network that not only solve the immediate prob- and causing these types of bandwidth bandwidth availability and (2) identify lem but also are applicable beyond any issues. For example, virtual realities, more-palatable options for managing particular application technology and such as Second Life, along with other bandwidth in the face of overwhelmed that do not introduce such architectural video and audio streaming applications network links. These are the types of complexity as to limit aspirant applica- are also having noticeable impacts on activities the IETF considered in two tions. networks. Nevertheless, some of the BoF sessions at IETF 72 in Dublin (see issues are exacerbated by the nature of page 1). 1. http://www.savetz.com/articles/ibj_bunyip.php.

13 IETF Journal IETF 72 • October 2008 • Volume 4, Issue 2

IETF 72 Welcomes ISOC Fellows By Wendy Rickard

ix technology specialists and researchers from Africa, Asia, and South America journeyed to Dublin, Ireland, Sfor their first IETF meeting as part of the Internet Society’s (ISOC’s) Fellowship to the IETF programme. Guided by their mentors and supported by ISOC staff, the fellows had been selected from among dozens of applicants and given opportunities to sharpen their technical skills, indulge their interests, and meet face-to-face with colleagues and others whom they’d known only by reputation or by way of time spent on working group (WG) mailing lists.

By all accounts, the fellows benefited country code considerably from the experience, bring- top-level domain Photo by Gerard Ross ing with them—and taking away—their registry where ISOC Fellowship to the IETF programme fellows and mentors at IETF 72 in Dublin. own unique perspectives. he develops soft- Meet the Fellows ware written in Perl, maintains a few Web sites, and No stranger to travel, the Pakistani Born and raised in a small city a few implements DNS-related technologies, native recently earned a Ph.D. in elec- kilometers from Santiago, Chile, Hugo such as IDN. Even though Internet trical engineering from Ajou University Salgado developed a passion for mathe- security has become a passion of late, in South Korea, a master of science in matics as a child. Although he began his Hugo writes that it is the IDN work that electrical engineering from the Univer- studies by pursuing a degree in physics interests him most. “We were the first sity of New South Wales in Australia, at the Universidad de Chile, in his third Spanish TLD with IDN,” he writes, “so and a bachelor’s degree in electrical en- year he discovered the Internet and we are very concerned about the changes gineering from the National University changed his major to computer science. that came with IDNAbis.” of Sciences and Technology in Pakistan. Today he works for NIC Chile, the .cl Attending an IETF meeting was an He is interested primarily in 6LoW- eye-opener for Hugo. “Everyone was PANs, particularly in mobility, security, and routing issues. (See page 16.) IETF 72 Fellows and Mentors friendly and open-minded,” he said. Alejandro Acosta (Venezuela) “That makes for a very rich environment Mohamad Dikshie Fauzie conducts for developing ideas and to be creative Mentor: Elwyn Davies research in Internet measurement anal- in.” Following the trip, Hugo planned yses in dual-stack IPv4/IPv6 environ- Ali Akbar (Pakistan) to participate in mailing list discussions ments at Keio University in Japan. Born Mentor: Carsten Bormann and to spread the work of the IETF. and raised in Indonesia, Mohamad Tamrat Bayle (Ethiopia) “We are currently preparing our first supplements his research with work as a Mentor: Hesham Soliman informational RFC submission on the School on Internet–Asia (SOI-Asia) op- Mohamad Dikshie Fauzie .cl extensions for EPP registration,” he erator at Bandung Institute of Technol- (Indonesia) added. ogy, where he operates dual-stack IPv4 Mentor: Erik Nordmark Ali Hammad Akbar is an assistant and IPv6 networks for real-time distance Hugo Salgado (Chile) professor in the department of computer learning using IP multicast operation. Mentor: Patrik Fältström science and engineering at the University He’s also actively involved in Indonesia’s Kumar Saurabh (India) of Engineering & Technology (UET), IPv6 task force, a group consisting of Mentor: Hadriel Kaplan the largest engineering university in academics, government representatives, Pakistan. He also consults to UETs and representatives from telecommuni- IETF 72 Returning Fellows Al-Khawarizmi Institute of Computer cations companies and Internet service Alberto Castro (Uruguay) Sciences, where he helped establish a providers that are working to implement Martin German (Uruguay) research group called WATCHNETs IPv6 in Indonesia. Subramanian Moonesamy (wireless and ad hoc actuator and sensor Attending IETF 72 helped Moham- (Mauritius) networks). ad gain a better understanding of the

14 IETF Journal IETF 72 • October 2008 • Volume 4, Issue 2

problems associated with IPv6 deploy- writes. “It is my strong belief that [at- Controllers (SBCs), which involves ex- ment and Protocol Independent Multi- tending] the IETF meeting will assist tensive application of the session initia- cast (PIM), an area that is critical to his my country in general—and the Ethio- tion protocol (SIP) and which explains research. He plans to use the knowledge pian Telecommunications Corporation his interest in the IETF’s SIP working he gained in Dublin as the basis for a re- in particular—in finding solutions for group. port to Indonesia’s IPv6 task force about efficient and scalable internetworking At Sonus, Kumar is involved in de- the latest developments. He also plans needs.” veloping next-generation telecom prod- to write a report to SOI-Asia about the In his role as internetworking coor- ucts, such as SBC, BGF, and softswitch. status of PIM–Sparse Mode. dinator with British Telecom in Ven- “My work involves developing applica- University professor and researcher ezuela, Alejandro Acosta was recently tions using IETF protocols like SIP and Tamrat Bayle possesses a deeply held be- involved in the implementation of IPv6 Megaco,” he writes. Kumar hopes to use lief in the power of a robust information within the company’s network running his experience at the meeting to further infrastructure to support his country’s BGP, firewalls, Linux, and IP services, enrich his knowledge base of those pro- IT industries. He also says he’s a strong including SSH, Apache, and DNS. “My tocols. “No one in Sonus Bangalore has believer in the IETF’s contribution to responsibilities in the company include ever attended an IETF meeting,” he the success of the Internet. This native everything related to the IP protocol,” writes. “I hope to be able to tell them Ethiopian is an assistant professor and Alejandro writes, “including devices, how important the IETF meeting is to head of the Department of Information services, connections, troubleshooting, our work.” Technology at the College of Telecom- and VoIP using Open Source.” As part of a new initiative, ISOC munications and Information Technol- Since he was in high school, Alejandro launched its Returning ISOC Fellow- ogy of the Ethiopian Telecommunica- has been interested in “everything re- ship to the IETF programme at IETF tions Corporation. There he teaches lated to computers and specifically with 72. For the first time, fellows who at- graduate-level courses in advanced com- the Internet.” His main areas of interest tended a previous IETF meeting were puter networks, data communications, today include IP, BGP, DNS, and routable to return for IETF 72. ISOC in- mobile ad hoc networking, and wireless ing protocols. “The IETF community vites applications from alumni of the IP networks. He also advises on master’s has had a big impact on those fields and, fellowship programme who wish to ac- degree theses and serves as a principal therefore, on me,” he writes. Attendance tively participate and contribute to the investigator on a project whose aim is to at an IETF meeting not only brings work of the IETF and who feel that at- increase classroom interaction with mo- Alejandro face-to-face with technolo- tending another meeting in person is es- bile wireless technology. gists working on the issues that interest sential to their own professional devel- him most; it also opment and local community. For more enables him to information, see http://www.isoc.org/ bring the knowl- educpillar/fellowship/returningfellows. edge he gains to shtml. the two national universities with which he works ISOC extends opportunities for organiza- closely, as well as tions to become sponsors of this important to the groups, such programme. Sponsorship demonstrates a as LACNIC. commitment to technical capacity building in less-developed regions and shows support

Photo by Gerard Ross Kumar Saurabh for extending participation in the IETF Fellow Mohamad Dikshie (right) with mentor Erik Nordmark. says the IETF is to those in developing countries. It also one of the main creates opportunities to build contacts with forces behind the Attending IETF 72 offered Tamrat technologists and potential regional leaders evolution of the Internet and its associ- a unique opportunity to enhance his who are highly knowledgeable about condi- ated standards. The software engineer knowledge and to contribute more inte- tions in developing countries. Those who are at Sonus Networks in India is helping grally to the growth of the emerging IT interested in becoming an ISOC Fellowship design and implement Border Gateway industries in his country. “The Internet to the IETF sponsor should contact ISOC Function (BGF) by using H.248 pro- is the new frontier in our country,” he at [email protected]. tocol. He also works on Session Border

15 IETF Journal IETF 72 • October 2008 • Volume 4, Issue 2

Joining the IETF Fold meet Prof. David Culler and Samita Chakrabarty and attend talks by Pascal Ali Hammad Akbar Thubert and Jean-Philippe Vasseur— people who work in subjects closely re- An IETF 72 fellow reflects on working group politics, the culture of leadership, and the lated to my interests and who are highly IETF dress code. regarded. Likewise, it was quite motivat- ing to see young scholars like Jonathan ’d like to take this opportunity to express my sincere thanks and appreciation to Hui and Phil Kevin at 6LoWPAN and the Internet Society and its sponsors for their sponsorship of the ISOC Fellow- ROLL working groups to present their shipI to the IETF program and to the organizers at the IETF, who made it possible works. Their success stories bespeak of for me to participate in the 72nd meeting of the IETF. All of the travel, lodg- their professional approach and relent- ing, and hospitality arrangements extended during the stay were splendid and were less pursuits. handled very professionally. My indebtedness is to Leni Nazare, Martin Kupres, and Mirjam Kühne for their efforts. With limited leisure time at my dis- posal, a city tour seemed like a good Though I was by and large familiar ing group. While attending the meeting extracurricular activity, so I set out to with the workings of IETF, I was in- as a first timer, I found myself awkward- hitchhike. While I went to the city cen- deed a newbie to its proceedings. In ly overdressed—not at all in the getaway tre in a more hop-on, hop-off mood, my the past, I would wonder how work- style of the majority of participants. touring spree turned out to be more aca- ing group (WG) ideas popped up: was Professor Bormann promptly comment- demic. My visit to the highly acclaimed it the WG chair who would spell out ed in a lighthearted manner that of all Trinity College and the National Uni- the seemingly Utopian ideas? Or was of the participants, only two gentlemen versity of Ireland enabled me to meet it the companies that would steer the were clad very formally—a dig on me, I some very good researchers in Dublin. chartering of the agenda items? It was realized! Prof. Murphy from University College only through firsthand experience at an IETF meeting that I became able to fully comprehend the working style: a clearly I realized that people here at the IETF accept being led only by chalked-out agenda is thoroughly delib- those who are focused, doers, and team players—and who are erated and firmed up through consensus not bothered by carefree attire and easy style. on the mailing lists. Afterward, it gets floated for consideration at the IETF meeting. Objective synoptic presenta- The meeting also afforded me inter- Dublin visiting faculty from Washington tions and question-and-answer ses- action with other fellows from all over State University, and Prof. Sumit Roy sions after each Internet-Draft expose the globe. While exchanging notes with were among the professors I met who the participants to a therapeutic forum Hugo Salgado from South America and work on IP-based wireless networks. I wherein they reflect upon and make ap- SM from Mauritius, I realized that such plan to take those initial interactions on propriate amends to their proposals. The people from diverse backgrounds and of to subsequent levels of rapport. ideas evolve through debate and candid a multitude of ethnicities, who have will As a whole, the experience of spend- comments, though at times these might and potential, very often remain un- ing just about a week in the IETF folds seem like forays into an Internet war tapped contributors. Though their pas- proved remarkably eventful. It could, zone! Undoubtedly, the two consequent sions might find expression through an however, result in more than that. For features of IETF meetings—synergy open call for participation on the IETF instance, pursuit of an Internet-Draft to- and proactivity—arise from honest de- mailing lists, it is only through bursaries gether with my mentor—in order to ex- bate that sometimes relegates courtesy and fellowships that they can get rec- plore ways and means of opening a new to a lower priority. These are the people ognition for their efforts. It was indeed ISOC chapter in Lahore (my hometown) for whom the maxim holds true: “If vio- very rewarding for us all to be part of and offering talented minds for ISOC— lence is a sin, silence is a felony.” such an activity. all are merely the initial contemplations My doubts were further cleared up At times, my admiration for academic we wish to pursue. when I met my mentor, Prof. Carsten stalwarts has bordered on infatuation. Bormann, a pleasant, modest, and And there could be no better place than knowledgeable person who maintained the IETF meeting to get them all to- a characteristic silence unless provoked gether. To my immense pleasure, I could and who chaired the 6LoWPAN work-

16 IETF Journal IETF 72 • October 2008 • Volume 4, Issue 2

IPv6 Deployment: Lessons from the Trenches

An IETF 72 panel looks at experiences with IPv6 deployment.

uring the IETF 72 technical plenary, the Internet Ar- chitecture Board (IAB) hosted a panel on the subject ofD IPv6 deployment. The five-member panel was composed of Internet community members who have firsthand experience with operational IPv6 deployments. They represent the perspectives of Regional Internet Registries, or RIRs; network operations teams; broadband services; content delivery thberg

services; and host applications. The panelists communicated ö their IPv6 adoption successes and hurdles, as well as their IPv4-depletion contingency plans, including carrier-grade network address translations (NATs), or CGNs, a concept Photo by Peter L that is currently under debate. IETF 72 panel discusses IPv6 deployment. Motivation and Background and a few have turn, the five RIRs that together cover partial deployments, yet they may hit Studies suggest that the completion of the globe assign portions of the /8s to the v4 allocation cliff harder than either IPv4 address allocations by IANA to ISPs in their regions according to their of the other two, aforementioned com- the RIRs could occur as early as 2011 local policies and practices. To give a munities. This will leave enterprises in (see http://www.potaroo.net/tools/ sense of the allocation pace, in Decem- a costly scurry to rectify the situation at ipv4/). Regardless of the exact date, ber 2004 there were 76 /8s remaining; the last minute. the idea of an empty storehouse will, in December 2005 there were 65; in without question, change the network- IPv6 deployment in operational net- December 2006 there were 55; in De- ing landscape. In an effort to prepare works across the Internet is a work in cember 2007 there were 42; and in June for that eventuality, various players are progress. Transition mechanisms have 2008 there were 39. While the abso- working toward widening and hasten- existed and been deployed for years, in- lute number of allocations per year has ing IPv6 deployment. cluding dual stacks and various transla- remained somewhat constant, the per- tion and tunnelling mechanisms. Over Some content providers are planning centage of remaining /8s being allocated time, more hosts and networks are ahead by readying their content for IPv6 is growing steadily each year. moving to native IPv6 operations. Col- endpoint hits. Some of the service pro- If, as one model predicts (http://www. lectively, we now have several years of viders and broadband providers that saw potaroo.net/tools/ipv4/), the IANA free experience with both. the need started their efforts some time pool runs dry in December 2011, then ago, and they’re now moving toward The IAB established this plenary IP address blocks that have never been infrastructure and service delivery that topic to provide background and input allocated to RIRs will be allocated. That can and will run on IPv6. Both face a from those experienced with deploy- won’t mean end users or corporations bit of a chicken-and-egg problem: the ments and issues in order to empower will no longer be able to get IPv4 public content providers would move faster if the IETF community to do its part to addresses from their ISPs. It means the they knew the operators had the services encourage and facilitate the universal currently defined IANA free pool allo- fully baked to deliver IPv6 eyeballs to deployment of IPv6. cations will be completed. Rather than the content. And the operators would View from the RIRs receiving this news as Chicken Little invest more in their IPv6 services and would—as an indication that the sky is Mark Kosters, Chief Technology infrastructure deployments if the con- Officer, ARIN falling—Mark urged us to look at it like tent the end customer demanded were the westward expansion of the United available and abundant. RIR Allocations States in the 1800s. At that time it was Enterprises are, in some way, the Currently there are 39 IPv4 “/8” address possible to go out and get land from the swing votes. Objectively, few enterprises blocks (2^24, or 16,777,216 addresses) government for only a small registration have moved toward wide-scale deploy- remaining in the IANA free pool that fee—land that had not been previously ments of IPv6. Some have IPv6 pilots; can be allocated by IANA to RIRs. In Continued on next page

17 IETF Journal IETF 72 • October 2008 • Volume 4, Issue 2

IPv6 Deployment, continued from page 17 addresses; both have policy proposals in ness and promotion work for IPv6. The the works for doing so. PI address grants RIRs have taken an aggressive stance on farmed. Today, you can still acquire a are held in tension because backbone trying to move IPv6 adoption forward. farm or a large piece of land; it just costs routing for IPv6 has not yet reached the They have issued position statements, a lot more, and it will have been owned same scale and stability as those present delivered awareness-raising and educa- by others—whether or not they used it— in IPv4 BGP, and the community ques- tional workshops, conducted research thereby giving it a definite market value. tions how much route bloat from PIs can on IPv4 allocations and IPv6 deploy- And today there exists a complex and be reasonably handled. ment, provided education and advice for governments and nongovernmental or- Both [service and broadband providers] face a bit of a chicken- ganizations, and hosted IPv6 networks during meetings, such as those of the and-egg problem: the content providers would move faster if they IETF—all to help drive IPv6 adoption. knew the operators had the services fully baked to deliver IPv6 “This is an important time of transi- eyeballs to the content. And the operators would invest more in tion, and people need to participate,” their IPv6 services and infrastructure deployments if the content Mark said in closing. “The registries’ the end customer demanded were available and abundant. policy development process is very bottom-up. So come join the effort.”

robust market for titling, brokering, and RIR Policy Development Lessons Learned from IPv6 Deployment owning the land. Likewise, the days of With IPv4 allocation completion on Alain Durand, Director of Internet Gover- IPv4 address “homesteading” are com- the horizon, the volume of policy work nance and IPv6 Architecture, Comcast ing to an end, and many more stringent by RIRs on this subject has ballooned. policies, and, perhaps, markets, will Fourteen policy proposals—almost half Comcast, a large cable operator in the emerge for dealing with IP address use of the open proposals—concern IPv4 United States, began its IPv6 deploy- and propriety. depletion policies. One of the propos- ments several years ago with a two- The IPv6 address space, on the other als concerns global policy, which states phase approach. First, it is readying the hand, is a 128-bit space, of which IANA that as IANA’s free allocations of /8s infrastructure by using IPv6 for man- has given out very little. The homestead- approach exhaustion, every RIR will get agement of cable modem devices and ing of IPv6 has barely begun. The RIRs a /8. Another proposal deals with lib- network infrastructure. This paves the have been fairly active in the past few eralizing the transfer policy for moving way for the second phase, wherein Com- years in assigning IPv6 address blocks blocks of addresses between RIRs and cast will offer home users IPv6 service to their Local Internet Registries (LIRs) LIRs and ISPs and organizations. In to their endpoints. That second phase is and ISPs, with RIPE NCC and APNIC the IPv6 policy realm, proposals exist to now in planning stages, with some lab being by far the most active. ARIN and make it easier to transition to and use trials under way. APNIC were making similarly sized IPv6. In the autonomous-system (AS) The cable industry’s Data over Cable allocations since 2003—around the realm, the RIRs currently allocate a lot Service Interface Specification (DOC- 40 to 50 mark per year—until 2007, of 2-byte AS numbers. These would be SIS) model assigns an IP address to when ARIN handled over a hundred exhausted in 2011 as well if the cur- each customer’s cable modem. This dif- IPv6 allocations. To date, RIPE NCC rent allocation rate continues. There are fers from DSL, wherein an individual has dealt almost half of all of the IPv6 4-byte AS numbers available, but many modem does not have its own IP ad- allocations—1,208—which equates to parties have returned them because the dress. Cable operators thus use a lot of 33,041 /32s. The next closest is APNIC, network as a whole does not support IP addresses and are very involved in with 580, accounting for 23,233 /32s, them very well (e.g., BGP implementa- allocation policy. Their move to IPv6 followed by ARIN with 496, LACNIC tions and OSS systems). We need to en- was somewhat motivated by the deplet- with 97, and AfriNIC with 47. These al- courage our vendors and ISPs to better ing IPv4 address space. They foresaw locations are from the RIRs to provid- support 4-byte ASs, because this is an- that in a few years an organization re- ers. However, only ARIN, APNIC, and other hole—like the IPv4 depletion— questing a few IPv4 addresses for Web AfriNIC have actually assigned provid- looming on the Internet highway. and mail servers might still easily get er-independent (PI) address blocks to Building Awareness them, whereas a request to IANA for end sites directly. The RIPE NCC and a large-scale allocation is likely to be LACNIC have not yet assigned PI IPv6 In addition to policy and allocations, the RIRs conduct a fair amount of aware-

18 IETF Journal IETF 72 • October 2008 • Volume 4, Issue 2

turned down much sooner. Moving accelerated only so much by applying other, with multiple overlapping ad- the modems’ management interfaces to additional resources. “Nine women can’t dresses to customers. While not impos- IPv6 means that they each get a glob- make a baby in one month,” quipped sible, NATing creates a lot of complex- ally unique and routable IP address, Alain, urging application vendors to get ity—especially in management—and it thereby avoiding messy address overlaps moving. Hosted or outsourced services makes the troubleshooting of customer or NATs. from third-party vendors are in a spot The company learned important les- similar to applications, wherein many sons from its initial experiments with do not yet support IPv6. IPv6 deployment. The first lesson Seeing the IPv4 depletion ahead, the taught that starting early saves money. Comcast team is plotting a transition For example, including IPv6 early in the course that includes IPv4 access for quite DOCSIS 3.0 specifications in early 2005 some time. Once scarcity hits, the team ensured that products rolling out today imagines, a wide range of IPv4-only include IPv6 at no extra cost. The second computers, devices, and operating sys- lesson was that the network buildout for tems will still exist in customers’ homes

IPv6 was easier than expected. Comcast (e.g., Win95, 98, XP, PlayStations, thberg ö started by adding IPv6 addresses on Xboxes, and some consumer devices). router interfaces—and nothing else. To Though more and more IPv6-ready its surprise, nothing bad happened. So equipment is entering homes, custom-

Comcast left the network like that for ers will not jettison the old IPv4-only Photo by Peter L several months. Next, it enabled IPv6 equipment; they keep using the older routing, IS-IS, and BGP. Again, noth- devices. Also, the content on the Inter- issues much more difficult. In addition, ing bad happened. Not one outage oc- net is almost exclusively IPv4. Recently, traffic-engineering gyrations, such as curred that was traced back to the IPv6 thanks to Google, we have some IPv6 source-based routing, might be neces- pieces. This was a critical step in build- content to look at, but not much. IPv4 sary to handle the overlaps. Outages ing the confidence of the operations hosts and content will need reachability are usually linked to complexity in the team, proving that IPv6 could run sta- for some time yet. network, so this increased complexity in the network is less than desirable. The Comcast team is looking at- us “Following IPv4 completion, if you give all new customers IPv6 ing tunnels and provisioning IPv6 to only, with no IPv4 support, then the IPv4-only devices can’t get customers’ home gateways. This would out of the home, and new, IPv6-only devices can’t get to the enable Comcast to offer both IPv6 and predominant IPv4-only content on the Internet.”— Alain Durand IPv4 services to endpoints behind those gateways. IPv6 would run natively from hosts to IPv6 targets. IPv4 is delivered bly in a production dual stack network. Comcast’s plan therefore involves by first having the gateway speak IPv4 Currently, IPv6 exists in both Comcast’s a dual-stack core, which Alain says internally, and second, by transport- access and backbone networks. should work well—at least until it’s no ing the IPv4 packet over the IPv6 infrastructure network via a tunnel. The For Comcast the problem with IPv6 longer possible to get any more IPv4 ad- IPv4 packet would be detunnelled in- was not in the networking layers but in dresses. “Following IPv4 completion, if side the ISP network at a large v4-to-v4 the application and services ecosystem you give all new customers IPv6 only, NAT box, a CGN. That box translates around the layers, like their operations with no IPv4 support, then the IPv4- the IPv4 packet to a globally routable and support, management, billing, and only devices can’t get out of the home, IPv4 address and sends it off to the IPv4 third-party systems. Not only do many and new, IPv6-only devices can’t get target. Alain refers to this as a dual- of those systems lack the required IPv6 to the predominant IPv4-only content stack-lite service. (Work on this is oc- support, but getting that support is not on the Internet.” To counter that hitch, curring in the Softwire working group.) high on most vendors’ priority lists. one might add the practice of NATing The advantage is that the infrastructure Adapting the code doesn’t happen over- new customers with overlays of private itself requires only IPv6 addresses for night. It takes implementation, testing, addresses from the RFC 1918 blocks. debugging, deploying, scaling, and sta- This brings undesirable results, though, bilizing. It’s a linear process that can be such as NATs piled one on top of the Continued on next page

19 IETF Journal IETF 72 • October 2008 • Volume 4, Issue 2

IPv6 Deployment, continued from page 19 each customer’s number of concurrent connections from a host—allowing for sessions. TCP and UDP allow for only no safety buffer—one could infer for a operated devices while allowing either 65,535 total source ports per single IP CGN deployment a user-to-IPv4-ad- IPv4-only or dual-stack hosts to reach address. As IPv4 addresses become dress ratio of about 130:1. An 8:1 ratio IPv4-only content on the Internet. “This scarce, a single public IPv4 address must would allow for a worst case, of about dual-stack-lite concept makes IPv6 ser- support many CPE routers, each with 8,200 simultaneous per-user connec- vices incrementally deployable,” claims several hosts behind it. How many hosts tions. And for a case where multiple Alain. “You don’t have to wait for the can be supported by one IPv4 address computers are all connecting from the rest of the Internet—the content and depends on the number of concurrent same customer premise, a 20:1 ratio applications—to move to IPv6 in order TCP and UDP connections being made would allow for a worst case of about to roll out the service. You can deploy by the average host. 3,300. What is the right ratio to use? IPv6 in your own world and get some To illustrate that point, Shin offered After warning of the CGN issues, immediate benefit out of it.” The IETF’s the example of browser connections to Shin proceeded to offer a graphical, most successful protocols over the past a Google Maps display of San Francisco time-lapsed, step-by-step progression of 15 years have been incrementally de- International Airport, an application how an operator might transition to an ployable, and that is Alain’s goal for net- that employs AJAX technology. One IPv6 network by using a dual-stack-lite works transitioning to IPv6. characteristic of AJAX is that it simul- service architecture. This transition plan A Step-by-Step Transition Plan taneously makes many discreet HTTP offers incremental deployment and IPv4 Shin Miyakawa, Director of IP Technology connections from the host to the server backward compatibility. The operator Development at NTT Communications in order to pull down different small starts by enabling IPv6 on its peering “pieces” of the content all at the same routers and backbone. Then the CGN While sharing much of Alain’s view of time (see Figure 1). As Shin demon- element/function is added, which logi- the need for incremental deployment strated, if the session count is limited cally sits north of the operator’s access of IPv6 in the face of depleted IPv4 to 30 concurrent connections, the map concentrator in the POP. The operator space, Shin cautioned against accept- loads appropriately. If it is limited to 20, may then place a private IPv4 address on ing a common misunderstanding about one block of the picture is missing. If it the CPE router’s provider-edge-facing carrier-grade NAT. “Please do not get is limited to 15, only 35 percent of the (PE) interface. This IP will be NAT’ed comfortable with the idea that a carrier- picture’s blocks are successfully received. by the CGN sitting in the operator in- grade NAT will ‘solve’ our problems,” he At a limit of 5 connections, the browser frastructure. This step addresses the warned. “Do not believe that if we have throws an error message. If each user decreasing availability of routable IPv4 a CGN, we need not move to IPv6.” needs only one such application con- addresses. On the contrary: according to Shin, the nection at a time, then one IPv4 ad- CGN concept has significant and seri- Step two introduces IPv6 on the cus- dress would serve approximately 2,100 ous restrictions as well as implications tomer side of the CPE, a client-based hosts. This 30-concurrent-connections for the Internet’s end-to-end design Softwire tunnelling solution from the number is for Google Maps only. The principle. “The last thing we would want customer’s hosts, and a tunnelling con- NTT Com- is the existence of a CGN to slow IPv6 m u n i c a t i o n s adoption,” he said. Instead, Shin sug- Max 15 Connections research team gests employing CGN as a backward- has observed compatible mechanism for the purpose iTunes opening of speeding along IPv6 adoption. “It 230–270, Ama- will do so by ensuring an incremental zon grabbing deploy-ability mechanism that does not 90, YouTube exclude or alienate v4 hosts [nor v4 con- pulling 90, and tent] once deployed,” he said. Once such OCN’s Photo a model is supported, network operators Friend consum- will be able to see a clear transition path ing 170–200. to IPv6 that contains neither product cliffs nor flagship upgrades. If one esti- mates an aver- Shin warned that the dual-stack lite’s Figure 1: When concurrent connections are reduced, an image may age of 500 open CGN component may necessarily limit not be able to load appropriately.

20 IETF Journal IETF 72 • October 2008 • Volume 4, Issue 2

centrator in the POP. This solution ISPs on the same architecture, and sites deploying IPv6 today. Explaining encapsulates IPv6 over IPv4 by using such was discussed extensively at a re- why the company made the investment, L2TP as the encapsulating protocol. A cent Internet Area interim meeting on Lorenzo stated, “When the day comes client-side software component sits on the v4-to-v6 topic. In the assistance of that users have only IPv6, they will need the customer’s host, and a networking various enterprises, application service to be able to get to Google. That’s the device sitting north of the CGN termi- providers, schools, and governmental long-term view.” He identified several nates the L2TP tunnel in the operator’s agencies with dual-stack deployments, shorter-term reasons for the deployment, network. At this point, the deployed Shin notes, externally facing systems including lower latency and packet loss, network supports dual-stack customer (e.g., Web, e-mail, and DNS) must be AJAX applications breaking behind ex- hosts and delivers to those hosts con- IPv6 capable first; then the customers’ cessive NAT (as described in detail by nectivity to both v4 and v6 content. other, internal systems follow. Shin), and the irritation of NAT travers- As new customer deployments occur, In addition to the aforementioned al mechanisms, such as STUN. The year Step 3 involves moving the Softwire dual-stack proposal, the NTT group in 2011 is when Google foresees the RIR v6-in-L2TP-over-v4 client function Japan has already deployed a commer- IPv4 address pool exhaustion to their off the hosts and into the CPE router. cialized IPv6 service to over 5 million ISPs and PIs, and they point to IPv6 This allows the clients sitting on the customers. This solution uses a highly as the only sensible solution. Starting CPE’s private side to contain any or all of IPv4-only, IPv6-only, or IPv4/IPv6 “Please do not get comfortable with the idea that a carrier-grade dual-stack hosts while still providing NAT will ‘solve’ our problems. Do not believe that if we have a access to either native v4 or native v6 CGN, we need not move to IPv6.” — Shin Miyakawa Internet content. Step 4 upgrades the provider edge controlled (i.e., walled garden), all-IPv6 as early as possible will ensure deploy- (PE) access concentrator to be IPv4/ network, including endpoints, to deliver ment is ready in time, if not well before. IPv6 dual stack. Note that the Softwire specialized value-based services to end The Google IPv6 effort began as a side tunnelling mechanism is required only users. (20 percent) project on the part of a few until such time as both the PE access employees. Once others caught wind of concentrator and the CPE support v4/v6 What can the IETF do to hasten IPv6 ipv6.google.com, they jumped in along- dual stack. Once both can run IPv6 na- adoption? According to Shin, first is an side Lorenzo and team, and now Gmail tively, the operator has no further need additional IPv4 private address space al- and News are IPv6 enabled too. They for the tunnelling mechanism. This cap- location for carrier/operator access net- built a pilot network and ran the infra- tures the attractiveness of the proposed work equipment that sits in the IETF’s structure at an IPv6 conference, proving transition plan: any of the key pieces— internal infrastructure devices, behind a that it worked. PE access concentrator, CPE router, CGN. Next would be defining a simple or end-host system—can be combined security scheme for IPv6 (see page 23). As more and more people wanted to in any combination of their v4-only or Implementations of IPv6 DNS deploy- get IPv6 running for their applications, dual-stack support, and still, the opera- ments need wider dispersion. Multi- the team grew and they scaled up the tor will be able to deliver a v4/v6 service. protocol label switching (MPLS) with pilot. Even though it was a pilot, they This provides true incremental deploy- IPv6 support must exist in the network dispelled the notion that it was experi- ability for operators, saving them from devices. Though commercially available mental, which could lead to skimping costly forklift upgrades (for end hosts, IPv6 supporting firewalls have been on quality. The key lay in incremental CPE gear, or access concentrators) and available since NetScreen (now Juniper) growth. A pilot IPv6 network doesn’t providing them with a grow-as-you-go released its in the early 2000s, other se- have to be as scalable or as capable as transition. The CGN remains in the curity devices—like IDP, IPS, and Web an IPv4 network on day one, but it does network until the provider was prepared filtering—are still awaited, as are load need the same types of production ser- to end the life of the IPv4 service. balancers. vices as soon as possible, as are found in IPv4 networks, including monitoring, NTT is considering putting in place A Simple Call to Action support, documentation, written quality by spring 2010 a service as described Lorenzo Colitti, Network Engineer and standards, and audits. earlier—before the IPv4 address com- Researcher, Google pletion. NTT is working with other Start small, and make steady prog- Google has one of the only large content

Continued on next page

21 IETF Journal IETF 72 • October 2008 • Volume 4, Issue 2

IPv6 Deployment, continued from page 21 balancing or traffic engineering from thinks NAT-PT’s presence will lower the network side, which are features the value of IPv4 on hosts, and opera- ress. In addition, Lorenzo urged that, present in v4. Without those features tors and users will opt for IPv6 hosts, whenever possible, one should design it’s tough to make large-scale applica- with NAT-PT fronting the v4 applica- the IPv6 deployment to be as similar tions deployable. Lorenzo also says tions. As soon as the content is v6, the as possible to one’s IPv4 network. “Ev- multihoming ought to be allowed using NAT-PT function will be removed, and ery time I made a design decision that /48 prefixes. He expressed the need for it’s pure v6 from there. wasn’t the same as IPv4, it turned out /127’s on point-to-point links (currently First Impressions Are Every- to bite me down the road,” he said. prohibited by RFC 4291) to help avoid thing denial-of-service attacks, and VRRP Lorenzo counselled against the use Stuart Cheshire, Wizard without Portfolio of tunnels in interdomain routing, cit- for v6 because neighbor unreachability at Apple ing increased latency and difficulty in is not fast enough. Apple chose IPv6 link local addressing Start small, and make steady progress . . . . [W]henever possible, for the AirPort Express wireless base station because of the auto configuration one should design the IPv6 deployment to be as similar as pos- features that require the user to do noth- sible to one’s IPv4 network. ing to get LAN-based printing, streaming music, and network administration running. The solution has been more debugging. Also, today most IPv6 op- NAT-PT is another item big on reliable and works better than IPv4 in erators are indiscriminately giving tran- Lorenzo’s list because, he says, it will a single-network home. The Internet, as sit to any other IPv6 operator, which lead to an all-IPv6 network more quick- Stuart pointed out, is a different story. slows convergence, increases round- ly than dual-stack lite will. He argues Five elements interact to make an IPv6 trip times, and creates partial visibility that once IPv4 address allocations slow solution work for the customer across the for yours and others’ networks. Some significantly, parts of the network will Internet: the operating system, applica- transit providers have incomplete IPv6 be able to serve hosts an IPv6 address tion software (such as a Web browser), routing tables that cause black holes only. Of course, all IPv4 content will home network, ISP, and content (such for those routes. The solution is direct not be served immediately on v6, so v6- as Web sites). peering with quality IPv6 networks, only hosts will, for some time, still need yielding direct contacts by which to ad- to reach v4-only sites. Using something Without any one piece, the solution dress and improve routing and connec- like NAT-PT transforms the content fails. Content is the key. Without IPv6 tivity issues. “Don’t assume the current deployment problem into an application content, ISPs have no incentive to carry IPv6 Internet works,” he said. “On the porting problem. However, NAT-PT IPv6. As Stuart said, if a customer can- other hand, get involved. The only way is deprecated in RFC 4966. “All of the not get IPv6 from the ISP, then there’s to accelerate the progress is to acceler- drawbacks of RFC 4966 are really draw- no reason for content accessible via IPv6. ate the involvement.” backs of NAT, and they are all present If the browser is not IPv6 enabled, then the customer will not be able to access Lorenzo’s IPv6 product feature/ca- in v4 NAT too,” said Lorenzo. Like IPv6 content and therefore will not pur- pability wish list included MPLS traf- Shin, Lorenzo doesn’t like NATs— chase IPv6 connectivity. If the OS is not fic engineering, mature load balancing, or the NAT mechanisms in NAT-PT. v6 ready, then apps can’t be either. In- IPv4-style multihoming, and hardware However, being an IPv6 champion, he centives must exist for all of the players. processing for both 6to4 and extension feels that incremental transition mecha- Apple’s incentive was the so-called cool- header filtering. Lorenzo notes that nisms are key to hastened adoption. “If ness factor of IPv6, so now Apple’s OS, today they have to drop at the edge of we want to reclaim the end-to-end prin- Apple’s browser, and most of Apple’s their network every IPv6 packet that is ciple, then we must do it with IPv6.” networking apps support it. “Now we not clearly TCP, UDP or ICMP due And in order to do that, Lorenzo called must find compelling incentives for the to a lack of hardware filtering for ex- for a bare-bones standard that addresses other three pieces to support v6,” en- tension headers. IPv6-style multiple- a v6 host connecting to a v4 server. This couraged Stuart. “Or, at the very least, address multihoming has not worked would require a DNS application layer make sure there are no disincentives.” well. Failovers break TCP connections. gateway. The focus should be on net- Lorenzo says HIP and SHIM6 do work-based translation scenarios, not To drive home the point, Stuart de- support failovers, but then new con- on a host-based solution. “[End-to-end scribed an application-level issue that nections see timeouts; both lack load connectivity] can happen in v6 but not Apple faced with regard to its Safari while we still have v4 around.” Lorenzo

22 IETF Journal IETF 72 • October 2008 • Volume 4, Issue 2

IPv6 Panel Takes Questions from the Floor What are the biggest operational issues percolating up from the network administration staff? Alain Durand: IPv6 addresses are difficult to type. I often ask people to write down an IPv6 address and read it back over the phone. Of all the attempts, only one person has succeeded in repeating the address correctly. So we must avoid IPv6 addresses as much as possible, and we must be more ardent DNS users. Shin Miyakawa: It’s not technical, but the lack of education of the customer-facing support staff. We don’t want the front-line staff answering support calls by saying, “What is IPv6? I don’t know anything about it.” Getting IPv6 into all the training manuals and achieving a basic level of familiarity across all levels of staff are the hardest things NTT has faced. Lorenzo Colitti: Failure to follow familiar IPv4 design principles. There is muscle memory there, and so people just naturally try to do an operation the v4 way, but then something breaks, or it doesn’t work. They don’t know why, and they don’t know where to find the answer. Training everyone that something must be done differently in this situation is a challenge and takes time. Putting safeguards in place, like deployment templates, helps keep people from such mistakes.

Are you able to get the equipment you need? What are the equipment gaps? Alain: The back-office applications are the most difficult. Mark Kosters: The RIRs are putting our money where our mouths are by making our services available on IPv6. Some of the middle boxes such as load balancers are not really ready yet with their IPv6 support. Also, their technical support and best practices are not mature, so we do not get as much consultative assistance as we would expect.

Are you driving IPv6 to your customers, or are your customers driving you to IPv6? Shin: We are pushing customers to use IPv6. We need IPv6 because we have a lack of resources from which to offer customers advanced services. Alain: Many customers want to access their e-mail, browse the Web, and download a video from YouTube. I don’t think they care whether this gets accomplished over IPv4, IPv6, or avian carrier [RFC 1149]. What matters is that we can keep the services of the Internet growing regardless of whether we have IPv4 or are out of v4 and need IPv6. Mark: The research is pretty conclusive that people see that IPv4 works now, and so they feel no need for IPv6. They see IPv6 as a capital cost for them. The question arises: Where does the money come from that will help us solve a problem that we don’t have right now? Gregory Lebovitz: It appears unanimous that we are driving IPv6, not the customers, because we need to produce new services that customers do want, and we do not have enough IPv4 addresses going forward to accomplish the task. We need IPv6 as an enabler. If customers are not begging us for IPv6, then the stakes are very high for us to make its presence very transparent to users—or risk its rejection. It has to be invisible and usable by the “grandmother living in the countryside,” as Shin says.

NATs in the middle can break things and create walled gardens. Is it possible to demand that DOCSIS put NATs at the ends? Alain: DOCSIS is layer 2, not layer 3. We are not talking about centralized carrier NAT. The question is, Where is this divide in the network? I agree that this is bad and that it could provide a single point of failure and that NATs need to get close to the customer. I suggest talking to the application developers.

Is it possible to do some analysis to figure out how much it will cost an end user to have a public IPv4 address? Could this be an incentive for using IPv6? Shin: NTT is currently that kind of research. Mark: There is a new policy proposal that is related to IPv4 address transfers. One aspect of transfer is market-based transfer, which currently is not allowed by RIR policy. ARIN asked a lawyer to look into this, and the answer is that an open market would be best.

What is the state of readiness of IPv6 DHCP [Dynamic Host Configuration Protocol]? Alain: The DHCP community has worked quite a bit with vendors recently, and the results are quite promising. (Editor’s note: See articles on IPv6 DHCP back-offs in recent editions of the IETF Journal). Applications developers are waiting for the peer-to-peer readiness of IPv6. Do you see inbound connectivity to the home as compelling-enough motivation? Stuart: I agree that inbound connectivity is the only compelling reason to use IPv6. Everything else is currently also available on IPv4. So, the only reason is that it gives me unhindered peer-to-peer connectivity.

23 IETF Journal IETF 72 • October 2008 • Volume 4, Issue 2

IPv6 Deployment, continued from page 23 and IPv6 http connections in parallel, plication/service. Please connect me to taking the first response and resetting it.” Apple uses a connect-by-name API Web browser and certain performance the second. Failures or hangs at either so that applications don’t even have to delays associated with dual-stack cli- step, on either track, no longer hang the know or care whether the underlying ents. When a dual-stack-capable Web user experience. connection is IPv4 or IPv6. Both Java browser connects to the Internet, it and Windows have similar APIs. The moral, according to Stuart, is Five elements interact to make an IPv6 solution work for the that as we move toward IPv6, when customer across the Internet: the operating system, application you build an app, avoid getaddrinfo() software (such as a Web browser), home network, ISP, and and such APIs. Instead, use concur- content (such as Web sites). rency and asynchrony. Yes, these new mechanisms will send extra packets and initially open more connections than first conducts an AAAA record look- The getaddrinfo() API was the prob- will actually be used. The first one that up, then it does an A (Address) record lem because it exposes addresses to the succeeds will proceed, while the others lookup and tries an IPv6 connection. If application when it shouldn’t. Applica- will be reset. This is the right design that fails, it tries an IPv4 connection. tions don’t need to know about Ethernet decision for IPv6. “We are trading off Everything works as long as this series addresses, and they don’t need to map a few extra packets and connections to of events occurs quickly, including any IP addresses to Ethernet addresses; the vastly improve the user experience,” said failures. Unfortunately, lack of AAAA kernel ought to do that for them with Stuart. “And that’s the point: let’s make responses and IPv6 connection failures ARP. Likewise, an app should not be sure to remove the barriers to transition are common. involved in mapping DNS names to that might otherwise make people regret Apple faced an issue regarding a big- addresses. The app should just tell the their first tentative steps into IPv6 de- name Web site. Customers complained system, “Here are a name and an ap- ployment and use.” that the site was really slow. Upon in- vestigation, Apple discovered that the site’s DNS servers did not send valid re- Related Links sponses to AAAA queries. Either such Introduction Email from the IAB sites do not respond to an AAAA query, or they send back a mangled, malformed http://www.ietf.org/mail-archive/web/ietf/current/msg52686.html response. The connection sequence IAB’s follow up email blocks are waiting for an answer that http://www.ietf.org/mail-archive/web/ietf-announce/current/msg05138.html isn’t coming. The user perceives this as Audio stream archive application slowness, which started oc- http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf72/ curring when the user’s computer first got an IPv6 address. Select “ietf72-ch3-wed-plenary.mp3” The root issue is the getaddrinfo() The IPv6 panel starts at time 01:13:00 on the stream. API, which blocks waiting for an IPv6 Q&A (only 1/3 appears in the article) at 02:29:00 address query that may never be an- Presentation archive swered. Because the problems first ap- http://www.ietf.org/proceedings/08jul/plenaryw.html peared when the ISP started offering http://www.nttv6.jp/~miyakawa/IETF72/ IPv6 service, the issue landed in the ISPs’ laps. This is bad for the industry http://www.stuartcheshire.org/IETF72/ because both the customer and the ISP One hypothetical model of an address allocation timeline get a bad impression about IPv6. These http://www.potaroo.net/tools/ipv4/ thorny disincentives must be removed if Related drafts we are to hasten deployment. draft-nishitani-cgn-00.txt Apple’s implementation now disas- draft-shirasaki-shared-adrs-00.txt sociates the IPv4 and IPv6 tracks. The tracks perform the AAAA and A que- draft-ietf-v6ops-cpe-simple-security-02 ries in parallel, and they try the IPv4

24 IETF Journal IETF 72 • October 2008 • Volume 4, Issue 2

IPv6 Transition at IETF 72 an IP packet’s destination address needs to have meaningful context at all points By Geoff Huston in the network. IP itself is a connec- tionless datagram protocol, without any he developmental work of the Internet Engineering Task Force (IETF) on form of capability negotiation. Its also a IPv6 has, from the outset, included the study of the particular issues associ- very challenging exercise to equip a net- Tated with transition to IPv6. The first effort to explore the transition space was at work with intermediaries that attempt to IETF 29 in March 1994, and it was termed TACIT, an acronym of Transition change the IP packet header mid-flight. and Coexistence including Testing. While it was admittedly a forced acronym, it This implies that the use of translation was illustrative of the IETF’s desire to include consideration of transition issues and substitution to create backward as part of the design of IPv6 itself. The underlying consideration here is a study compatibility has limited applicability of how a diverse amalgam of applications, hosts, and network elements that col- in the context of IP itself. lectively make up the Internet and the related collection of enterprise networks can A Classical Transition be upgraded, selectively augmented, or pable of recognizing and using some ex- The original approach to IPv6 transi- replaced in order to support IPv6 and, tension or new attribute. For example, tion could be termed a “classical” view ultimately, to deprecate all further use of the Border Gateway Protocol (BGP) of transition. Because IPv6 is not a IPv4 while at the same time preserving is in the process of transitioning from backward-compatible augmentation of all of the essential, “any-to-any” end- 16-bit Autonomous System (AS) num- IPv4, it is not possible to deploy new to-end property of the Internet Proto- bers to 32-bit AS numbers. This BGP hosts and network infrastructure with col (IP) through the transition. From transition uses a combination of transla- the TACIT birds-of-a-feather sessions, the baton was then passed to the NG- The study of transition to IPv6 has now broadened in scope, and TRANS working group in July 1995 at today a number of IETF working groups are examining aspects IETF 33. This working group was ac- of transition to IPv6, including the SOFTWIRE, BEHAVE, and tive until IETF 55 in mid-2002, when INTAREA working groups, in addition to V6OPS. the baton was again passed—this time to the V6OPS working group, which met first in early 2003 at IETF 56. The tion and tunnelling that allows a BGP support for only IPv6 and have these study of transition to IPv6 has now speaker configured to use the longer AS networks, devices, and applications ex- broadened in scope, and today a number numbers to be backward compatible change IP packets with their IPv4 coun- of IETF working groups are examining with the existing installed base of BGP terparts. An application that is equipped aspects of transition to IPv6, including that uses the 16-bit AS number format. with IPv6 requires its host to have IPv6 the SOFTWIRE, BEHAVE, and IN- The protocol specification of BGP- in support in its protocol stack, and for the TAREA working groups, in addition to cludes an initial capability negotiation host to be able to communicate, the net- V6OPS. when BGP is first started up, allowing a work is required to have IPv6 support. Given that this study now encom- “new” BGP speaker to establish wheth- And if an application wishes to commu- passes a period of 14 years, what exactly er its BGP neighbour is also capable of nicate with another application, all the are the issues with respect to the transi- supporting longer format AS numbers networks on the path between the two tion to IPv6, and why is this transition or not. As a result, upgraded versions hosts also must be configured to support taking such a long time? of BGP can coexist with older versions the transmission of IPv6 packets. In Backwards Compatibility of BGP, so that the overall transition of other words, a “complete” deployment of BGP to use 32 bit AS numbers can be IPv6 requires all applications, hosts, and This is not the only transition we’ve faced undertaken on a piecemeal basis. This network infrastructure and middleware at the basic level of protocol infrastruc- particular backward-compatible trans- to be aware of IPv6 and explicitly con- ture, and the conventional approach lation technique relies on a combina- figured to handle IPv6 packets. In this is to make the changes “backward tion of capability negotiation and the classical form of transition, the major compatible” Backward compatibility properties of hop-by-hop interpretation constraint is to avoid any flag day, or any can take many forms, but typically in- of tokens, where AS-number values are other form of synchronized or orches- volves some form of initial negotiation interpreted in a strictly local context. trated common activity across the entire between communicating parties that IP is an end-to-end protocol, as dis- establishes whether both parties are ca- Continued on next page tinct from a hop-by-hop protocol, and

25 IETF Journal IETF 72 • October 2008 • Volume 4, Issue 2

IPv6 Transition at IETF72, continued from For early adopters of IPv6, whether it from the larger address fields in the page 25 was application designers, suppliers of packet header, there is no significant rel- host operating systems or routers, or ative change in IPv6 from a performance network. Individual elements of the net- network operators and system admin- or benefit perspective. In addition, the work should be able to undertake their istrators, the investment in dual-stack Internet itself is now so much larger and part of the transition without requiring capability in their area of responsibility so much more diverse that commonality any action to be performed on any other would generate the greatest extent of of purpose is difficult to sustain. These element. The transition should be a piece- resultant benefit only when the transi- days, altruism often takes a backseat to meal activity. This classical approach, in tional dual-stack phase was complete. business interests as the Internet now general terms, assumes that each appli- In other words, there was no immediate operates as a collection of quite conven- cation, host device, and network element reward for those early adopters of IPv6, tional business enterprises. Indeed, since is able to make an independent decision and late adopters did not experience any the bursting of the Internet bubble at the as to when to enable support for IPv6. detrimental side effects, because the full start of this decade, this sector of busi- To preserve connectivity of the network benefits of an outcome of IPv6 adoption ness is relatively conservative as well, as a whole, then, as and when each net- would be realized only once the entire and far greater emphasis is placed on work element or end device is configured environment adopted IPv6 in a dual- securing immediate returns on invested with support for IPv6, it would not “cut stack configuration with IPv4, at which capital over and above the undertaking over” and remove all IPv4 support from point IPv4 could be deprecated from the of longer-term investments and with the device, but, instead, it would support operational network. less-certain outcomes. This implies that the operation of both IPv4 and IPv6 for any such commonality of purpose and an extended period. This was termed This approach assumes that all parties a vision of a longer-term outcome is ex- the dual-stack transition approach. This are equally motivated to undertake this tremely challenging to sustain in the face mode of progressive shift of the elements transition, and that each party will do of shorter-term considerations. of the Internet to a dual-stack opera- so as quickly as possible. It also assumes tion would continue for as long as there that all applications, all connected de- The combination of these factors cre- were essential components of the overall vices, and all components of the net- ates a situation that has been incapable environment—from applications to In- work’s infrastructure are capable of be- of sustaining the operation of this “clas- ternet infrastructure—that support only ing configured to operate in dual-stack sical” transition process. So the IETF IPv4. Only when the entire connectivity mode. Perhaps those assumptions may was motivated to look at transition in domain was supporting comprehensive have been feasible in practical terms if slightly different terms—to see whether dual-stack operation would it be possible IPv6 had been in a position to offer very this approach could be refined to offer to deprecate IPv4 from the network and significant cost, performance, or func- some more-immediate benefits to early remove all support for this protocol (see tionality improvements over IPv4. In adopters and not to stall the entire pro- Figure 1). such a case the superior characteristics cess while awaiting completion of the of the new technology would have pro- late adopters of dual stack. pelled the Transition with Incremental Out- transition comes: Tunnelling p r o c e s s . However, The initial refinement to this original any such transition model, explored in the NG- IPv4 IPv6 m a j o r TRANS working group, was intended r e l a t i v e to allow various IPv6-only and dual- improve- stack applications to support IPv6 from Figure 1. The Progressive Stages of IPv6 Transition. ment in the outset, so that any benefits related perfor- to IPv6 could be realized immediately The issue with this approach to IPv6 mance, cost, and utility is not the case in and not be forced to await the actions of transition was that it relied on a strong a comparison of IPv6 with IPv4, because the slowest adopters to also make their mix of altruism, common purpose, and IPv6 represents only a marginal change moves. The motivation involved the res- shared motivation, as well as a high level in the underlying network design. Fol- toration of simple application program- of technical capability from everyone: lowing a further decade of incremental ming interfaces for applications, the res- from suppliers and vendors through to refinement in both IPv4 and IPv6 we toration of coherent end-to-end packet network operators and even end users. have the current situation where, apart delivery in an IPv6 network, and the

26 IETF Journal IETF 72 • October 2008 • Volume 4, Issue 2

benefits that this clear and simple appli- While the mo- cation architecture offers to applications tive and logic for the that operate in an over-the-top mode. use of tunnels in this Such an end-to-end packet transport transition scenario environment offers strong end-to-end are certainly sound, channel security as well as restoration the overhead here is of the uniform binding of IP address to that tunnels normally end-point identity in the IP architec- require explicit con- ture. figuration of both The objective of the attempt to operate ends of the tunnel, in an end-to-end IPv6-only mode over a and any form of tun- largely IPv4 substrate network led to the nel topology that attempts a fully meshed development of a number of approaches Figure 3. Transition Using Tunnels. to IPv6 transition that relied on tun- interconnection of the nelling techniques, wherein IPv6 pack- IPv6 islands runs into ets are encapsulated in an IPv4 packet an N-squared scaling problem in tunnel 6to4 sites are passed directly from 6to4 wrapper, allowing these IPv6 “islands” configuration almost immediately. gateway to gateway. To complete the to treat the IPv4 network as a form of This, in turn, has led to exploration of picture, each local 6to4 network needs transmission media, or a non-broadcast approaches that supported the concept to provide 6to4 gateway service for IPv6 multicast network. That led to the de- of fully meshed tunnels—but with an packets from non-6to4 IPv6 networks velopment of the general technique of extremely simple single end configura- (see Figure 4). carrying IPv6 packets in IPv4 by treat- tion. This is achieved by associating an A related form of embedding IPv4 in ing IPv6 as an IPv4 protocol—namely IPv4 tunnel endpoint in an endpoint IPv6 addresses to aid in autotunnelling protocol 41 (see Figure 2). IPv6 address. When such a packet is is ISATAP, the Intra-Site Automatic passed to a Addressing Protocol, which embeds the tunnel in- IPv4 address in the interface identifier gress, the field of the IPv6 address to support a IPv4 tun- local scope automated IPv6 over IPv4 nel egress tunnelling approach. These approaches address is can be combined, so that an enterprise defined by can construct an IPv6 network with a the origi- single infrastructure gateway that cre- Figure 2. IPv6 in IPv4 Tunnelling. nal IPv6 ates the prefix and tunnels over the wide destination area network by using 6to4 while tun- address, so nelling over the local area network by The general characterization of this that the tunnel does not have to be ex- using ISATAP. approach to this form of dual-stack tran- plicitly configured at both ends. One of The shortcoming of the 6to4 ap- sition was to allow the initial “islands” these is the 6to4 technique, which gen- proach is that it assumes a general avail- of IPv6 adoption to connect to each erates an IPv6 48-bit prefix by prepend- other via these tunnels, essentially cre- ing 2002::/16 to the front ating an IPv6 connected network from of the 32-bit IPv4 address. the outset. As more of the infrastructure This allows a dual-stack adopted the same form of dual-stack gateway to double as an support, these islands would start to di- IPv6 tunnel egress, serv- rectly interconnect, making the islands ing a local network of larger and the tunnelled gaps shorter. As IPv6 hosts with tunnel these gaps shrink to the point of general services. Each 6to4 gate- dual-stack support, it may be an option way, or 6to4 individual to then tunnel the remaining IPv4 traf- host, needs only to config- Figure 4. 6to4 Tunnelling. fic over IPv6, but perhaps that’s getting ure its end of the tunnel. well ahead of ourselves right now (see All IPv6 packets between Continued on next page Figure 3).

27 IETF Journal IETF 72 • October 2008 • Volume 4, Issue 2

IPv6 Transition at IETF72, continued from a different set of design trade-offs com- nalling and Maximum Transmission page 27 pared with 6to4. In its desire to be useful Unit (MTU) discovery. Where there is a ability and use of public IPv4 addresses. in an environment that includes NATs tunnel MTU mismatch coupled with an A single host behind a network-address- in the IPv4 path, Teredo is a per-host ICMP handling problem, the situation translation (NAT) gateway cannot use connectivity approach, compared with often manifests itself as a TCP “hang”, this approach given that the implicit 6to4’s approach, which can support both where the initial SYN handshake suc- IPv4 tunnel endpoint is drawn from a individual hosts and end sites within the ceeds, but the first large data packet is private address pool and is therefore not same technology. Also, Teredo is now a never transmitted. A typical dual-stack visible outside the IPv4 private address host centric multiparty rendezvous ap- implementation will lock into IPv6 or scope. It also requires firewalls to be plication, and Teredo clients require the IPv4 at the point of completion of the aware of protocol 41 and apply the IPv6 existence of dual-stack Teredo servers initial TCP handshake completion, and filter rules to the inner IPv6 packet. and relays that exist in both the public the data payload problem then causes The Teredo approach addresses both IPv4 and IPv6 networks. From Teredo’s the user’s application to hang. The name of these concerns by using explicit sup- host-centric perspective, it could be said to protocol family association is now port for NAT traversal, and embedding that Teredo is more a connectivity tool locked into the user’s cache, so that re- the IPv6 packet inside an IPv4 UDP than a service solution (see Figure 5). setting the connection and forcing the transport session rather than as an The common feature of all of these application to use IPv4 rather than IPv6 IP transport. Teredo takes a relatively transition approaches is the use of tun- is invariably beyond the user’s direct conventional ap- control. proach to NAT IPv6 host So, is it possible to avoid tunnels and traversal, using a still achieve incremental outcomes for simplified version 9 3 early adopters of dual stack? Behind all of the STUN ac- TEREDO RELAY of the transition scenarios so far lies the 2

tive probing ap- 4 assumption that IPv4 and IPv6 sup- 8 IPv4 Network proach to deter- 7 TEREDO port distinct universes of connectivity. SERVER IPv6 Network mine the type of 6 However, both protocols present much 1 1. Teredo ICMPv6 Echo Request from Teredo Client to Server NAT, and uses 5 the same set of functions to the upper- Restricted 2. Forwarded IMCPv6 Echo Request from Server to Host NAT 3. IMCPv6 Echo Reply from Host to Relay concepts of “cli- 4. Teredo Bubble from Relay to Server level transport protocols, and the header 5. Teredo Bubble from Server to Client ents,” “servers,” 6. Teredo Bubble from Client to Relay fields of the protocol are similar. Just 7. Forwarded Teredo ICMPv6 Echo Reply from Relay to Client 8. Ini�al Packet Teredo-Tunnelled from Client to Relay and “relays.” A T e redo Client 9. Forwarded Ini�al Packet from Relay to host how bad is this backward incompatibil- Teredo client is ity of IPv6 with respect to IPv4? Is it a dual-stack host Figure 5. An Example of a Teredo Rendezvous. completely impossible for an IPv4-only that is located host to initiate, maintain, and close a in the IPv4 world, possibly behind a nels. Tunnels are extremely convenient conversation with an IPv6-only host NAT. A Teredo server is an address and in terms of their ability to interconnect and vice versa? If one allowed vari- reachability broker that is located in the diverse islands of IPv6 without requir- ous forms of intermediaries, including public IPv4 Internet. A Teredo relay is ing any change to the intervening IPv4 protocol-translating NATs and various a Teredo tunnel endpoint that connects infrastructure. However, tunnels are not permutations of Domain Name System Teredo clients to the IPv6 network. without their attendant problems. Tun- (DNS) servers, is this still impossible? nels can be fragile, unstable, and chal- The tunnelling protocol used by Te- Probably not impossible, but it would lenging to diagnose. The issue of Inter- redo is not the simple IPv6-in-IPv4 pro- go well beyond the conventional mode net Control Message Protocol (ICMP) tocol 41 used by 6to4. IPv4 NATs are of packet protocol header manipulation treatment within tunnels is a good sensitive to the transport protocol and and would call upon protocol header example, where a return ICMP error generally pass only Transmission Con- translation, cross-protocol NAT bind- notice is sent not to the original source trol Protocol (TCP) and User Datagram ings, DNS manipulation, and various host, as intended, but to the tunnel in- Protocol (UDP) transport protocols. In forms of application level gateways. gress point that is the source address of Teredo’s case, the tunnelling is UDP, so An approach to this form of transla- the outer tunnel packet. The inner pay- all IPv6 Teredo packets are composed of tion was described in RFC2766, “Net- load, which contains the initial fragment an IPv4 packet header and a UDP trans- work Address Translation—Protocol of the original packet, also includes the port header, followed by the IPv6 packet Translation (NAT-PT).” The approach tunnel header. The critical point here is as the tunnel payload. Teredo represents creates a number of security vulnerabili- the interplay between end-to-end sig-

28 IETF Journal IETF 72 • October 2008 • Volume 4, Issue 2

ties and appears to operate with a high ment that is heavily reliant on various of depletion of the unallocated IPv4 level of assumption about application forms of NATs and possibly some fur- address pool in 2011. The prospect of behaviours, making its operation ex- ther extensions to NAT behaviours and broadening the domain of NAT deploy- tremely fragile. The NAT-PT approach NAT deployment models, including the ment from the edges of the network to was subsequently deprecated in RFC possibility of augmenting the NAT-at- parts of the interior boundaries using 4966 which consigned NAT-PT from the-edge deployment model with vari- carrier-grade NATs was also foreshad- Proposed Standard to Historic status, ous forms of NAT in the middle, as the owed at that session. A report of the with the comment: “Accordingly, we industry contemplates the potential of experience gathered at Google pointed recommend that: the IETF no longer so-called carrier-grade NATs and re- to a pragmatic approach to dual-stack suggest its usage as a general IPv4-IPv6 lated approaches. deployment that advocated undertaking transition mechanism in the Internet, The challenge as we undertake these IPv6 support designed to the same pro- and RFC 2766 is moved to Historic new technical approaches will be to not duction quality standard as IPv4. It was status to limit the possibility of it being lose sight of the fact that short-term cost reported that Google was not in a posi- deployed inappropriately.” pressures need to be balanced against tion to dual stack its major service point IPv4 Exhaustion and IPv6 the collective long-term desirable out- at present, given that IPv6 today still Transition come of an achievable exit strategy from represents lower reliability and higher the ever more complex environment of latency for some users as compared with The one common assumption in all of keeping IPv4 operating. IPv4 connectivity to the same service these transition scenarios is that this du- point. A presentation by Apple pointed al-stack transition will take place across IETF 72 Activity to consumer products that already make the period when there are still sufficient In IETF 72, the issues that we have use of IPv6 link-local addressing. The IPv4 addresses to address the entire In- been confronting, with this combina- presentation also looked at a dataflow ternet across the entire transition phase tion of dual-stack transition to IPv6 and model of connection establishment in and that the event that IPv6 was pri- IPv4 address depletion, were discussed a dual-stack environment, where both marily intended to avert, the exhaustion in a number of working groups, as well IPv4 and IPv6 connections are initiated of the supply IPv4 addresses from the as the Technical Plenary session. What in parallel, and the first path to suc- unallocated pool, would not occur dur- follows is a brief summary of the relevant cessfully complete the DNS and initial ing the transition process. activity in each of those working groups. packet exchange to complete the con- It is generally anticipated that this While these brief summaries provide a nection is the protocol that is associated transition will take up to a further de- general overview of current activities, with the application’s original connec- cade to complete from the current time, the brevity of the description here can tion request (see Figure 6). while depletion of the unallocated IPv4 get in the way of address pool may occur within the next precision, and the two to three years. On one hand, while reader is referred to the overall transition toolbox always as- the proceedings of sumed a wide array of deployment ap- the IETF 72 meet- proaches, this forecast shortage of IPv4 ing and of course will shift the scaling trade-offs for tran- the associated In- sition approaches in ways that will be ternet Drafts for a more complex and more expensive to more complete de- operate than the simpler, dual-stack ap- scription of these proach would have been. On the other technical contribu- hand, this is a forced scenario because tions (http://www. there is no opportunity to go back in ietf.org). time to try this transition again under At the Technical different circumstances. Plenary, the IETF Whatever scenario of IPv6 transition was shown some we contemplate, it now has to be one of the underlying that will take into account the forth- Figure 6. A Dataflow Model of Protocol Selection [Adapted from: metrics of address Stuart Cheshire, Apple, IETF 72 Plenary]. coming acute shortage of public IPv4 allocation and the addresses, which implies an environ- current predictions Continued on next page

29 IETF Journal IETF 72 • October 2008 • Volume 4, Issue 2

IPv6 Transition at IETF72, continued from ent NAT types. The motivation here is binding state is maintained—indexed page 29 that the more Teredo traffic that can be by the IPv4 address values. The reverse The V6OPS working group is looking off-loaded from the Teredo relay to an packet performs a binding lookup, al- at some of the basic operational tools to optimized peer-to-peer connection, the lowing the IPv6 destination address support transition, and, in particular, a more reliable the Teredo performance. to be substituted, and the source IPv4 reexamination of the requirements for Related work has been reexamining address is again wrapped up in the V4-V6 translation mechanisms to see the security issues that are exposed by synthesized IPv6 packet. BEHAVE whether there may be viable approaches the use of tunnelling and the potential also reviewed a contribution calling for to provide the original NAT-PT func- for disruption and hostile attack on the specification of the carrier-grade NATs, tion that might address some of the tunnel. whereby the NAT translation function shortcomings in the original specifica- The BEHAVE working group started is provided at the interior boundary of tion. The basic problem being addressed out with a charter to provide some stan- an Internet service provider (ISP) net- by that effort can be envisaged in a dard specifications for the behaviour work in conjunction with NATs being scenario where there are no more IPv4 of IPv4 to IPv4 NAT units, but in re- performed at the CPE edge. addresses and a network domain is de- cent times this has been expanding to The SOFTWIRES working group ployed using only IPv6, and this domain encompass examination of the role of has also been involved in aspects of the wants to be able to communicate with NATs in various IPv6 transition scenar- IPv6 transition with regard to consid- a domain that is still operating in IPv4 ios, including examination of NATs that eration of Softwires NAT, or SNAT. only and has not deployed IPv6. At perform protocol translation. The cur- SNAT combines IPv4 NAT and IPv4- IETF 72, the working group reviewed rent agenda of contributions to review in-IPv6 softwires to carry IPv4 traffic a set of goals to see whether there could includes the IVI scheme—a proposal through the ISP network that uses only be a viable set of requirements that to use bidirectional address mapping IPv6 service. In essence, this approach could be refined from such a set. While between subsets of IPv6 and IPv4 ad- creates a split NAT whereby the inner this approach of first defining a set of dresses to allow a form of stateless tran- NAT is connected to the outer NAT via requirements and then working on position wherein the binding of the trans- an IPv6 software tunnel. Multiple CPE tential solutions is a conventional mode lation is carried in the address fields of NATs are multiplexed through a single of operation for the IETF, the consider- the packet itself. Another approach to external NAT, thereby reducing the to- ation relating to market timing, where NAT-PT is also being studied. In this tal number of IPv4 addresses in use by deployment of a solution is anticipated case, the asymmetric nature of conven- the ISP (see Figure 7). to be needed by 2010, is a very sobering call to focus the effort here. A related effort concerns the evaluation of modified NAT behaviour, where the conventional binding space of a vector of inner and outer addresses and ports and an associated protocol is replaced by an outer-side address and port and an inner-side tun- Figure 7. Softwires SNAT. nel identifier and an address and port that refer to the NAT device at the other end of the tunnel. The essential concept tional 4-to-4 NATs is exploited and a The INTAREA meeting considered a here is that the NAT function is then proposal for a 6-to-4 NAT was made proposal that calls for standard handling a distributed function across a common to the working group. In this contribu- of MTU negotiation, fragmentation, outer-facing-edge device and the set of tion, the communication is initiated by and signalling for tunnels. Given that inner NATs that are used as a custom- the IPv6 host, and the synthesized view tunnels appear to be major components er-premises-equipment (CPE) device. of the remote IPv4 world is provided of this piecemeal IPv6 transition model, Other work presented at IETF 72 in- by embedding the IPv4 address in the the consistent treatment of tunnelled cluded a review of proposed refinement synthesized IPv6 address. The NAT64 traffic appears to be an emerging, near- of the Teredo specification that would host performs a protocol translation by term imperative for the transitioning In- improve its NAT behaviour discovery extracting the IPv4 address out of the ternet and for the IPv6 Internet as well. function from the simple two-mode IPv6 destination address and providing The impending exhaustion of the IPv4 discovery in the current specification to one of its own addresses as the source address pool has caused another critical- a mode that discovers up to eight differ- address of the IPv4 packet. A NAT use address proposal to emerge. In this

30 IETF Journal IETF 72 • October 2008 • Volume 4, Issue 2

IETF Response to the Kaminsky not unusual for protocols designed in the early 1980s. Any protocol will likely DNS Vulnerability have security problems, and this is especially true for one that was designed By Shane Kerr before security was a concern—and for f you follow the news about information technology, you probably have heard one that has been in use during most of about a new DNS vulnerability discovered by Dan Kaminsky, which is often the evolution of the Internet. Ireferred to as the Kaminsky Attack. Since the DNS is a protocol of the IETF—and The list of security problems with the certainly one of the most successful IETF protocols—let’s have a look at how the DNS protocol and its implementations IETF is dealing with the issue. is long and varied, but here are a few:

Understanding the Vulnerability Briefly, the Kaminsky attack allows • Using reverse DNS to impersonate hosts There are descriptions of the attack on an attacker to put incorrect data into the Internet. Google can find many, but the cache of a recursive resolver, which • Software bugs (buffer overflows, bad the Illustrated Guide to the Kaminsky allows the attacker to return any an- pointer handling, and so on) DNS Vulnerability is quite good, even if swer it wants to future DNS queries • Bad crypto (predictable sequences, you know almost nothing about DNS. for a given domain. The attack is quite forgeable signatures) clever, since almost every piece of the It can be found at http://www.unix- • Information leaks (exposing cache attack has been known for a long time. wiz.net/techtips/iguide-kaminsky-dns contents or authoritative data) -vuln.html. However, in this case, the pieces have been put together in a new and unex- • Cache poisoning (putting inappro- Dan Kaminsky’s official talk about pected way. priate data into the cache) the vulnerability can be found on the Work on securing the DNS began in Black Hat site at http://www.blackhat. DNS Security (Pre)History the mid-1990s. com/html/webinars/kaminsky-DNS. The DNS protocol was originally de- html. signed without any security, which was Continued on next page

IPv6 Transition at IETF72, continued now working under strict time pressures Disclaimer to develop the standard specification for case, it’s a call for reservation of IPv4 The foregoing views do not necessarily tools and protocol mechanisms that need unicast address space to be used within represent the views or positions of either to be fielded into production networks a carrier’s infrastructure for bridging the the Asia Pacific Network Information within a very compressed time frame; gap between the carrier-grade NAT at Centre or the Internet Society. and having every vendor, every network the boundary of the carrier’s network operator, and every operating system and the CPE devices at the boundary to Geoff Huston is chief scientist at APNIC, suppler devise distinct approaches runs the customer. Given the often protract- the Regional Internet Registry serving the the risk of making the situation more ed debates such calls for reservation of Asia Pacific region. He holds both a B.Sc. difficult than it would otherwise be. address space often engender—and the and an M.Sc. in computer science from relatively short time frame left for ex- The challenge for the IETF is to en- Australian National University. Geoff has haustion of the remaining pool of IPv4 sure some clarity of focus on the work been closely involved with development of addresses—it’s not clear whether the concerning transition tools for IPv6 the Internet for many years—particularly IETF will be able to reach a clear con- that also would assist in increasing the within Australia, where he oversaw ini- sensus on this proposal in the remaining address utilization efficiency of IPv4 tial build of the Internet within the Aus- time available. addresses and to be mindful of the in- tralian academic and research sectors. He is creasingly strident call for standardiza- author of a number of Internet-related Summary tion of these hybrid technologies that books; was a member of the Internet Ar- There is no doubt that the impending ex- couple tunnelling, address mapping, chitecture Board from 1999 until 2005; haustion of the IPv4 unallocated address NATs, and protocol transformation in and served on the Board of Trustees of the pool adds some level of urgency as well ways that application designers, operat- Internet Society from 1992 until 2001. as an element of complexity to the IPv6 ing system vendors and providers, and See http://www.potaroo.net. transition agenda, and the work of the operators of networking infrastructure IETF will no doubt increase in inten- can use in simple and effective ways. sity in future meetings. It appears we’re

31 IETF Journal IETF 72 • October 2008 • Volume 4, Issue 2

IETF Response to the Kaminsky DNS Vulnerability, continued from page 31 an ongoing group dedicated to non- both in labs and “in the wild”), and links protocol aspects of the DNS, such to studies of how quickly resolvers were 1997: RFC 2065, adding security exten- as DNSSEC best practices and root patched into various environments. server recommendations sions, was published several years after The dnsext list is the WG whereby any work began. • The DNS Extensions WG, which is changes to protocols would have to be in theory a conventional IETF work- 1999: After early implementation, it standardized. A number of proposals on ing group chartered for a specific was determined that RFC 2065 needed the list were discussed, as were a number goal, but in practice it is an ongo- work, so RFC 2535 was created to fix of nonproposals: for instance, DJ Bern- ing group that has been active since the flaws (see Appendix B of RFC 2535 stein has an alternative to DNSSEC that 1999: changes to the DNS protocol, for the full list of the differences). was mentioned, but djb is unlikely to put such as the DNSSEC RFCs and it forward as an Internet draft. 2005: At workshops for implementers, explanations of how wildcards work, yet more problems were discovered, come out of this working group. Most of the proposals centred on ways to make it even more difficult for including extreme difficulty getting Both groups recently have done secu- an attacker to spoof packets. Another secret-key signing material to and from rity-related work. For example, draft- common theme was for recursive serv- a zone parent. In response, a set of three ietf-dnsop-reflectors-are-evil-06.txt has ers to detect when someone was trying RFCs were published with the new been approved for publication as best to spoof traffic and therefore, put the DNS Security Extensions (DNSSEC) current practices, and work on DNSSEC resolver into a mode that makes spoofs standards: RFC 4033, RFC 4034, and trust anchor configuration and mainte- more difficult. RFC 4035. RFC 4033 was the first time nance is going on in the dnsop working the requirements for DNS security were group. Refinements of the DNSSEC In the end, the dnsext WG chairs documented! protocol (new hash algorithms in the decided to set deadlines for semiformal 2008: DNSSEC gave users the ability wake of recently discovered weaknesses proposals at the end of September 2008. to see the entire contents of a zone, and in existing hash algorithms, clarifica- The proposals would be discussed in Oc- it was by looking at signed records that tions of DNSSEC) are being evaluated, tober, and in November a recommended read no such domain. Privacy concerns and a draft describing how to make forgery resistance approach would be se- made this unacceptable to some domain the DNS more resilient against forged lected. As of the time of this writing, the operators, so a new type of DNSSEC answers (draft-ietf-dnsext-forgery process is still under way. record was created. (RFC 5155 defines -resilience-*.txt) was already being dis- Current Status the extensions.) cussed before Kaminsky revealed the problems he discovered. Some people think the Kaminsky attack What appears here is the history of will accelerate DNSSEC adoption. The DNSSEC proper, but it is not the only IETF’s Response .gov domain will now be signed in 2009, work in the area. For example, TSIG Until 7 August 2008, when the details and there have been rumours that the (RFC 2845) is a way to authenticate were made public, there were IETF par- root zone will be signed soon as a result DNS operations by using a shared se- ticipants who had inside knowledge of of the attack. However, no changes are cret, a procedure that has been widely the Kaminsky attack. There also were expected in the DNSSEC protocols. deployed. participants whose information came The dnsext WG is going to make As of this writing, several top-level only from press reports or other public specific suggestions for a new forgery- domains and part of the reverse tree sources, such as by looking at patches resistance mechanism based on the have been secured with classic DNS- to open-source resolvers. Initial discus- outcome of the selection process. This SEC, as defined in RFCs 4033, 4034, sions had slightly surreal qualities, as should help harden resolvers enough to and 4035. The Public Interest Registry those who had in-depth knowledge of make the Kaminsky attack unfeasible in (PIR) has announced that in 2009 it in- the exploit discussed the ramifications the current Internet. tends to sign .ORG with the RFC 5155 with those who could only guess. The IETF is a great organization for extensions. On the dnsop list, the exploit was reviewing the details of the DNS on a Recent DNS Security Work announced, and the follow-up mails in- technical level. A considerable amount cluded a study of the mathematics of the The IETF currently has two working of good information and discussion en- exploit (estimating how long a typical groups (WGs) dedicated to DNS issued as a result of the attack. It is our exploit would take), links to and discus- sues: hope that everyone involved will benefit sions of vulnerability checkers, posts of from the recommendations that will fol- • The DNS Operations WG, which is relevant news articles (such as exploits low.

32 IETF Journal IETF 72 • October 2008 • Volume 4, Issue 2

IRTF Report By Aaron Falk

What follows are summaries of several updates on the Internet Research Groups (RGs), some of which were reported during the Technical Plenary at IETF 72.

Since IETF 71, three Internet Research Task Force (IRTF)-stream RFCs have been published, including RFC 5166 (TMRG), RFC 5184 (MOBOPTS RG), Aaron Falk, IRTF Chair and RFC 5207 (HIPRG). Three drafts are in the RFC Editor’s queue, and two are in process toward publication. A document is being developed that proposes to formally establish an IRTF RFC document stream. The publication is entwined with draft-iab-streams -headers-boilerplates as well as the revision to RFC 3932. There is still continued interest in establishing a research group (RG) on unwanted traffic mitigations and another one on network virtualization. During IETF 72, four RGs met. Following is a summary of recent developments as well as of developments reported by RGs during the IETF 72 technical plenary. Anti-Spam RG (asrg)

The document that describes the mechanisms used for DNS blacklists will be in the standards track. The other ASRG document (best current practices on blacklist operations) is still a draft. The RG has set up a wiki on spam mitigation techniques that is being further populated and that may evolve into a document analysing why some of those techniques should not be used. The wiki is located at http://wiki.asrg.sp.am. Delay-Tolerant Networking Research Group (dtnrg)

There are currently three drafts in the RFC Editor queue on delay-tolerant networking (DTN) for deep-space communication (draft-irtf-dtnrg-ltp-*). In addition, the DTN code base been moved from Intel to Sourceforge. The Networking for Communications Challenged Communities (N4C) project is helping with the code maintenance, and the Defense Advanced Research Proj- ects Agency is funding a phase 3 effort on DTN. Host Identity Protocol Research Group (hip)

Network address translation and Firewall Traversal Issues of Host Identity Pro- tocol (HIP) Communication has been published as RFC 5207. Current topics of discussion are: • Migration of HIP certificate draft to HIP WG • Using HIP for RFID • Middlebox authentication extensions to HIP There are a number of ongoing HIP experiments as follows: • Boeing is using HIP to build secure overlay networks over untrusted wireless and wired infrastructure.

Continued on next page

33 IETF Journal IETF 72 • October 2008 • Volume 4, Issue 2

IRTF Report, continued from page 33

• HIIT: A video/voice/chat communication system on Linux PDAs utilizing Peer-to-Peer Session Initiation Protocol (P2PSIP) with SPAM prevention over HIP • ICSALabs: IPv6-only HIP connectivity for gaming and SIP applications using Teredo Internet Congestion Control Research Group (iccrg)

Three proposals on congestion control are currently under review. The review on Compound TCP is nearly completed, and the reviews on CUBIC and HTCP are just beginning. CUBIC is an extension to the current TCP standards. The protocol differs from the current TCP standards only in the congestion window adjustment function in the sender side. HTCP stands for TCP Congestion Control for High-Bandwidth-Delay Product Paths. The ICCRG Slow Start design team continues to work on characterizing issues with slow start. Two surveys are currently under discussion: one on open congestion control research issues and one on the current congestion control RFCs (in IRSG [In- ternet Research Steering Group] review at the moment). The RG is planning to meet at the next IETF meeting in Minneapolis. Mobility Optimizations Research Group (moboptsrg)

Unified Layer 2 (L2) Abstraction for Layer 3 (L3)—Driven Fast Handover has been published as RFC 5184. Current topics include: • IP Mobility Location Privacy Solutions (revising based on IRSG review) • Media-Independent Pre-Authentication Framework (revising based on RG Last Call done) • Multicast Mobility (Problem Statement and Brief Survey being discussed) Network Management Research Group (nmrg)

The document specifying SNMP trace exchange formats and specifying a format for aggregation of SNMP messages is currently in IRSG review. Another document on SNMP trace analysis definitions has been published in the AIMS (Autonomous Infrastructure, Management and Security) 2008 conference. A planning meeting to discuss NETFLOW/IPFIX data analysis is scheduled for 30 October in Munich, Germany. The group is looking for new chairs for the RG. Routing Research Group (rrg)

The focus in RRG has moved from advocating proposals to discussing trade- offs of different architectural approaches. There is a lot of interest, and many discussions (1,250 messages since IETF 71) have been held. A recommendation is expected to be published by March 2009.

34 IETF Journal IETF 72 • October 2008 • Volume 4, Issue 2

Scalable, Adaptive Multicast Research Group (samrg)

The SAMRG is meeting in conjunction with the Consumer Communications and Networking Conference (CCNC) 2009, which is scheduled for 10–13 Janu- ary 2009 in Las Vegas. There will be a special session on Scalable Adaptive Mul- ticast in P2P Overlays. More information can be found at http://www.samrg.org under Meetings. The RG might meet at IETF 73 in Minneapolis. Transport Modelling Research Group (tmrg)

Metrics for the Evaluation of Congestion Control Mechanisms has been published as RFC 5166. The group is now working on a new draft on the Common TCP Evaluation Suite (L. Andrew and S. Floyd, editors, draft-irtf-tmrg-tests- OO.txt). For more information about the Internet Research Task Force, visit http://www.irtf. org/.

Recent IESG Document and Protocol Actions A full list of recent IESG Document and Protocol Actions can be found at http://www.isoc.org/ietfjournal/DocProtoActions0402.shtml.

35 IETF Meeting Calendar IETF Journal IETF 72 IETF 73 IETF 75 Volume 4, Issue 2 16–21 November 2008 26–31 July 2009 October 2008 Host: Google Host: .SE Location: Minneapolis, MN, USA Location: Stockholm, Sweden

IETF 74 IETF 76 Published three times 22–27 March 2009 9–13 November 2009 a year by the Host: Juniper Networks Host: WIDE Internet Society Location: San Francisco, CA, USA Location: Hiroshima, Japan 4 rue des Falaises CH–1205 Geneva Switzerland Register now for Managing Editor IETF 73 Mirjam Kühne 16–21 November 2008 Minneapolis, MN, USA Associate Editor http://ietf.org/meetings/73-IETF.html Wendy Rickard

Early bird registration: USD 635 (through Friday, 7 November 2008) Editorial and Design Regular registration: USD 785 The Rickard Group, Inc. Full-time students: USD 150 with on-site proof of ID Editorial Board IETF 73 is being hosted by Google Leslie Daigle Peter Godwin Russ Housley Olaf Kolkman Special thanks to Special thanks to Lucy Lynch

for hosting IETF 72 for hosting IETF 73 E-mail [email protected] Find us on the Web at http://ietfjournal.isoc.org The ISOC Fellowship to the IETF is sponsored by

This publication has been made possible through the support of the following Platinum Programme supporters of ISOC