[Editors Note: While the following report provides a high-level overview of all working groups in the Internet area, some of them are discussed in more detail in the reports following this one.]
In this article I’d like to provide a brief run-down of the status of those Working Groups in the Internet Area that met at IETF 65 in March 2006, looking at the major items of interest that the WG is focussed on.
This is not an official report, by the way, and I confess at the outset that I did not manage to attend all of these WG sessions at IETF 65. Much of the material here is based on the extensive reporting that the IETF produces, including the proceedings, logs of text sessions and the audio archives of the meeting.
The Internet Area of the IETF sits in a position similar to that of the Internet Protocol layer in the traditional stacked layer of network models: between transport protocols and the underlying media. The “conventional” activities of this Area include standardization of IP adaptation layers (IP over foo), as well as a number of network attachment protocols and various forms of IP-specific protocols. For many years one of the major areas of activity in this area was the IPv6 WG.
IPv6 over Low power WPAN (6lowpan)
This WG is an example of the IP adaptation standardization role undertaken by the Internet Area – in this case the underlying media is the IEEE 802.15.4 class of networks, which includes a set of wide area low power wireless access systems. This WG includes the conventional agenda of IP adaptation interfacing, including framing, address generation and header compression specification. The WG also has the latitude to look at more innovative approaches to adaptation that make use of ad-hoc networks based on the MANET approach. The frame formats, address acquisition and header compression schemes have been documented in a 6lowpan draft which appears to be in its final stages in the WG review cycle (draft-ietf-6lowpan-format-02.txt). The WG is now looking at re-chartering with an intended focus on neighbour discovery, stateful header compression, recommendations for applications, meshed routing and security considerations. At IETF 65 the WG considered proposals for mesh routing, ad-hoc on demand distance vector routing, neighbour discovery and serial forwarding. It appears likely that the rechartering will proceed in the coming months.
Ad-Hoc Network Autoconfiguration (autoconf)
The autoconf WG is intended to standardize mechanisms to be used by ad-hoc (self-configuring) nodes for obtaining unique routeable addresses. Such ad-hoc nodes would be capable of supporting the MANET routing protocols for multi-hop communications. The WG is chartered to produce a “MANET architecture” and an auto-configuration mechanism. The WG is currently working on the MANET architecture document, as well as the problem statement documents for auto-configuration, so at this stage the WG is still in its initial phase. This is part of a larger effort to bring IPv6 standards into the realm of reliable self-configuration in mobile environments that may utilize various forms of ad-hoc connections to build up connectivity services. The WG was established just prior to IETF 64, so the progress to date has been noteworthy.
Dynamic Host Configuration (dhc)
The Dynamic Host Configuration Protocol (DHCP) is now a very well-established protocol with extremely broad deployment. DHCPv4 is a Draft Standard, and DHCPv6 is a Proposed Standard. This WG is, in effect, a protocol maintenance WG, maintaining oversight on proposed DHCP options and extensions in a manner that is consistent with the core DHCP specification, avoiding instances of option and extension clashes and duplication. Current WG activities include security and authentication, rigorous analysis of the specification, operation of DHCP in dual-stacked IPv4/IPv6 contexts and dynamic updates. The WG is a well established one with a very sizeable list of already published RFCs. The current work at IETF 65 was the consideration of a number of DHCP option proposals, namely for a timezone option for DHCPv6, emergency dial string option, 802.21 information service option, PANA authentication agent option, service override option, lease query option, and passive Duplicate Address Detection (DAD). The WG also considered mixed DHCPv4 and DHCPv6 environments and possible operational issues that could arise.
Detecting Network Attachment (dna)
As pointed out in the dna WG charter: “The current IPv6 stateless and stateful autoconfiguration procedures may take a fairly long time due to delays associated with Router Discovery and Duplicate Address Detection. … The main goal of this WG is to develop mechanisms that reduce or avoid such delays, in cases where they are not necessary. … The purpose of the dna WG is to define standards track and BCP documents that allow hosts to detect their IP layer configuration and connectivity status quickly, proposing some optimization to the current specifications that would allow a host to reconfigure its IPv6 layer faster than today. The WG has produced 1 RFC and one WG draft has passed WG Last Call and is now in the IESG review process. A further 7 drafts are still with the WG. This form of reworking existing specifications in order to optimise performance can be very slow and painstaking work, in that much of the existing sequencing of activity and the associated protocol timers were folded into the standard specification to ensure that the autoconfiguration steps did not converge to incorrect outcomes. The work of the dna WG follows a design team proposal to have the host be aware of layer 2 hints indicating a change in access point, and then have the host communicate to a router its concept of connectivity and have the router either confirm this view or propose a new network configuration for the host.
DNS Extensions (dnsext)
This is another example of a WG that has a significant protocol maintenance component. In this case the protocol is the DNS, and while there is a significant protocol maintenance component, the primary focus of the WG is DNSSEC. The WG is concerned with issues relating to DNSSEC deployment and the potential for protocol modifications in the light of DNSSEC experience. In addition the group is also studying zone transfer, notify and update documents as they progress towards Draft Standard status. Current activity is concerned with a set of DNS specification clarification documents, and the NSEC3 issues.
Extensible Authentication Protocol (eap)
EAP appears to be nearing the end of its current charter to revise the EAP specification with a view to fully document the protocol and improve the interoperability of the protocol. This charter is almost complete, and with the publication of the revised EAP specification in June 2004 and the state machine specification in August 2005, the remaining work items are concerned with the keying framework and the network selection problem. It appears that these two drafts are close to WG Last Call, and with that the only remaining task for this WG is to complete the problem definition document on network selection.
Host Identity Protocol (hip)
HIP has had a relatively lengthy history in the IETF. The idea was originally published as an individual Internet-Draft in May 1999. The basic idea is to inject a hash of the public key into the IP datagram as a means of providing a constant identity pivot within a packet sequence. This allows a certain level of locator agility while maintaining a presentation of a constant connection state to the upper level protocols. As noted in the HIP charter, “The Host Identity Protocol (HIP) provides a method of separating the end-point identifier and locator roles of IP addresses. It introduces a new Host Identity (HI) name space, based on public keys.” This is an interesting WG in that its charter is not one that is primarily intended to produce standard protocol specifications, but to define a set of infrastructure elements to allow for wide scale HIP experimentation. At this stage the base HIP protocol specification has completed a WG Last Call, and the architectural description of HIP is to be published as RFC 4423. The mobility and multihoming specifications are in WG Last Call state, and are essentially complete. At this stage it appears that the WG is nearing completion of its chartered work items, and a rechartering discussion is underway in this WG.
Layer 2 Virtual Private Networks (l2vpn)
This WG is responsible for defining and specifying a limited number of solutions for supporting provider-provisioned layer-2 virtual private networks (L2VPNs). The VPN area is one that has certainly consumed a significant amount of attention from the IETF over the years, and the current IETF framework to work on this admittedly large topic is to group VPNs into a number of classes and work on each class as a distinct WG effort. In this case the l2vpn WG is looking at LAN-emulation VPN structures, IP-over-LAN emulation services, and point-to-point private wire services. The working group has a large set of active drafts at present. Five of these drafts were being reviewed as to their security properties by a Security Area review group after a WG Last Call, and a number of documents are close to a WG Last Call. However there are a further 7 drafts under current consideration, and 3 more waiting in the wings. This is a detailed area of activity, and one of the broader WGs in scope, despite the efforts to restrict its scope to layer-2 VPNs, and I suspect that this is not a WG that will have reached the logical end of its charter anytime soon!
Layer 3 Virtual Private Networks (l3vpn)
This is the routed equivalent of the l2vpn WG, looking at VPNs where the VPN is an active routing entity for the client VPN. This WG has already produced 10 RFCs and while there are a further 14 Internet-Drafts in the process, most of these have completed a WG Last Call and are in the subsequent stages of IESG review or awaiting publication. There are only 3 drafts that are currently in the WG, one concerning verification of routing information generated by PE routers and a further two drafts relating to multicast requirements. The discussion on whether to recharter the WG or to declare victory and move on is a likely topic for this WG in the coming months.
Mobility for IPv4 (mip4)
According to the mipv4 WG charter. “IP mobility support for IPv4 nodes (hosts and routers) is specified in RFC 3344. RFC 3344 mobility allows a node to continue using its “permanent” home address as it moves around the Internet. The Mobile IP protocols support transparency above the IP layer, including maintenance of active TCP connections and UDP port bindings.” At present the IETF appears to be in a phase of consolidation in terms of revisiting some basic specifications, and mobility for IPv4 has not escaped such attention. The WG is working on an update to RFC 3344 that clarifies some aspects of the protocol as well as making some adjustments to the protocol specification (draft-ietf-mip4-rfc3344bis-02.txt). This would set the path for mipv4 to progress to a Draft Standard within the Internet Standards process.
Nokia (present at IETF 1): “I think there are two different dimensions where we will see lots of growth: one is in places that don’t have the Internet today. That is a big challenge in many ways. The other dimension is the development to make everything on the Internet interconnected. Instead of just having the laptops, PCs and servers we have to today, we will have an increasing amount of devices that are small or embedded. They may be self-organised but networked together. In the first case the network is getting wider and covering more area and more people. But I think it is also going to get a lot more denser with more devices on the network all the time.
Building this big, complicated, very dense network where everything is networked together and everything has a potential to talk to each other and in a secure way, so it is usable, will keep us all busy for a long time.”
Mobility for IPv6 (mip6)
MIPv6 has a similar objective to mipv4, unsurprisingly, but the mechanisms used in IPv6 to provide this functionality are quite different. At this stage the number of working group documents and related individual submissions is up to 18 drafts, although its not quite as daunting as it sounds. The MIB and shared key documents are to be published as Proposed Standards, and the bootstrap and extensions to the socket API are in the final stages of revision prior to publication. The WG has also completing a review of Mobile IPv6 with IKEv2 and the revised IPv6 architecture.
MIPv6 Signalling and Handoff Optimization (mipshop)
A quick glance at the MIPSHOP drafts and its charter milestones would have you believe that this WG has completed its work items on Hierarchical Mobile IPv6 mobility management (HMIPv6) and Fast Handovers for Mobile IPv6 (FMIPv6). However the group considered 11 individual contributions relating to further potential work for this WG. In other words its chartered work appears to be complete, but the continuing level of interest in this area of activity is extremely high. It appears that this WG may be assuming a role of evaluation of various forms of experimental extensions for MIPv6 that relate to particular envisaged deployment scenarios in the signalling and handoff area.
Mobile Nodes and Multiple Interfaces in IPv6 (monami6)
One of the critical aspects of the IPv6 architecture is the concept of multiple addresses, where an endpoint can be configured with multiple address prefixes simultaneously. This presents some issues to mobility protocols with multiple care-of addresses and potentially multiple Home Agent addresses. The objective of the monami6 WG is to produce a problem statement and associated specifications to clarify the use of multiple addresses in mobility contexts. The multi-homing motivation scenario and mipv6 analysis drafts are in their final stages of WG review and work is progressing on multiple care-of addresses and flow binding.
Network Mobility (nemo)
The nemo working group is concerned with managing the mobility of a network, looking at the issue in the form of interactions between Home Agents and Mobile Routers. The working group appears to be in the latter stages of defining common terminology, requirements, models and issues. It is likely that this material will be completed in the coming months, exposing the critical parts of followup agenda, namely routing optimization in both IPv4 and IPv6 contexts (as well as hybrid v6 over v4 contexts, no doubt) and adequately addressing the associated security issues that proliferate this area of mobility. This is a relatively challenging area to work in and it will be interesting to see how well the Internet Area can produce clear and concise specifications to address this space. The decision to recharter nemo to undertake this work, or use a new WG for this route optimization effort has yet to be made.
Network-based Localized Mobility Management (netlmm)
The basic motivation of this WG is in the assertion that mobility for IP nodes can be more efficiently handled if mobility management is broken down into
localized mobility management and global mobility management. Local mobility involves movements across some administratively and geographically contiguous set of subnets. As the netlmm WG charter notes: “In the WLAN infrastructure market, WLAN switches, which perform localized mobility management without any mobile node involvement, have seen widespread deployment … [this suggests] localized mobility protocol with no mobile node software to specifically implement localized mobility management”. It appears that the WG is heading towards the substance of its study in the draft “Network-based Localized Mobility Management Interface between Mobile Node and Access Router” (draft-laganier-netlmm-mn-ar-if-00). However, the WG is following what has become a very conventional IETF approach of first working at a Problem Statement (what are we talking about), Requirements (why is this useful) and Threat Model (what could go wrong here) as the initial steps into this space.
Network Time Protocol (ntp)
NTP is another of those venerable protocols with very extensive deployment experience. In this case NTP is the timekeeper for the Internet. This WG is chartered to advance NTP along the standards track, by documenting the deployment experience of NTPv4 and completing the specification of NTPv6. From that respect the WG is close to completion of its initial charter, and is looking to add work items concerning IPv6, security and auto-configuration. The NTPv4 document is close to completion within the WG and requires some further revision to reflect NTP extension and authentication fields, the definition of IANA-managed protocol parameter registries and some guidance on the poll interval. The work on the algorithm specification for NTP is also underway. The WG appears to be steadily working through its agenda.
Protocol for carrying Authentication for Network Access (pana)
Its worth quoting the WG charter here to describe the intent of this working group: “The goal of PANA is to define a protocol that allows clients to authenticate themselves to the access network using IP protocols. Such a protocol would allow a client to interact with a site’s back-end AAA infrastructure to gain access without needing to understand the particular AAA infrastructure protocols that are in use at the site. It would also allow such interactions to take place without a link-layer specific mechanism. […] provide support for various authentication methods, dynamic service provider selection, and roaming clients.” Once more this WG has followed the convention of initial documents concerning Framework (what are we talking about), Requirements (why is this useful) and Threat Model (what could go wrong here) as the initial steps into this space. The requirements and threats documents are already published as RFCs and the core PANA specification document, framework description and IPSEC use specification have been passed to the IESG. The SNMP and Pana State Machine descriptions have also been largely completed. The current focus of the WG is on pre-authentication, context transfer, mobility optimizations and interoperation with AAA systems.
Pseudo Wire Emulation Edge to Edge (pwe3)
As any student of Computer Science will tell you there is nothing quite like recursion. Of course recursion is not confined to algorithms and the potential to emulate various media-layer servers as virtual services over an IP substrate has proved to be irresistible for IP. The WG is looking at the encapsulation, transport, control, management, restoration, interworking and security of emulated point-to-point link servers. The set of emulated services includes Ethernet, Frame Relay, PPP, HDLC, ATM, low-rate TDM, SONET/SDH and Fibre Channel. This is a relatively challenging agenda and the WG has already completed documents on a generic architecture and requirements, as well as encapsulation methods for Ethernet, Frame Relay, ATRM and HDLC PPP. However the list of active drafts is impressively long at this point. So there appears to much for this WG to undertake across the remainder of 2006.
Site Multihoming by IPv6 Intermediation (shim6)
This WG has adopted a two phase approach to the area of study. The initial work phase has been to develop a core set of documents that describe the “basic” set of SHIM6 protocol actions, as well as the associated protocol objects that will be used in the SHIM6 protocol. This base scenario looks at the multi-homing problem from the perspective of two communicating hosts that undertake an exchange locator information between themselves as a means of preserving active sessions by being agile across locator pairs in the event of active path failure. This protocol specification work is largely complete, and the three documents are in the closing stages of the WG’s consideration. SHIM6 will now be turning its attention on to a number of potential refinements to the approach, including site-based locator policy settings, split functionality SHIM approaches, and also to the area of signalling path and locator information vertically within the protocol stack. At the same time the WG is now soliciting implementations of the base specification in order to assess the robustness of the protocol specification.
Softwires (softwires)
The issues relating to various permutations of IPv6 and IPv4 have been studied by the IETF for many years now, and the softwires WG is the latest in what has become a rich tradition for the IETF. According to its charter, the softwires WG is undertaking the standardization of the discovery, control and encapsulation methods for connecting IPv4 networks across IPv6 networks and IPv6 networks across IPv4 networks in a way that will encourage multiple, inter-operable implementations. “softwires” are, in this context, various forms of tunnels, and the richness of tunnel approaches, and the level of mutual incompatibility in these approaches are the critical issues for this WG. This WG is looking to define a software end-point discovery mechanism, a softwire setup negotiation protocol and a standard encapsulation. The WG appears to have reached consensus on a “Hub and Spoke” scenario using L2TP and a “Mesh” scenario using extensions to Multi-Protocol BGP with negotiated tunnel encapsulation types. The practical approach being taken by the WG in looking to the capabilities of deployed networks and equipment to guide their standardization decisions appears to be one that offers a practical and effective approach to this longstanding issue.
Transparent Interconnection of Lots of Links (trill)
Many operations folk have grappled with Spanning Tree protocol in L2 networks for many years. There have been noteable victories and equally noteable defeats over the years! Spanning Tree has well known weaknesses and one approach to move to more robust protocols in this space is to look at the problem as a routing problem. The trill WG is looking at the application of link state routing protocol technology to this problem space, using the initial rbridge proposal as a starting point (draft-perlman-rbridge-03.txt). The WG is looking at a problem statement, architecture document and a routing requirements document in addition to the rbridge protocol specification.
BoF Sessions
IP over IEEE 802.16(e) Networks (16ng)
This is the second attempt to introduce the work item of standardizing IP over WIMAX (IEEE 802.16) into the IETF. This appears to be a matter principally of coordination between multiple standards bodies and also coming to grips with multiple convergent layers.
Layer 2 Control Protocol (l2cp)
This BoF was concerned with the configuration of access devices, and, in particular the control of the L2 (switching) operation of access devices. The proposed mode of operation for this group is in keeping with the current style of the IETF to first look at a common framework to describe the environment, then generate a set of requirements for the space, and then look at protocol development work, preferably through protocol adaptation or recycling: “The WG will define a framework and set of requirements, and will investigate and define a solution for an IP based Layer 2 control protocol that is robust, reliable and scalable. L2CP will be based on extensions to existing protocols. The initial proposal for L2CP is based on GSMPv3.”
Network Endpoint Assessment (nea)
This BoF was concerned with a proposal for a Network Endpoint Assessment protocol specification, intended to assess the “status” of devices before that attach to a network. This work is related to the Endpoint Attachment Protocol (EAP) and RADIUS, but focuses on what is termed “posture assessment”, where “posture” is the device’s current state of operating system patches, Firewall state, and similar, and where the assessment checks this state against a set of policy rules.