Publications 

Full issue in PDF format

The full IETF Journal, Volume 1, issue 2 (Winter 2005/2006) is available here for download in PDF format (284KB).

Posted: Wednesday, January 18th, 2006

New agreement marks major milestone in IETF Administrative Restructuring

By Peter Godwin - Editor, IETF Journal

After nearly twenty years of existence, the Internet Engineering Task Force has assumed oversight over the services that support the operations of the world’s leading Internet standards development group.

A new agreement with NeuStar Secretariat Services LLC marks a major milestone in efforts to ensure that the IETF administrative support infrastructure will meet the future needs of the expanding IETF community.

The agreement (which was signed on December 15, 2005) was the outcome of extensive discussions and consultations between the IETF community and the IETF Administrative Support Activity (IASA) - a group created in April 2005 to examine ways of improving the IETF’s administrative operations in support of the IETF standards process and technical activities. (more…)

Posted: Wednesday, January 18th, 2006

IETF64 Review: Plenary Sessions

By Mirjam Kühne, ISOC

The IETF plenary was organised in two parts: on Wednesday evening more administrative and operational aspects of the IETF were presented and discussed, such as reports from the IETF chair and the IESG, the IETF Administrative Director (IAD) and the IETF Administrative Oversight Committee (IAOC), RFC editor and IANA and finally the Process and Tools Team (PROTO). On Thursday the Technical Plenary session took place with a technical presentation of the Crypto Forum Research Group and reports from the IAB and the IRTF. (more…)

Posted: Wednesday, January 18th, 2006

IETF64 Review: Routing

By Geoff Huston

The following is a review of the current status of the working groups that either met at IETF64 or whose status was reported at the Routing Area meeting during the week of IETF64 in November 2005. This is of course a set of personal opinions and perspectives rather than an official report of the IETF.

Routing Area Working Group (rtgwg)

Alex Zinin, one of the Area Directors of the Routing Area announced his intention to step down from this role in March 2006, at the expiration of his current term as AD. Alex has served for four years as an AD for the Routing Area of the IETF and has established a careful consultative style as an Area Director. I’d like to simply say here a personal thanks to Alex for his time and energy over the past four years.

RFC1264bis - a review of Routing Protocol Standardization Criteria. A number of changes are being proposed here, including turning the protocol analysis documentation, which was a mandatory requirement for Proposed or Draft Standard protocol specifications, into a chartered step if it is felt that such an analysis is a requirement for the protocol being developed. The experience with BGP was that this particular analysis was an exercise required for the IETF standards process, but was not felt to be a useful document in its own right. The current proposal is to either place the preparation of this document into the charter as an explicit Working Group deliverable, or do not prepare such an analysis. Also within scope of this review is a clarification of the independence of the two implementations from the proposed specification. (more…)

Posted: Wednesday, January 18th, 2006

IETF64 Review: DNS

By Jaap Akkerhuis and Peter Koch

The DNS ext working group started with business as usual - a run down of the status of various Internet Drafts (ID). For a complete list, see the agenda at: http://www3.ietf.org/proceedings/05nov/agenda/dnsext.htm.

Draft minutes of the working group are available here: http://www3.ietf.org/proceedings/05nov/minutes/dnsext.txt.

The mDNS ID returned to the working group. The chairs post a summary about the comments to the mailing list with a request for review.

DNS Testing

The Tahi group reported on their first interoperability testing effort. They tested one DNS client and found some bugs in the client and some bugs in the testing tool. They did not find any issues with the basic DNS specifications. The next scheduled TAHI testing event is at the end of January 2006.

NSEC3 Update

The definition of the NSEC3 records is progressing rapidly. Among the things that got discussed was whether a new record type might be needed for storing meta data. This would help to prevent collisions of hash names and legitimate zone names. A decision about this is delayed until experience is gathered from real implementations. Such experiments should take place before the document is advanced. A testing and engineering workshop might be held at the beginning of 2006.

The Big Trust Anchor Management debate

The way the trust anchor for DNSSEC in the resolver is managed is not defined, but this needs to be done. Doing things manually is error prone so people are looking into ways for automating this process. Currently there are four proposals - with IDs already written for three of them. There are various intellectual property claims to a couple of these ideas, but the strength of each individual claim is not clear. During the discussion it became evident that all solutions are struggling with at least two different problems: Initial key distribution and key roll over. The need is felt for a short requirements document. Some volunteers have stepped forward to write this within a short time frame (three months).

The Sky is falling!

The crypto algorithms used in DNSSEC come from standard sources. One of these, the SHA-1 is under attack and some weaknesses have been found. The way that DNSSEC uses SHA-1 is not affected by this weakness, so the sky is not really falling. Since there is not yet widespread deployment of DNSSEC, it is better to replace SHA-1 by SHA-256 now, just in case SHA-1 gets even more tainted in future. For this purpose a new ID will be written which will make SHA-256 mandatory to implement.

Workload Review

The chairs suggested that for a working group document to advance or to be accepted at least four or five people should have committed to review. If not, it will be dropped by the group and authors will have to do a personal submission. The room hummed consensus.

DNSOP

The WG has a new co-chair, Peter Koch, replacing David Meyer. The participants agreed to work on the document backlog one-by-one to significantly reduce the number of open and close-to-finished documents before the next meeting in Dallas. This is why no new work was adopted as WG items. For a list of current work items, see http://www3.ietf.org/proceedings/05nov/agenda/dnsop.txt

6to4 Reverse DNS Delegation

The (expired) draft-huston-6to4-reverse-dns-03.txt describes a potential mechanism for entering a description of DNS servers which provide “reverse lookup” of 6to4 addresses into the 6to4 reverse zone file and is asked by an IAB IPv6 ad-hoc to be published by the DNSOP WG. After some discussion whether the WG should publish other people’s work, it was agreed to do so. Some reviewers stepped forward.

Cross-WG review

Other WGs (e.g. ENUM, GEOPRIV, ECRIT) are increasingly asking for review of their drafts buy DNSOP (and DNSEXT), often via the IESG. As an example, the ENUM WG feels the need for clarification about ENDS(0) and volunteers were found to write such a document. Here the question was also how to communicate to both vendors and network operators that EDNS0 is a sheer necessity in today’s DNS operations, particularly needed for ENUM and DNSSEC, but considered non-optional in the general case.

The DNSOP WG minutes are available at http://www3.ietf.org/proceedings/05nov/dnsop.html

New work: AS 112 in a box

Queries to domains such as 168.192.in-addr.arpa or 8.e.f.ip6.arpa leak all over the Internet and end up at the root-servers. There is a network of volunteers (see http://www.as112.net/), operating (anycasted) domain name servers trying to answer these queries, before they hit the root servers. For a description see the http://public.as112.net/ website. The new work proposes that resolvers themselves should directly return authoritative answers for special domains.

Posted: Wednesday, January 18th, 2006

IETF64 Review: IPv6

By Mikael Lind

The 64th IETF was a big milestone for IPv6. It marked the end of the IPv6 working group and hopefully the beginning of large scale adoption of IPv6. It was concluded that this would be the last face-to-face meeting of the IPv6 WG but that the working group should stay open until all unfinished work is done. There are no big items left on the charter although several documents are currently being revised (e.g. address selection RFC 3484). The largest remaining task is perhaps the shepherding of the core specifications to Internet standard. During its existence the IPv6 working group has produced 69 RFCs and it still has 11 drafts on their way to RFC.

Neighbor discovery

RFC2461bis is one of the documents underway and the last remaining piece was the issue about the meaning of the ‘Managed address configuration’ flag and the ‘Other configuration’ flag. The accepted solution at the meeting was to say that M flag indicates a client should use DHCPv6 for all configuration information and only use DHCPv6lite if just the O bit is set. Related to the management flag discussion was the issue when an ISP wants to force a user to use a specific address. Even if the management bit is set by a router there is no guarantee that the client doesn’t use any other address such as privacy addresses. This will create problems with access control since the client address isn’t always predictable. One solution would be not to include a prefix in the router advertisements.

IPv6 Operations

There’s no lack of operational issues related to IPv6. One big task at the meeting was to figure out what to take up as work within the WG and what to send off to other groups. Documents that already are WG items and now starting to be finalized are Broadband deployment scenarios, Enterprise Analysis, and Network architecture protection. The Broadband deployment document will ship without an updated cable networks section since the new cable network specification isn’t quite ready. The Enterprise analysis will just have a small rewording regarding DSTM before moving to the IESG. One document that was taken up as a new WG item was IPv6 Implications for TCP/UDP Port Scanning. There are many other interesting documents in the working group and the work would definitely gain from a wide community review since all operational input is useful.

Softwires

At IETF63, Softwires was a BoF but it has been very active and has held an interim meeting to finalize the problem statement. Softwires was approved as WG during IETF64 and will now start working on flexible tunneling mechanisms that work in two different scenarios; the first being hubs and spokes and the second mesh. These more or less represent end host and core network cases. One of the important goals is to make the mechanisms independent of the tunnelling protocol so that it can be optimized to different networks and provide integrity when needed.

IPv6 over IEEE 802.16(e) Networks

This was a BoF to start a working group that would work with IPv6 over 802.16 networks or WiMax. There was some confusion as to what was the actual problem since it is possible to run IPv6 over 802.16 today. The statement was that the functions in 802.16 networks make IPv6 perform poorly and that there has to be additional work done. One question many asked was if this shouldn’t be something that should be fixed in the 802.16 standard instead of in the IETF. In the end there was no clear consensus on how to proceed and there will not be a WG created right now.

Posted: Wednesday, January 18th, 2006

IETF64 Review: SHIM6

By Geoff Huston

It’s always handy in a working group to have had some other working group do all the heavy lifting in terms of defining the problem, sorting out requirements, looking at the threats and documenting the basic architectural issues. In the case of SHIM6 this includes working through a relatively hefty collection of candidate proposals and identifying an approach that appears to offer the most promise. In the case of SHIM6, much of the work was already undertaken by its predecessor, the MULTI6 working group, which looked at the more general topic of multi-homing in IPv6.

So to briefly recap here over some well covered territory, when the scaling issues with the Internet were examined in the early 1990’s, two basic problems were identified. The first was that the IP environment was indeed running out of addresses, and secondly that the routing space was running out of capacity. The interim approach was to adopt a new address architecture in IPv4 that removed the ‘class-based’ semantics of an address, and instead used an explicitly specified prefix length for all address prefixes. The longer term approach was to work on a protocol specification that extended the address space significantly. The approach adopted by the IETF in this new protocol was a relatively conservative one that extended the address space from 32 to 128 bits, but made no other basic changes to the IP architecture. So the question remained on the table: how do you solve the routing capacity problem in IPv6? (more…)

Posted: Wednesday, January 18th, 2006

IETF64 Review: Security

By Eric Rescorla

The buzz in the Security Area at IETF 64 was all about hash functions. Hash functions-in particular MD5 and SHA-1-are a key part of nearly every IETF security protocol, so it was big news in 2004 when Wang et al. announced a practical attack on MD5 (http://eprint.iacr.org/2004/199.pdf) and even bigger news in February 2005 when it was announced that the security level of SHA-1 was substantially less than its design goal of 80 bits (http://theory.csail.mit.edu/~yiqun/shanote.pdf). Improved attacks have since lowered the security level of SHA-1 to 63 bits, just inside the range of what’s practical. (more…)

Posted: Wednesday, January 18th, 2006

IETF64 Review: Mobility and Wireless

By James Kempf

IETF64 saw the establishment of two new working groups related to mobility and wireless:

MONAMI6 - working on a problem statement and standards track specifications addressing issues associated with the simultaneous use of multiple addresses for mobile hosts using Mobile IPv6 or mobile routers using NEMO Basic Support.

AUTOCONF - working to standardize mechanisms by which ad hoc network nodes can configure locally or globally routable IPv6 addresses.

In addition, there were BoFs related to mobility and wireless:

NETLMM - second BoF on network-based, localized mobility management;

16NG - discussed 802.16 wireless link architectures and work needed to run IPv6 over 802.16;

EMU - standardizing Extensible Authentication Protocol (EAP) methods.

This article will discuss the results of the first meeting of the AUTOCONF working group and progress in the DNA (Detecting Network Attachment) working group. Both working groups are in the Internet Area. (more…)

Posted: Wednesday, January 18th, 2006

IETF64 Review: Internationalized Email and Extensions (IEE)

By Marcos Sanz

More than one and a half years have gone since the last Internationalizing Email Address BoF, which took place at the IETF 59 in Seoul, and apparently the time has now come at the IETF 64 for a working group to be formed and to take a stab at the issue of fully internationalized email addresses. The biggest push for this work comes from IETFer colleagues in China, Japan and Korea. And not without reason: imagine you have to transliterate your names from Hangul or Kanji into ASCII for most of the email addresses you type. This is not only a cumbersome and alienating process, but also an error-prone one. On top of that consider, you only would have to do that for the left hand side of the ‘@’ character, since the right hand side of the address, the domain names, are already internationalized by the IDNA standard (RFC 3490). Now, how incoherent is this current situation? (more…)

Posted: Wednesday, January 18th, 2006

IETF64 Review: New ‘Birds of a Feather’ (BoF) Meetings

Descriptions and agendas for all BoF meetings can be found at http://www.ietf.org/meetings/past.meetings.html (more…)

Posted: Wednesday, January 18th, 2006

News from the IAB

By Leslie Daigle, IAB Chair

The IAB has to fulfill a number of roles and responsibilities, described in RFC2850 (BCP39). In the light of the current NomCom cycle (looking for next year’s IAB members) this issue’s IAB update includes additional material elaborating the broad range of those responsibilities.

First, how are IAB members selected? Candidates for the IAB are selected by the IETF NomCom except for Ex-Officio members (IRTF chair and the IAB Executive Director) and Liaison members (ISOC, RFC Editor and IESG). Every year, the IAB elects a chair from within its membership. (more…)

Posted: Wednesday, January 18th, 2006

News from the IRTF

By Aaron Falk, IRTF Chair

As reported at the last IETF, the IRTF is reaching out to the research community. In order to attract more researchers to actively work in the IRTF, an article was published in the ACM Computer Communication Review:

http://www.acm.org/sigs/sigcomm/ccr/archive/2005/october/p69-falk.pdf

In the meantime two new Research Groups have been created:

Transport Modelling (TMRG)

This Research Group will develop drafts on how to evaluate congestion control mechanisms and simulation & testbed scenarios. It is further planning to produce documents on best current practices and admission control mechanisms. Sally Floyd will be chairing the group.

Internet Congestion Control (ICCRG)

The ICC Research Group is chaired by Srinivasan Keshav and Mark Handley and is extected to work on a roadmap on congestion control. (more…)

Posted: Wednesday, January 18th, 2006

News from the IAOC and IAD

By Lucy Lynch and Ray Pelletier

Among the most significant tasks the IAOC has been undertaking recently are negotiating terms of the IETF Trust, establishing contracts with service organisations and developing a budget for the following years.

Substantial agreement has been reached with both CNRI and ISOC on the founding document for an IETF Trust. The IETF Trust is a private legal construct (in this case established under the laws of Virginia, USA) allowing assets (in this case, intellectual property rights and other property) to be held and administered for the benefit of the IETF and hence the Internet Standards process.

Upon signing, procedures which will bind the Trustees to the same conditions for Review and Appeal as those applied to the IAOC in BCP 101 will be enacted. Both, CNRI and ISOC will put any currently held IETF related IPR into the IETF Trust at initial signing. (more…)

Posted: Wednesday, January 18th, 2006

News from the IETF Tools Team

By Mirjam Kühne, ISOC

The purpose of the IETF Tools Team is to provide IETF feedback and guidance during the development of software tools to support various parts of IETF activities.

Henrik Levkowetz is chair of the tools team and is putting a lot of effort into this activity. See http://tools.ietf.org/members for a full list of team members.

The first tool the team has considered is an Internet Draft (ID) submission tool. With this in place, other tools will follow, as listed in the milestones on http://tools.ietf.org/charter-page

It is not the team’s task to do the actual development - however, the team understands the tool development process, and has the ability to formulate and communicate the IETF’s needs with respect to the individual tools. It is also not prohibited for team members to actively develop tool implementations. (more…)

Posted: Wednesday, January 18th, 2006

Reflections on Architecture

By Pekka Nikander

I happen to have an architect’s mind. Looking at the network of today, I strongly feel the pain of the current architecture’s cracking and squeaking. Consequently, I believe that we - the wider IETF community responsible for Internet technology - need to re-think the architecture. We need to find a way to re-create the core of the Internet in a way that leads to a new era of innovation and intellectual prosperity. The highlight of my IETF64 meeting in Vancouver was that I started to see signs of interest and activity in the broader community to pursue such a goal.

Thinking about the architecture is not easy. The existing, real, out-there Internet architecture is no more the simple one that the founders designed it to be and that many of us wish it still was. We all know that. What we perhaps don’t consider very often is the fact that there are huge asset values embedded in various parts of the network. As the slower-than-expected migration to IPv6 has amply demonstrated, some parts of the current Internet are painfully hard to change. This makes any long-term architectural thinking and planning difficult. (more…)

Posted: Wednesday, January 18th, 2006

Calendar

Spring 2006 - 65th IETF

March 19-24, 2006
Host: Nokia
Location: Dallas, Texas

Summer 2006 - 66th IETF

July 9-14, 2006
Host: TBD
Location: TBD

Autumn 2006 - 67th IETF

November 5-10, 2006
Host: TBD
Location TBD

Spring 2007 - 68th IETF

March 18-23, 2007
Host: TBD
Location: TBD

Summer 2007 - 69th IETF

July 22-27, 2007
Host: TBD
Location: TBD

Autumn 2007 - 70th IETF

December 2-7, 2007
Host: TBD
Location: TBD

Posted: Wednesday, January 18th, 2006

Recent IESG Document and Protocol Actions

Listing of recent IESG Document and Protocol Actions (more…)

Posted: Wednesday, May 31st, 2006