IETF Journal - Focus on IPv6 at IETF 72 IETF Meetings Related to

Document Sample
IETF Journal - Focus on IPv6 at IETF 72 IETF Meetings Related to Powered By Docstoc
					                                   IETF Journal                                                                       Volume 4, Issue 2
                                                                                                                          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
                                   Set against the beautiful backdrop of a golf resort near Dublin, IETF 72 offered an opportunity to
  Management .............. 1
                                   revisit many of the same themes discussed at prior meetings.
  Message from
                                      IPv6 was, once again, a hot topic, most notably dur-
  the IETF Chair ........... 2
                                   ing 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,
                                   is described in detail on page 17.
  Plenary Report .......... 5
                                     In this issue, Shane Kerr takes a look at the IETF
  Real-Time Text .........9
                                   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
                                   within the IETF took place primarily within working groups, Shane offers a good look at the history
  The Internet and
                                   of DNS security and a brief review of recent DNS security work as well as a compilation of IETF
  Activities ................13
                                      Stepping outside the usual technical discussions, the IETF Journal sat down with IETF lawyer
  IETF 72 Welcomes
                                   Jorge Contreras, who discussed his work with the IETF and, in particular, the latest developments
  ISOC Fellows .........14
                                   in the field of intellectual property rights. The interview with Jorge appears on page 11.
  Joining the
                                      Once again, the IETF meeting played host to a number of engineers from various parts of the
  IETF Fold ...............16
                                   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
                                   As bandwidth management has become an important topic, the IETF has held a handful of meet-
  Protocol Actions ....... 35
                                   ings 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 at-
    tendance, the week was filled with the usual mix of working group (WG) meet-
    ings, 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 gener-
    ated 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 pub-
    lished 88 new RFCs.                                                                  Descriptions and agendas for all
       One of the hot topics during IETF 72 was the coexistence of IPv4 and IPv6.        BoF meetings can be found at
    The discussions about requirements for NAT-PT (network address translation–
    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.
       At IETF 73, we expect to conduct a scheduling experiment that we hope will        Routing Area
    lead to the creation of additional meeting time for WGs. Instead of ending at        alto: Application-Layer Traffic
    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
       I look forward to IETF 73 in Minneapolis, which is scheduled for 16–21            tana: Techniques for Advanced
    November 2008, and will be hosted by Google, and to IETF 74 in San Fran-               Networking Applications
    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:// I look forward to seeing you at the

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 col-
                                                       leagues 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
                                                       questions asked here but also to inspire participants to go back home and assess
       WGs Chartered ...................... 115
                                                       how they could play their part in an IPv6 rollout. A report by the moderator,
       New Internet-Drafts ................ 475
                                                       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
                                                       family might not make it onto the agenda. It shouldn’t have to; IP infrastructure
       97 RFCs published of which
                                                       should just work. However, I find it hard to believe that at the chief technology
            • 44 standards tracks
                                                       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
                                                       tuned in to the issue? An entirely different and somewhat plausible explanation
       IANA Actions
          (March–June 2008)                            for the difficulty in finding engineers with experience in enterprise-scale IPv6
                                                       deployment is that those engineers are not participating in the IETF. The root
       Processed 1,422 IETF-related
                                                       cause for both of those explanations may be that IP addressing is a typical ISP
         requests of which:
                                                       issue and that engineers at ISPs may be more attuned to IPv4 address comple-
         • 775 Private Enterprise
                                                       tion than are their counterparts in the business enterprises sector.
                                                          These personal musings aside, the IAB is interested in hearing more adoption
         • 66 Port Numbers
                                                       stories, specifically those in which barriers were encountered and overcome. We
         • 67 TRIP ITAD Numbers
                                                       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 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.

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        on top of connections between peers
       Jason Livingood and Rich Woundy
                                                 these chunks may not be the most de-          that are established regardless of the
    provided some technical perspective
                                                 sirable. Stanislav and Eric observed that     underlying network topology. In ad-
    from their vantage point at Comcast,
                                                 efficient choosing of peers could reduce      dition to simply achieving suboptimal
    the cable service provider. Participants
                                                 transit traffic by more than 50 percent.      performance, such networks can lead to
    learned that Internet service providers
    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        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 in-
                                                 crease 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)

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

    “E     ven though Irish is the native language of Ireland, English has become the
           dominant language, just like IP is the dominant language of networking,”
    said Kevin O’Callaghan, Ireland’s leader of Alcatel Ireland, which served as host                  Mirjam Kühne

    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         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
                                                   the problem space, to gauge the inter-      of multiple transport connections and
    TANA BoF
                                                   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.

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
                                                                       retreat was designed as a workshop at       pubp olpi l l a r/do c s /o e c d-te c h n ic a l
     IAB Update                                                        which everyone brought up topics they       -community-memorandum.pdf.
                                                                       wanted to discuss and after which a           The IAB also participated in a techni-
     Following Internet Research Task Force
                                                                       work plan was developed. A discussion       cal forum on the future of the Internet
     (IRTF) chair Aaron Falk’s update cov-
                                                                       on evolution of the IP model, including     Economy, which was organized prior to
     ering recent developments in the IRTF
                                                                       assumptions regarding which IP models       the OECD Ministerial meeting.
     (details on page 33), Internet Architec-
                                                                       are valid and which are not, was led by
     ture Board (IAB) chair Olaf Kolkman                                                                             Olaf reminded the audience that
                                                                       Dave Thaler. A discussion on peer-to-
     gave an update of IAB activities as fol-                                                                      the IAB is responsible for maintaining
                                                                       peer architecture was led by Gonzalo
     lows:                                                                                                         and defining the RFC Editor model,
                                                                       Camarillo. Gregory Lebovitz is leading
        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    The RFC Editor contract will be up for
     ume 3, Issue 3, December 2007). Design
                                                                       of organizational activities. Bert Wijnen   bids in 2009. To guarantee continuity, a
     Choices While Expanding the DNS is
                                                                       stepped down as IEEE 802.1 liaison          comprehensive model is needed. To that
     technically approved, but it needs one
                                                                       and has been replaced by Eric Gray.         end, the RFC Editor function will be
     more round of editorial review before
                                                                       John Klensin has been appointed liaison     split into four functions:
     sending it to the RFC Editor.
                                                                       within ISO/TC46. Lars Eggert is suc-
                                                                       ceeding Mark Twonsley as IESG liaison
                                                                                                                     •	 Independent Stream Approver
                                                                       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)
                                             Photo by Peter Lö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-
     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
                                                                       that will take into account the ITU-T       planned for end of August. More details
       A number of documents are now
                                                                       transport network requirements. The         can be found on the IAB Web site.
     works in progress, including Principles
     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

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

    their particular environment. (See arti-
    cle page 17.)                                 Another new organizational development is the IETF’s involve-
                                                  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-
    munity, and adopted. The RFC series           Internet in a global economy.
    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
                                                    Jonne also announced that during           technical knowledge needed to produce
    archives to identify them.
                                                  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
    documents. Even though a licence for
    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                                                  the practice of having the IESG make
                                                  •	 Process-oriented topics: bringing
    status of the IETF and announced hosts                                                     decisions during telephone chats and via
                                                     new work into the IETF and docu-
    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
    project and take place in Hiroshima,             The Edu team also organizes topical                          Continued on next page
    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
                                                                                                                                           Photo by Peter Löthberg

                                                  what the tutorials should cover: Should
    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
                                                  cific technologies? Should there also be
    slightly under budget for 2008, and the                                                    IETF 72 participants meet in hotel lobby.

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-
                                                                                                                 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
                                                                                                                 one can have NAT-to-NAT peer-
                                                              Photo by Peter Löthberg

                                                                   pant asked what the
                                                                   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
                                                                   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
                                                                                                                                                          Photo by Peter Lö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 b e s t a nd a rd i z e d
    IETF consider extending the meetings and then gradu-
    to Friday afternoon. Most of those who ally made into the                               Shuttle takes IETF participants to Dublin.

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

    Real-Time Text
    By Arnoud van Wijk

    W        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
    time1; that means that we send and receive audio and video continuously as we com-
    municate, 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-
    um. We use it to read newspapers and         ately to the receiving person(s). This al-    To the deaf or hard of hearing, real-time
                                                                                               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, in-     for 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
    Real-time text works by sending and re-                                                    disabilities than by those who have
    ceiving text on a character-by-character                                                   them. On phone calls, people can type
                                                    Real-time text uses the standard ses-      in phone numbers, addresses, names,
    basis. The characters are sent immedi-
                                                 sion initiation protocol (SIP) (RFC
    ately (within a fraction of a second) once                                                                    Continued on next page

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
     elderly parent, for example, a person can                                                  IP networks. Authorities are already
                                                   that will enable implementers to test
     use text to supplement voice to make                                                       pushing for this in the European Union
                                                   how well their solutions comply with the
     sure important information has been                                                        and the United States.
                                                   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
     can provide an almost instant list of the                                                  References
                                                   will act as an educator on related issues.
     choices visually so users can immediately                                                  1. The International Telecommunica-
     read and select the number they want to        The Web site of the R3TF is http://
                                                                                                tion Union (ITU) defines real time in
     press. These and a myriad of other uses
                                                                                                ITU-T F.700 Section 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
                                                   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
                                                   ensure that the real-time text proto-        the technique for real-time text described
        Having a single real-time text stand-
                                                   col/service used does interoperate with      in this article, combining existing IETF
     ard that is used everywhere would make
                                                   RFC4103.                                     standards to facilitate text streaming over
     access to communication services easier,
                                                                                                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
                                                                                      , 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-
                                                   puters.                                      and accessibility for people with disabili-
     this is not possible.
                                                                                                ties, edited and coauthored Framework
       The R3TF will promote real-time             •	 Include real-time text in your design     for Real-Time Text over IP Using the
     text as the real-time text standard that      and development of new services, such
                                                                                                Session Initiation Protocol, which the
     most terminals and networks can either        as voice and videoconference services,
                                                                                                IETF recently published as information
     use native or easily interconnect with        answering machine services, call centre
                                                                                                document RFC 5194.
                                                   services, language interpretation servic-

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, licens-
    ing, 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-

                                                                                                                                          Photo by Mirjam Kühne
    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
    law that applies to standards organiza-       a product that implements the standard,        IETF attorney Jorge L. Conteras
    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-
    the IETF are aware of the Dell case and                                                      ten, it is not actually clear who the client
                                                  IJ: What other legal matters do you handle
    a number of more recent cases that have                                                      is. The IETF is more a concept than an
                                                  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
    are fine. If they violate the rules, how-                                                      The IETF Trust is a different legal
                                                  strong desire to release the tools on an
    ever, they risk the loss of patent rights,                                                   entity altogether. It is the custodian
                                                  open-source basis, and I have worked
    just as Dell did.                                                                            of the IPR owned by IETF, including
                                                  with the tools team, the IAOC and
                                                                                                 software code, the IETF trademarks
    IJ: Has the IETF ever been sued under         the IETF Trust to evaluate various ap-
                                                                                                 and logo, written records, and, most im-
    patents?                                      proaches that might satisfy the many
                                                                                                 portant, the RFC series itself.
                                                  constituencies involved with the IETF.
    JLC: No, the IETF has never been sued         For example, certain open-source devel-
    for patent infringement. An SDO like          opers favour the General Public License,                          Continued on next page

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      JLC: I’m chair of the Technical Stan-
     RFCs to the Trust. A number of com-
                                                   to work that is ongoing in an IETF            dardization Committee of the Ameri-
     panies and individual authors have al-
                                                   working group. You can also disclose          can Bar Association’s Section of Science
     ready done that, and we are encouraging
                                                   other people’s patents if you know they       and Technology Law. In that capacity,
     other active IETF participants to follow
                                                   affect the work in a WG. If you know          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?                                                                 For more information about Jorge L.
                                                   ny’s patent would cover all of IPv6. It
     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- 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 /pu blication s /whP u bsLi st .
     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.
     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
                                                   to manage people’s expectations about the     Note: Standards Development Patent
     left their companies, moved on to other
                                                   IETF, is that right?                          Policy Manual can also be found on Google
     projects, or, in some cases, passed away.
     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-

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

                                                                                                  As we engage in IETF activities on
    The Internet and Bandwidth-                                                                the topic—including BoF sessions and,
    Intensive Activities                                                                       eventually, working groups—it’s im-
                                                                                               portant 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
    are 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
       The answer is not simple. From a           index for the purpose of giving prece-
                                                  dence to European sites mirroring the           The long view is that this sort of stretch
    technology perspective, the Internet is
                                                  same files made sense as a way of reduc-     in network demand is normal and, on a
    activity agnostic. Therefore, in principle,
                                                  ing that traffic demand.1                    global level, healthy. By making a net-
    any popular application or service could
                                                                                               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
    networks. Nevertheless, some of the           BoF sessions at IETF 72 in Dublin (see
    issues are exacerbated by the nature of       page 1).                                     1.

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

     IETF 72 Welcomes ISOC Fellows
     By Wendy Rickard

     S    ix technology specialists and researchers from Africa,
          Asia, and South America journeyed to Dublin, Ireland,
     for 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

                                                                                                                                       Photo by Gerard Ross
     spent on working group (WG) mailing lists.
       By all accounts, the fellows benefited    country      code
     considerably from the experience, bring-    top-level domain
     ing with them—and taking away—their         registry    where ISOC Fellowship to the IETF programme fellows and mentors at
     own unique perspectives.                    he develops soft- IETF 72 in Dublin.
                                                 ware written in
     Meet the Fellows
                                                 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,
                                                 friendly and open-minded,” he said. and routing issues. (See page 16.)
       IETF 72 Fellows and Mentors
                                                 “That makes for a very rich environment         Mohamad Dikshie Fauzie conducts
       Alejandro Acosta (Venezuela)
                                                 for developing ideas and to be creative      research in Internet measurement anal-
         Mentor: Elwyn Davies
                                                 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
                                                 of Engineering & Technology (UET),           IPv6 task force, a group consisting of
       Kumar Saurabh (India)
                                                 the largest engineering university in        academics, government representatives,
         Mentor: Hadriel Kaplan
                                                 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

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 rout-       able 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
                                                                        bring the knowl-      educpillar/fellowship/returningfellows.
                                                                        edge he gains to      shtml.
                                                                        the two national
                                                                        universities with
                                                                        which he works        ISOC extends opportunities for organiza-
                                                                                              tions to become sponsors of this important
                                                                  Photo by Gerard Ross

                                                                        closely, as well as
                                                                        to the groups, such   programme. Sponsorship demonstrates a
                                                                        as LACNIC.            commitment to technical capacity building
                                                                                              in less-developed regions and shows support
                                                                        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
                                                tocol. He also works on Session Border

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

                                                                                                meet Prof. David Culler and Samita
     Joining the IETF Fold                                                                      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
     ship 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-

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

    IPv6 Deployment: Lessons from the
    An IETF 72 panel looks at experiences with IPv6 deployment.

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

                                                                                                                                      Photo by Peter Lö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
    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://w w /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          centage of remaining /8s being allocated
       Some content providers are planning
                                                time, more hosts and networks are             is growing steadily each year.
    ahead by readying their content for IPv6
                                                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                                         , 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                                                      receiving this news as Chicken Little
                                                View from the RIRs
    invest more in their IPv6 services and                                                    would—as an indication that the sky is
                                                Mark Kosters, Chief Technology
    infrastructure deployments if the con-                                                    falling—Mark urged us to look at it like
                                                Officer, ARIN
    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

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-
                                                                                                 ganizations, and hosted IPv6 networks
     Both [service and broadband providers] face a bit of a chicken-
                                                                                                 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 bot-
                                                                                                 tom-up. So come join the effort.”

     robust market for titling, brokering, and      RIR Policy Development                       Lessons Learned from IPv6
     owning the land. Likewise, the days of         With IPv4 allocation completion on           Deployment
     IPv4 address “homesteading” are com-           the horizon, the volume of policy work       Alain Durand, Director of Internet Gover-
     ing to an end, and many more stringent         by RIRs on this subject has ballooned.       nance and IPv6 Architecture, Comcast
     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
                                                    In addition to policy and allocations, the   a large-scale allocation is likely to be
     LACNIC have not yet assigned PI IPv6
                                                    RIRs conduct a fair amount of aware-

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

                                                                                                                                       Photo by Peter Löthberg
    IPv6 was easier than expected. Comcast        (e.g., Win95, 98, XP, PlayStations,
    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
    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 in-
                                                  longer possible to get any more IPv4 ad-     frastructure network via a tunnel. The
       For Comcast the problem with IPv6
                                                  dresses. “Following IPv4 completion, if      IPv4 packet would be detunnelled in-
    was not in the networking layers but in
                                                  you give all new customers IPv6 only,        side the ISP network at a large v4-to-v4
    the application and services ecosystem
                                                  with no IPv4 support, then the IPv4-         NAT box, a CGN. That box translates
    around the layers, like their operations
                                                  only devices can’t get out of the home,      the IPv4 packet to a globally routable
    and support, management, billing, and
                                                  and new, IPv6-only devices can’t get         IPv4 address and sends it off to the IPv4
    third-party systems. Not only do many
                                                  to the predominant IPv4-only content         target. Alain refers to this as a dual-
    of those systems lack the required IPv6
                                                  on the Internet.” To counter that hitch,     stack-lite service. (Work on this is oc-
    support, but getting that support is not
                                                  one might add the practice of NATing         curring in the Softwire working group.)
    high on most vendors’ priority lists.
                                                  new customers with overlays of private       The advantage is that the infrastructure
    Adapting the code doesn’t happen over-
                                                  addresses from the RFC 1918 blocks.          itself requires only IPv6 addresses for
    night. It takes implementation, testing,
    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

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                                                             After warning of the CGN issues,
                                                      To illustrate that point, Shin offered
     immediate benefit out of it.” The IETF’s                                                     Shin proceeded to offer a graphical,
                                                   the example of browser connections to
     most successful protocols over the past                                                      time-lapsed, step-by-step progression of
                                                   a Google Maps display of San Francisco
     15 years have been incrementally de-                                                         how an operator might transition to an
                                                   International Airport, an application
     ployable, and that is Alain’s goal for net-                                                  IPv6 network by using a dual-stack-lite
                                                   that employs AJAX technology. One
     works transitioning to IPv6.                                                                 service architecture. This transition plan
                                                   characteristic of AJAX is that it simul-
     A Step-by-Step Transition Plan                taneously makes many discreet HTTP             offers incremental deployment and IPv4
                                                   connections from the host to the server        backward compatibility. The operator
     Shin Miyakawa, Director of IP Technology
     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-             Step two introduces IPv6 on the cus-
     CGN concept has significant and seri-
                                                   dress would serve approximately 2,100          tomer side of the CPE, a client-based
     ous restrictions as well as implications
                                                   hosts. This 30-concurrent-connections          Softwire tunnelling solution from the
     for the Internet’s end-to-end design
                                                   number is for Google Maps only. The            customer’s hosts, and a tunnelling con-
     principle. “The last thing we would want
                                                   NTT        Com-
     is the existence of a CGN to slow IPv6
                                                   munications                             Max    15 Connections
     adoption,” he said. Instead, Shin sug-
                                                   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
                                                   age of 500 open Figure 1: When concurrent connections are reduced, an image may
     CGN component may necessarily limit                              not be able to load appropriately.

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
                                                      What can the IETF do to hasten IPv6       employees. Once others caught wind of
    concentrator and the CPE support v4/v6
                                                   adoption? According to Shin, first is an, they jumped in along-
    dual stack. Once both can run IPv6 na-
                                                   additional IPv4 private address space al-    side Lorenzo and team, and now Gmail
    tively, the operator has no further need
                                                   location for carrier/operator access net-    and News are IPv6 enabled too. They
    for the tunnelling mechanism. This cap-
                                                   work equipment that sits in the IETF’s       built a pilot network and ran the infra-
    tures the attractiveness of the proposed
                                                   internal infrastructure devices, behind a    structure at an IPv6 conference, proving
    transition plan: any of the key pieces—
                                                   CGN. Next would be defining a simple         that it worked.
    PE access concentrator, CPE router,
    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

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
       Lorenzo counselled against the use         denial-of-service attacks, and VRRP
                                                                                               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
                                                                                               for the AirPort Express wireless base
     Start small, and make steady progress . . . . [W]henever possible,
                                                                                               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, stream-
                                                                                               ing 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
                                                  in v4 NAT too,” said Lorenzo. Like           the customer will not be able to access
        Lorenzo’s IPv6 product feature/ca-
                                                  Shin, Lorenzo doesn’t like NATs—             IPv6 content and therefore will not pur-
     pability wish list included MPLS traf-
                                                  or the NAT mechanisms in NAT-PT.             chase IPv6 connectivity. If the OS is not
     fic engineering, mature load balancing,
                                                  However, being an IPv6 champion, he          v6 ready, then apps can’t be either. In-
     IPv4-style multihoming, and hardware
                                                  feels that incremental transition mecha-     centives must exist for all of the players.
     processing for both 6to4 and extension
                                                  nisms are key to hastened adoption. “If      Apple’s incentive was the so-called cool-
     header filtering. Lorenzo notes that
                                                  we want to reclaim the end-to-end prin-      ness factor of IPv6, so now Apple’s OS,
     today they have to drop at the edge of
                                                  ciple, then we must do it with IPv6.”        Apple’s browser, and most of Apple’s
     their network every IPv6 packet that is
                                                  And in order to do that, Lorenzo called      networking apps support it. “Now we
     not clearly TCP, UDP or ICMP due
                                                  for a bare-bones standard that addresses     must find compelling incentives for the
     to a lack of hardware filtering for ex-
                                                  a v6 host connecting to a v4 server. This    other three pieces to support v6,” en-
     tension headers. IPv6-style multiple-
                                                  would require a DNS application layer        couraged Stuart. “Or, at the very least,
     address multihoming has not worked
                                                  gateway. The focus should be on net-         make sure there are no disincentives.”
     well. Failovers break TCP connections.
     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

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
      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

      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.

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-
                                                                                             rency and asynchrony. Yes, these new
     content (such as Web sites).
                                                                                             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
     sites do not respond to an AAAA query,        Introduction Email from the IAB
     or they send back a mangled, malformed
     response. The connection sequence             IAB’s follow up email
     blocks are waiting for an answer that
     isn’t coming. The user perceives this as
                                                   Audio stream archive
     application slowness, which started oc-
     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-
     peared when the ISP started offering
     IPv6 service, the issue landed in the 
     ISPs’ laps. This is bad for the industry
     because both the customer and the ISP         One hypothetical model of an address allocation timeline
     get a bad impression about IPv6. These
     thorny disincentives must be removed if
     we are to hasten deployment.                  Related drafts
        Apple’s implementation now disas-
     sociates the IPv4 and IPv6 tracks. The          draft-shirasaki-shared-adrs-00.txt
     tracks perform the AAAA and A que-              draft-ietf-v6ops-cpe-simple-security-02
     ries in parallel, and they try the IPv4

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

                                                                                              an IP packet’s destination address needs
     IPv6 Transition at IETF 72                                                               to have meaningful context at all points
     By Geoff Huston                                                                          in the network. IP itself is a connec-
                                                                                              tionless datagram protocol, without any

     T     he developmental work of the Internet Engineering Task Force (IETF) on
           IPv6 has, from the outset, included the study of the particular issues associ-
     ated with transition to IPv6. The first effort to explore the transition space was at
                                                                                              form of capability negotiation. Its also a
                                                                                              very challenging exercise to equip a net-
                                                                                              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-
    tive until IETF 55 in mid-2002, when
                                                  of transition to IPv6, including the SOFTWIRE, BEHAVE, and
    the baton was again passed—this time          INTAREA working groups, in addition to V6OPS.
    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-
                                                  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
                                                  of BGP, so that the overall transition of   other words, a “complete” deployment of
    Backwards Compatibility
                                                  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-
                                                  tinct from a hop-by-hop protocol, and                          Continued on next page

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
                                                     This approach assumes that all parties     any such commonality of purpose and
     an extended period. This was termed
                                                  are equally motivated to undertake this       a vision of a longer-term outcome is ex-
     the dual-stack transition approach. This
                                                  transition, and that each party will do       tremely challenging to sustain in the face
     mode of progressive shift of the elements
                                                  so as quickly as possible. It also assumes    of shorter-term considerations.
     of the Internet to a dual-stack opera-
     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-
                                                                                                comes: Tunnelling
                                                                                   However,        The initial refinement to this original
                                                                                   any such     transition model, explored in the NG-
                                                                                   m a j o r    TRANS working group, was intended
                                 IPv4          IPv6                                relative     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
                                                                                   per for-     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

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 at-
    development of a number of approaches        tempts a fully meshed
    to IPv6 transition that relied on tun-       interconnection of the Figure 3. Transition Using Tunnels.
    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-
                                                                              nal     IPv6 ates the prefix and tunnels over the wide
    Figure 2. IPv6 in IPv4 Tunnelling.
                                                                              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-
    fic over IPv6, but perhaps that’s getting    ure its end of the tunnel.
                                                                               Figure 4. 6to4 Tunnelling.
    well ahead of ourselves right now (see       All IPv6 packets between
    Figure 3).                                                                                                  Continued on next page

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                               early adopters of dual stack? Behind all
     of the STUN ac-                                                                                               of the transition scenarios so far lies the


     tive probing ap-

                                                                                                                   assumption that IPv4 and IPv6 sup-
     proach to deter-               IPv4 Network
                                                                                                                   port distinct universes of connectivity.
                                                       TEREDO  7
                                                                                 IPv6 Network
     mine the type of                                  SERVER
                                                           6                                                       However, both protocols present much
     NAT, and uses                                         1
                                                      1. Teredo ICMPv6 Echo Request from Teredo Client to Server
                                                                                                                   the same set of functions to the upper-
     concepts of “cli-
                                                      2. Forwarded IMCPv6 Echo Request from Server to Host
                                                      3. IMCPv6 Echo Reply from Host to Relay                      level transport protocols, and the header
                                                      4. Teredo Bubble from Relay to Server
     ents,” “servers,”                                5. Teredo Bubble from Server to Client
                                                      6. Teredo Bubble from Client to Relay
                                                                                                                   fields of the protocol are similar. Just
     and “relays.” A                                  7. Forwarded Teredo ICMPv6 Echo Reply from Relay to Client
                                                      8. Ini�al Packet Teredo-Tunnelled from Client to Relay       how bad is this backward incompatibil-
                                  Teredo Client       9. Forwarded Ini�al Packet from Relay to host
     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-                          Probably not impossible, but it would
        The tunnelling protocol used by Te-
                                                 lenging to diagnose. The issue of Inter-                          go well beyond the conventional mode
     redo is not the simple IPv6-in-IPv4 pro-
                                                 net Control Message Protocol (ICMP)                               of packet protocol header manipulation
     tocol 41 used by 6to4. IPv4 NATs are
                                                 treatment within tunnels is a good                                and would call upon protocol header
     sensitive to the transport protocol and
                                                 example, where a return ICMP error                                translation, cross-protocol NAT bind-
     generally pass only Transmission Con-
                                                 notice is sent not to the original source                         ings, DNS manipulation, and various
     trol Protocol (TCP) and User Datagram
                                                 host, as intended, but to the tunnel in-                          forms of application level gateways.
     Protocol (UDP) transport protocols. In
                                                 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-

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
                                                  the collective long-term desirable out-       at present, given that IPv6 today still
    IPv4 Exhaustion and IPv6
                                                  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                                                         IPv4 connectivity to the same service
                                                  keeping IPv4 operating.
    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                                                  use of IPv6 link-local addressing. The
                                                  In IETF 72, the issues that we have
    IPv4 addresses to address the entire In-                                                    presentation also looked at a dataflow
                                                  been confronting, with this combina-
    ternet across the entire transition phase                                                   model of connection establishment in
                                                  tion of dual-stack transition to IPv6 and
    and that the event that IPv6 was pri-                                                       a dual-stack environment, where both
                                                  IPv4 address depletion, were discussed
    marily intended to avert, the exhaustion                                                    IPv4 and IPv6 connections are initiated
                                                  in a number of working groups, as well
    of the supply IPv4 addresses from the                                                       in parallel, and the first path to suc-
                                                  as the Technical Plenary session. What
    unallocated pool, would not occur dur-                                                      cessfully complete the DNS and initial
                                                  follows is a brief summary of the relevant
    ing the transition process.                                                                 packet exchange to complete the con-
                                                  activity in each of those working groups.
       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
    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-        metrics of address Figure 6. A Dataflow Model of Protocol Selection [Adapted from:
                                                                      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

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-                                                     is provided at the interior boundary of
                                                       The BEHAVE working group started
     tion. The basic problem being addressed                                                     an Internet service provider (ISP) net-
                                                    out with a charter to provide some stan-
     by that effort can be envisaged in a                                                        work in conjunction with NATs being
                                                    dard specifications for the behaviour
     scenario where there are no more IPv4                                                       performed at the CPE edge.
                                                    of IPv4 to IPv4 NAT units, but in re-
     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 po-
                                                    sition 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 ef-
     fort concerns the evaluation of modified
     NAT behaviour, where the conventional
     binding space of a vector of inner and
     outer addresses and ports and an associ-
     ated 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

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

                                                                                              not unusual for protocols designed in
    IETF Response to the Kaminsky                                                             the early 1980s. Any protocol will likely
    DNS Vulnerability                                                                         have security problems, and this is es-
                                                                                              pecially true for one that was designed
    By Shane Kerr
                                                                                              before security was a concern—and for

    I  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.
    referred 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
                                                  an attacker to put incorrect data into         hosts
    There are descriptions of the attack on
    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)
    It can be found at http://www.unix-           clever, since almost every piece of the
                                                                                              •	 Information leaks (exposing cache          attack has been known for a long time.
                                                                                                 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                                                         priate data into the cache)
                                                  pected way.
    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   The foregoing views do not necessarily
    case, it’s a call for reservation of IPv4
                                                  tools and protocol mechanisms that need     represent the views or positions of either
    unicast address space to be used within
                                                  to be fielded into production networks      the Asia Pacific Network Information
    a carrier’s infrastructure for bridging the
                                                  within a very compressed time frame;        Centre or the Internet Society.
    gap between the carrier-grade NAT at
                                                  and having every vendor, every network
    the boundary of the carrier’s network
                                                  operator, and every operating system        Geoff Huston is chief scientist at APNIC,
    and the CPE devices at the boundary to
                                                  suppler devise distinct approaches runs     the Regional Internet Registry serving the
    the customer. Given the often protract-
                                                  the risk of making the situation more       Asia Pacific region. He holds both a B.Sc.
    ed debates such calls for reservation of
                                                  difficult than it would otherwise be.       and an M.Sc. in computer science from
    address space often engender—and the
    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
    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

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

     IETF Response to the Kaminsky DNS              an ongoing group dedicated to non-        both in labs and “in the wild”), and links
     Vulnerability, continued from page 31
                                                    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-      standardized. A number of proposals on
     1999: After early implementation, it
                                                     ing group chartered for a specific       the list were discussed, as were a number
     was determined that RFC 2065 needed
                                                     goal, but in practice it is an ongo-     of nonproposals: for instance, DJ Bern-
     work, so RFC 2535 was created to fix
                                                     ing group that has been active since     stein has an alternative to DNSSEC that
     the flaws (see Appendix B of RFC 2535
                                                     1999: changes to the DNS protocol,       was mentioned, but djb is unlikely to put
     for the full list of the differences).
                                                     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
     including extreme difficulty getting                                                     ways to make it even more difficult for
                                                     Both groups recently have done secu-
     secret-key signing material to and from                                                  an attacker to spoof packets. Another
                                                  rity-related work. For example, draft-
     a zone parent. In response, a set of three                                               common theme was for recursive serv-
                                                  ietf-dnsop-reflectors-are-evil-06.txt has
     RFCs were published with the new                                                         ers to detect when someone was trying
                                                  been approved for publication as best
     DNS Security Extensions (DNSSEC)                                                         to spoof traffic and therefore, put the
                                                  current practices, and work on DNSSEC
     standards: RFC 4033, RFC 4034, and                                                       resolver into a mode that makes spoofs
                                                  trust anchor configuration and mainte-
     RFC 4035. RFC 4033 was the first time                                                    more difficult.
                                                  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 (dra ft-ietf-dnsext-forger y        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                                                      and there have been rumours that the
                                                  Until 7 August 2008, when the details
     (RFC 2845) is a way to authenticate                                                      root zone will be signed soon as a result
                                                  were made public, there were IETF par-
     DNS operations by using a shared se-                                                     of the attack. However, no changes are
                                                  ticipants who had inside knowledge of
     cret, a procedure that has been widely                                                   expected in the DNSSEC protocols.
                                                  the Kaminsky attack. There also were
                                                  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
                                                     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    of good information and discussion en-
     The IETF currently has two working
                                                  exploit (estimating how long a typical      sued as a result of the attack. It is our
     groups (WGs) dedicated to DNS is-
                                                  exploit would take), links to and discus-   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.

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 un-
                                        wanted traffic mitigations and another one on network virtualization.
                                          During IETF 72, four RGs met. Following is a summary of recent develop-
                                        ments as well as of developments reported by RGs during the IETF 72 technical

                                        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

                                        Delay-Tolerant Networking Research Group (dtnrg)
                                        There are currently three drafts in the RFC Editor queue on delay-tolerant net-
                                        working (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

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 is-
     sues 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 for-
     mat 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 sched-
     uled 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.

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
                                    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 pub-
                                    lished 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-
                                    For more information about the Internet Research Task Force, visit http://www.irtf.

                          Recent IESG Document and Protocol Actions
               A full list of recent IESG Document and Protocol Actions can be found at

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
                                Register now for

                               IETF 73                                           Managing Editor
                                                                                  Mirjam Kühne
                              16–21 November 2008
                              Minneapolis, MN, USA                               Associate Editor
                                  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
                                                                              Find us on the Web at
           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

Shared By: