RSS feed
Atom feedFull issue in PDF format
The full IETF Journal, Volume 1, issue 1 (Autumn 2005) is available here for download in PDF format (420KB).
Posted: Monday, October 3rd, 2005
IETF JournalTable of Contents - Volume 1, issue 1 (Autumn 2005)
Full issue in PDF formatThe full IETF Journal, Volume 1, issue 1 (Autumn 2005) is available here for download in PDF format (420KB). Posted: Monday, October 3rd, 2005
Welcome to the IETF JournalBy Peter Godwin - Editor, IETF Journal Welcome to the first issue of the IETF Journal! Our aim is to provide an overview of what ’s happening in the world of Internet standards with a particular focus on the activities of the IETF Working Groups (WG). While we won’t be able to provide in-depth coverage of every WG, each issue of the IETF Journal will highlight some of the hot issues being discussed in IETF meetings and in the IETF mailing lists. We’ll publish three issues per year (following each of the IETF meetings). The bulk of this issue (which was produced in cooperation with the IETF Edu Team) takes a look back at what happened during the recent 63rd meeting of the IETF in Paris. We hope that this publication will give anyone with an interest in Internet standards an opportunity to keep abreast of many of the topics being debated by the IETF, and also facilitate participation in IETF activities for newcomers. We encourage you to provide feedback on this first issue and to let us know what you’d like to see in future issues. Your suggestions for themes or topics for future articles are most welcome. We’re looking forward to hearing from you. You can contact us at: ietfjournal@isoc.org. Posted: Monday, October 3rd, 2005
An Introduction to the IETFThe Internet Society is proud to be the organisational home of the Internet’s premier Internet standards-making body: the Internet Engineering Task Force (IETF). Without the technical achievements of the IETF and its participants, the Internet would never have become the success that it is today. The complete range of IETF standards processes involve several groups, including ISOC, the Internet Architecture Board (IAB), the Internet Engineering Steering Group (IESG), the Internet Assigned Numbers Authority (IANA), the Internet Research Task Force (IRTF), the Request for Comments (RFC) Editor and the IETF itself. ISOC is the home of the IETF Administrative Support Activity. ISOC also acts as the IETF’s educational channel to communicate and promote standards internationally. As a standardization body, the IETF focuses on the development of protocols used in IP-based networks. Its unique process is based on "rough consensus and running code." The IETF is different from most standardization bodies in that it is a totally open community with no membership requirements. It is an international community of network designers, operators, vendors, and researchers concerned with the evolution of Internet architecture and smooth operation of the Internet. As an open forum, anyone can join the activities of the IETF. The IETF consists of a number of working groups (WGs) classified into several areas. Currently, there are seven areas: Applications, General, Internet, Operations and Management, Routing, Security, and Transport. Three IETF meetings are held annually. Decisions are made based not on formal voting but on rough consensus. Many of the IETF’s processes and decisions are managed through mailing list discussions that allow for broad participation in IETF activities by people everywhere. The IETF area directors together with the IETF chair make up the IESG. The IESG administers the Internet standards process according to community-defined rules and procedures, and is responsible for actions associated with the progression of technical specifications along the standards track, including initial approval of new working groups and final approval of specifications as Internet standards. As described above, the IAB’s responsibilities include architectural oversight of IETF activities, Internet Standards Process oversight and appeal. The full IAB Charter is documented in RFC 2850. The IETF Nominations Committee nominates candidates for the IESG and IAB. The IAB confirms the IETF chair and the nominations of IESG candidates. ISOC’s Board of Trustees confirms the nominated IAB members. The IANA is responsible for assigning Internet protocol parameters and works with the IETF on the basis of a memorandum of understanding (RFC 2860). Many protocol specifications include numbers, keywords, and other parameters that must be uniquely assigned. Examples include version numbers, protocol numbers, port numbers, and management information base numbers. The IRTF consists of a number of Research Groups working on topics related to Internet protocols, applications, architecture, and technology. The IRTF chair is appointed by the IAB. In addition to managing the Research Groups, the IRTF may from time to time hold topical workshops focusing on research areas of importance to the evolution of the Internet or may hold more general workshops to discuss research priorities from an Internet perspective. An example of an IRTF Research Group is the Anti-Spam Research Group, which addresses new or improved anti-spam tools and techniques as well as administrative tools and techniques. The specification documents of the Internet protocol suite, as defined by the IETF and the IESG, are published as RFCs. The RFC editor prepares and publishes the RFCs and is responsible for final editorial review of the standards in their definitive form. The RFC editor is an organisation that is financially supported by and under contract to ISOC and overseen by the IAB. IETF standards are specifications that are stable and well understood; are technically competent; have multiple, independent, and interoperable implementations with substantial operational experience; enjoy significant public support; and are recognisably useful within some or all parts of the Internet. IETF standards are freely available on the Internet, without cost, to everyone. Funding ISOC provides a major source of funding and support for the IETF and its processes. Notably, ISOC funds 100 percent of the RFC Editor function today, and is providing additional support for the IETF by housing its Administrative Support Activity (IASA), which is responsible for all of the IETF’s operational support. Funding for these efforts is provided by ISOC Organisation Members as well as ISOC’s Platinum Sponsors for Internet standards programmes: APNIC, ARIN, RIPE NCC, and Microsoft. Other Support ISOC’s contributions also extend to policy and public relations support on behalf of the IETF as well as legal and insurance coverage. ISOC is the IETF’s sole source of financial support apart from IETF meeting fees. Support from companies whose products and services so clearly depend on the standards developed by the IETF is essential. Posted: Monday, October 3rd, 2005
How to take part in IETF activitiesThe IETF is different from most standardization bodies in that it is a totally open community with no membership require-ments. As an open forum, anyone can join the activities of the IETF. The IETF consists of a number of working groups (WGs) classified into several areas. Currently, there are seven areas: Applications, General, Internet, Operations and, Management, Routing, Security, Transport Decisions are made based not on formal voting but on rough consensus. Many of the IETF’s processes and decisions are managed through mailing list discussions that allow for broad participation in IETF activities by people everywhere. IETF meetings are held three times each year. See the IETF web site for more information: http://www.ietf.org. Posted: Monday, October 3rd, 2005
IETF Web resourcesMore information about the IETF IETF mailing lists The Tao of IETF: A Novice’s Guide to the Internet Engineering Task Force The Internet Standards Process Internet Engineering Steering Group Posted: Monday, October 3rd, 2005
IETF Mission StatementThe goal of the IETF is to make the Internet work better. The mission of the IETF is to produce high quality, relevant technical and engineering documents that influence the way people design, use, and manage the Internet in such a way as to make the Internet work better. These documents include protocol standards, best current practices, and informational documents of various kinds. The IETF will pursue this mission in adherence to the following cardinal principles: Open process - any interested person can participate in the work, know what is being decided, and make his or her voice heard on the issue. Part of this principle is our commitment to making our documents, our WG mailing lists, our attendance lists, and our meeting minutes publicly available on the Internet. Technical competence - the issues on which the IETF produces its documents are issues where the IETF has the competence needed to speak to them, and that the IETF is willing to listen to technically competent input from any source. Technical competence also means that we expect IETF output to be designed to sound network engineering principles - this is also often referred to as “engineering quality”. Volunteer Core - our participants and our leadership are people who come to the IETF because they want to do work that furthers the IETF’s mission of “making the Internet work better”. Rough consensus and running code - We make standards based on the combined engineering judgement of our participants and our real-world experience in implementing and deploying our specifications. Protocol ownership - when the IETF takes ownership of a protocol or function, it accepts the responsibility for all aspects of the protocol, even though some aspects may rarely or never be seen on the Internet. Conversely, when the IETF is not responsible for a protocol or function, it does not attempt to exert control over it, even though it may at times touch or affect the Internet. The IETF Mission statement was published as RFC3935. Posted: Monday, October 3rd, 2005
News from the IETFBy Brian Carpenter - IETF Chair There were 1454 registered participants at IETF63 - 150 more than at the last meeting. Attendees came from 36 countries with only 35% from the US. Significantly, many people from ITU-T had come to Paris to participate in the meeting. Attendance at IETF meetings has decreased somewhat during the last four years. This was to be expected taking into consideration the downturn in the fortunes of the telecom industry during the same period. However, attendee levels have held up well when compared to the performance of the Nasdaq Telecom index! Since the last IETF meeting in March, a lot of work has been done with four new Working Groups (WGs) established and 22 WGs being closed. In the same period, around 125 RFCs were published - 71 of them standards or BCP documents Recent achievements of the IETF include:
The IESG and the IAB continue to take transparency very seriously: all meeting minutes are published on the web site. IESG teleconference minutes are available here. IAB meeting minutes are available here. The IAB recently published a series of governing RFCs regarding liaisons with other organisations (RFC 4052 and RFC 4053). There is ongoing work in the General Area of the IETF:
At the next IETF in Vancouver there will be a BoF session to discuss IETF requirements for the publication of technical specifications (watch for the Techspec BoF). More work will be done on procedural and process documents. Also the quality and timeliness of WG output and cross-area review needs to be improved. We all need to think more about engineering practices in WGs. Tools can help to manage the status of documents. Some IETF processes will have to change as the world is changing and becoming more complex. Nevertheless it is very important to ensure stability and continuity. At the same time it’s hard to predict the effect and cost of changes in a non-linear system. The aircraft is in flight, so the engines need to be changed with care (and probably one at a time!). IETF Facts and Figures Document actions and RFCs since IETF62
IETF63
Posted: Monday, October 3rd, 2005
News from the IABBy Leslie Daigle - IAB Chair The Internet Architecture Board (IAB) is chartered both as a committee of the IETF and as an advisory body of the Internet Society (ISOC). Its responsibilities include architectural oversight of IETF activities, Internet Standards Process oversight and appeal, and the appointment of the RFC Editor. The IAB is also responsible for the management of the IETF protocol parameter registries. Like the rest of the IETF, the IAB’s lasting contributions are made through the development and publication of documents. Recent IAB document highlights include
The IAB members met during a retreat in June and discussed the priorities for this year. The following areas were identified as key organizing items:
To help organize and inform IAB discussions on particular topics, informal (ad hoc) committees are formed from time to time. Currently, these include:
All documents published by the IAB are listed here. All current IAB Internet-Drafts are can be found here. Minutes of IAB meetings are published here. For more info about the IAB: http://www.iab.org. Posted: Monday, October 3rd, 2005
News from the IETF Administrative Support Activity (IASA)By Lucy Lynch, chair of the IETF Administrative Oversight Committee (IAOC) The IETF Administrative Support Activity (IASA) structure is designed to ensure accountability and transparency of the IETF administrative and fiscal activities to the IETF community. The IETF Administrative Oversight Committee (IAOC) directs and oversees the IASA. The IAOC consists of volunteers, all chosen directly or indirectly by the IETF community, as well as appropriate ex-officio members from the ISOC and IETF leadership. The IAOC shall be accountable to the IETF community for the effectiveness, efficiency and transparency of the IASA. IAOC responsibilities are:
The IAOC’s mission is not to be engaged in the day-to-day operations of the IASA, but rather to provide appropriate direction, oversight and approval. The IAD is responsible for negotiating and maintaining contracts with outside organisations as well as providing any coordination necessary to make sure the IETF administrative support functions are covered properly. The IAOC was seated in April after the publication of RFC 407 (BCP 101). One of their first activities was the hiring of the IAD: Ray Pelletier was hired for this position in May. At the moment the IAOC is working with CNRI on the transfer of IETF related IPR to “the trust”. The details of this trust are currently being discussed. There are also discussions underway about a potential service contract for secretarial functions with NeuStar. The official web site of the Internet Administrative Support Activity (IASA) and the IAOC is currently located at: http://koi.uoregon.edu/~iaoc. For questions, please send mail to: iaoc@ietf.org or iad@ietf.org. Posted: Monday, October 3rd, 2005
News from the IETF Edu TeamBy Avri Doria, IETF Edu Team The IETF Edu Team, a project organized within the General Area, manages the internal education efforts of the IETF. Its efforts are focused primarily on education for IETF participants and leaders. Historically, each Sunday before the week of IETF meetings, an introductory class for newcomers would be held. Several years ago, a security class was added. In 2004, a decision was made to widen the curriculum offered by the Edu Team. At IETF63 the EDU Team offered five classes: Two versions of the traditional Newcomers Orientation were given; one in English and one in French. The introduction to the IETF for new IETF attendees covers the IETF document processes, the structure of the IETF, and gives tips for new attendees on how to be successful in the IETF environment. At the Seoul meeting in 2004, the IETF first offered the Newcomers class in the language of the host country. The Edu Team decided to do this because there was an expectation that many new participants from the host country would be attending their first IETF meeting and that they might find it useful to hear an introduction from a native speaker in their native language. Specifically in Paris: Une introduction à l’IETF destiné aux nouveaux (ou récents) participants Couvre la structure de l’IETF, le processus d’avancement des documents, et des conseils pour réussir dans ce cadre. Bridging, Routing and Switching was a class that was given for the second time at IETF63. This session demystifies the conceptual issues involved in moving data across multiple hops. The class gives an overview of, and contrasts the functionality of these technologies, including an overview of link state routing (used in OSPF and IS-IS), spanning tree (used in bridging and switching), distance vector (used in RIP), and path vector (used in BGP). DNS for programmers was a new class that was offered for the first time at IETF63. Various IETF working groups’ protocols/applications have a need for universal distribution of information related to their operation. The Domain Name System (DNS) is the natural fit to carry certain information. While the DNS is indeed a very valuable and powerful tool fulfilling its tasks very well for almost two decades now, it does not serve all proposed new uses equally well. And even if the DNS is the lookup system of choice, the extent to which the DNS is used still needs to be considered. Sometimes, the DNS’s strength, its global availability, turns out to be a weakness when it comes to operational issues, tracking bugs and fighting misconceptions. This tutorial covered DNS basics and explained how to take advantage of DNS. It also covered the pitfalls of DNS. The class covered common misconceptions and design criteria to be used. RFC Editor Tutorial or How to Write an RFC is a class that is given at each IETF. Given that the main product of the IETF is technical documentation, this is a critical class and should be attended by everyone who plans to write an RFC. During this class, not only are the processes explained, but some of the major errors RFC authors make are described, with explanations of ways to avoid them. This tutorial provides an introduction for newcomers to the RFC series as well as a refresher for experienced RFC authors. It reviews the most important editorial policies and formatting rules for RFCs. It also provides a set of helpful hints to authors about content and format; following these hints will often improve the timeliness of RFC publication and the quality of the resulting documents. It includes a brief overview of the procedures for review and approval of RFCs, both IETF submissions and RFC Editor submissions. The class was given by an RFC editor and there was an opportunity to ask questions of RFC Editor staff. Copies of slide sets used in the classes are available at: http://edu.ietf.org. In addition to offering the series of classes on Sundays, the Edu Team also holds a lunchtime session for current Working Group chairs on selected topics. These sessions are usually very interactive and this time was no exception. The session at IETF63 covered the criteria the Area Directors use when reviewing Internet Drafts before sending them on to become RFCs and covered new tools that are being developed by the IETF Tool Team and the IETF Secretariat. The Edu Team is always looking for new ways to provide information and education to the IETF community. We hope that this newsletter is helpful in describing the activities of the IETF. The Edu Team maintains an open email list for discussions of any IETF educational issues. Please feel free to subscribe and to send us email with any recommendations you have on ways to improve the educational project in the IETF. For more information about the IETF Edu Team: http://edu.ietf.org Join the IETF Edu Team Mailing list: edu-discuss@ietf.org Posted: Monday, October 3rd, 2005
News from the IRTFBy Aaron Falk, IRTF Chair The mission of the Internet Research Task Force (IRTF) is to promote research of importance to the evolution of the future Internet by creating focused, long-term and small Research Groups working on topics related to Internet protocols, applications, architecture and technology. The Research Groups (RGs) work on topics related to Internet protocols, applications, architecture and technology. Research Groups are expected to have the stable long term (with respect to the lifetime of the Research Group) membership needed to promote the development of research collaboration and teamwork in exploring research issues. Participation is by individual contributors, rather than by representatives of organisations. The IRTF is managed by the IRTF Chair in consultation with the Internet Research Steering Group (IRSG). The IRSG membership includes the IRTF Chair, the chairs of the various Research Groups and possibly other individuals (”members at large”) from the research community. In addition to managing the Research Groups, the IRSG may from time to time hold topical workshops focusing on research areas of importance to the evolution of the Internet, or more general workshops to, for example, discuss research priorities from an Internet perspective. The IRTF Research Groups guidelines and procedures are described more fully in RFC 2014 (BCP 8). The relationship between the IRTF and the IETF is now much closer than in the past. Up until now RGs created by community initiatives were sometimes brought into the IETF. Today however, the initiative to start a Research Group often comes directly from the IETF. This is part of a new move to create RGs to work on specific problems that arise in the IETF. It has also been suggested that the IRTF might produce some kind of new ‘referee publications’ to showcase initiatives for improving the Internet. In the area of simulation, for example, many papers have already been published and it would be useful to present and position their work and their conclusions in order to make comparisons between different papers and proposals easier. One possibility is to introduce IRTF "sanctions" to indicate the best ideas. The IRTF is also working actively to reach out to the network research community to encourage participation in the IRTF RGs. There are currently a number of hot topics being addressed in the IRTF:
Other RGs may be formed to focus on the following topics:
For more information about the IRTF: http://www.irtf.org. Posted: Monday, October 3rd, 2005
IETF63 Review: Plenary SessionsBy Mirjam Kühne, ISOC There were two plenaries held during IETF63 in Paris. The Wednesday evening plenary was dedicated to Operations and Administration with the Thursday plenary focussing on technical issues. Operations and Administration Plenary The Wednesday plenary started with a welcome address by Brian Carpenter, the new IETF Chair. See page 5 for the IETF Chair’s report. Brian thanked France Telecom, the local host and sponsor of IETF63 and introduced Pascal Viginier, Executive President R&D, France Telecom. In his plenary address, Pascal stressed the importance of standardization in order to ensure interoperability. He encouraged the IETF to continue the way in which they are working and to cooperate with other Standards Organisations, especially with the IEEE, but also with the ITU and 3GPP, especially in the area of mobility. On behalf of the Internet Society, Daniel Karrenberg (chair of ISOC’s Postel Award committee) then described the Postel Award and presented the 2005 award to Professor Jun Murai of Japan. Professor Murai thanked ISOC for the award and mentions that he is very pleased to see that there are so many attendees from Japan and the Asia Pacific region nowadays. He remembers when he was the only attendee from Asia at the IETF and looks back to the time when he installed the first root server that was located outside the US. Lucy Lynch, Chair of the IETF Administrative Oversight Committee (IAOC), introduced the IAOC members and describes the responsibilities of the IAOC and the structure of the IETF Administrative Support Activity (IASA) along with the responsibilities of the new IETF Administrative Director (IAD), Ray Pelletier. The IAOC is currently working with CNRI on the transfer of IETF related IPR to a new IETF trust. The details of this trust are currently being discussed. The web site of the IASA is at: http://koi.uoregon.edu/~iaoc Ray Pelletier, the new IAD, introduced himself to the IETF and explained how his job will be to improve the throughput of the IETF and to reduce friction and add transparency. Some processes will have to be changed. He encourages people to send suggestions to iad@ietf.org on process issues regarding meetings, WGs etc. Henrik Levkowetz presented the IETF Tools Team, formed in August 2004. The team is working on a number of very useful tools for the IETF community and is also collecting existing tools from other sources. His presentation as well as all information about the tools can be found at http://tools.ietf.org. A discussion among the IETF community followed during which a number of procedural improvements were suggested related to topics such as:
Some concern was expressed that concentrating too much on too many process changes could take time away from technical work and review. Leslie Daigle, Chair of the IAB, stressed that the entire community needs to find a way to agree on how to pick what process changes we need to work on and in what order. Further work on process changes will continue in the plenary sessions of coming IETF meetings. Technical Plenary During the Technical plenary on Thursday, a number of technical issues were presented and discussed. Steve Bellovin gave a presentation entitled Application security: Threats and Architecture showing how the world is changing and how people that want to cause harm adapt to new technology. The requirements for security have changed, because the threats have changed. Typical attacks today include eavesdropping, man-in-the-middle attacks, evil twin access points, routing attacks and ARP-spoofing. Yesterday’s security mechanisms such as plain text passwords, plain text challenge/response based on passwords or crypto without bilateral authentication don’t work well today. With every transaction we need to ask: Is this the party to whom I am speaking? Who is the Right Party? Authorisation is still the hard part. Depending on the application being used, an appropriate security solution must be chosen. However, in order to make that choice, one needs to know what the properties of the lower layers are. This requires real analysis. After the presentation there was a suggestion to set up a tutorial on this topic. Steve Bellovin agreed saying it is important to make people aware of threats and security holes. IAB Town Hall session Moderated open Town Hall sessions were introduced for the first time at IETF63 in order to encourage discussion during the plenaries. Prior to the meeting, suggested discussion topics were collected on the IETF mailing list. Notably, it is easiest to focus discussion on known problems than everything that in fact is working well. To help frame the evening’s discussion the following issues were raised on the IETF list to be discussed during the open IAB Town Hall session:
A lively discussion followed on the relationship between IETF standards and real-life user experiences: This centred on the question of "How do we make sure we don’t have to turn millions of people into system administrators?" There was discussion about whether this needs to be addressed in every individual WG, or whether a higher level solution exists to the problem. And should user issues become a separate consideration section in standards documents? Some felt that there is not enough expertise about user interface issues at the IETF. A lot of IETF participants are from vendors that sell products. Often there is no end-user experience in the WGs at all (it’s interesting to note that there used to be an Area at the IETF dedicated to users and directed by Joyce Reynolds for many years). The discussion then moved on to the growing complexity and total number of protocols. It is increasingly difficult to see the big picture. Technology is expanding and the IETF needs to respond to that, so Leslie Daigle suggested that more work be done on overview documents, tools and logistical help. Kurtis Lindqvist (an IAB member) was more worried about "layer creep” than “feature creep". There is the tendency to reinvent similar functionality in multiple layers. If one is serious about reducing complexity one needs to analyse what layers show the most complexity and then tackle those. Other speakers believed that as a community we don’t pay enough attention to complexity. It is hard to add simplicity and striking the right balance is essential. Finally, a suggestion was made that WGs should have a web page on which they could present an overview of their technology. The Technical plenary also included updates from the IAB (see page 6) and the IRTF. Posted: Monday, October 3rd, 2005
Jun Murai receives 2005 Postel AwardProfessor Jun Murai is this year’s recipient of the Internet Society’s prestigious Jonathan B. Postel Service Award. The award recognizes Professor Murai’s vision and pioneering work that helped countless others to spread the Internet across the Asia Pacific region. The Postel Award was presented during the 63rd meeting of the Internet Engineering Task Force (IETF) in Paris, France by Daniel Karrenberg, chair of this year’s Postel award committee, and Lynn St. Amour, President and CEO of the Internet Society. “Jun Murai has always encouraged, inspired and helped others, particularly his students and his colleagues in other parts of the Asia Pacific region,” said Karrenberg. “He has also played a key role in creating structures for Internet coordination in the region (particularly APNIC), and he is widely recognized for his recent pioneering work in IPv6 implementation.” Jun Murai is currently Vice-President, Keio University in Japan, where he is a Professor in the Faculty of Environmental Information. In 1984, he developed the Japan University UNIX Network (JUNET), and in 1988 established the WIDE Project (a Japanese Internet research consortium) of which he continues to serve as the General Chairperson. He is President of the Japan Network Information Center (JPNIC), a former member of the Board of Trustees of the Internet Society and a former member of ICANN’s Board of Directors. The Jonathan B. Postel Service Award was established by the Internet Society to honour those who have made outstanding contributions in service to the data communications community. The award is focused on sustained and substantial technical contributions, service to the community, and leadership. With respect to leadership, the nominating committee places particular emphasis on candidates who have supported and enabled others in addition to their own specific actions. The award is named after Dr. Jonathan B. Postel, who embodied all of these qualities during his extraordinary stewardship over the course of a thirty-year career in networking. He served as the editor of the RFC series of notes from its inception in 1969, until 1998. He also served as the ARPANET “numbers Czar” and the Internet Assigned Numbers Authority over the same period of time. He was a founding member of the Internet Architecture Board and the first individual member of the Internet Society, where he also served as a trustee. Posted: Monday, October 3rd, 2005
IETF63 Review: RoutingBy Geoff Huston Securing Inter-Domain Routing For those who have been following this activity, the good news is that the base documents on securing inter-domain routing, being developed in the RPSEC working group are now in their final stages. The next step is to look at the issue of standardization of an inter-domain routing protocol that can incorporate these requirements. There have been a number of secure routing protocol proposals over the past few years and part of the work will be the challenging aspect of standardizing a protocol that can support security in the inter-domain routing environment. It’s likely that there will be a BOF on this topic at IETF-64. This promises to be an interesting area of IETF activity in the coming months. Inter-Domain Routing At IETF 63 there was a proposal to introduce a ‘Time To Live” or TTL for BGP updates. This is not the first proposal for a protocol mechanism to limit the scope of propagation of BGP updates, and no doubt will not be the last, but it does have the essential attributes of being simple in its definition and clear in its operation. Each AS decrements the TTL of an Update, and when the TTL value gets to zero the update is discarded. Given that about one half of the BGP routing table consists of more specific advertisements of existing aggregates, this method of localizing the propagation of more specific prefixes is certainly worth considering. On another note, the revised specification for the BGP protocol proved to be a significant exercise taking some three years and 26 iterations of the draft document. The good news is that this work is now largely complete, and is currently in the publication process. OSPF Current work is on version 3 of this interior routing protocol. This includes aspects of support for Traffic Engineering as well as adding explicit support for various forms of mobility. There is an interesting area of trade-off here in terms of how much functionality is pushed into the routing protocol itself, and how much is taken up by the application environment. ISIS The Working Group is currently working on documenting a number of implementation practices and extensions. The bulk of this work is now coming to a conclusion and the next steps for ISIS appear to be on the agenda for the Routing Area. MPLS The current activity here includes the task of adding multicast to MPLS. No doubt one of these days we’ll see multicast become an accepted and integral part of the portfolio of IP services, but multicast provides a set of technical and business challenges that continue to make its ubiquitous deployment a challenging goal. However there is a lot of interest in multicast these days, and maybe we’ll make some progress in this. Also there is the continuing work in extending MPLS into inter-area support. VPN Activity Standardizing various aspects of the design of Virtual Private Networks continues to be an aspect of the IETF’s work. The original work on standardizing aspects of VPNs quickly split into two working groups, the Level2 and Level 3 VPN working groups, reflecting the two major approaches to VPN implementation. These working groups sit in the Internet Area of the IETF. The Routing Area now has a Level 1 VPN working group, looking at the aspects of providing a synthetic Layer 1 VPN between the customer’s edge devices. Note: This article does not attempt to provide a complete summary of all IETF activities in this area. It reflects a personal perspective on some current highlights. Posted: Monday, October 3rd, 2005
IETF63 Review: IPv6By Mikael Lind IPv6 work is progressing in many parts of the IETF and the IPv6 working group is slowly moving to its close. This doesn’t mean that there isn’t a lot of debate and work going on in many areas. Looking at this IETF, and at the community as a whole, the address assignment plans are the things mostly discussed right now. This is due to the fact that the first real allocations, in accordance with the allocation guidelines, happened last year and have continued at a rather rapid rate. These allocations have been very large and this seems to have triggered people’s attention. The usual reaction is that the consumption rate is a bit unhealthy when seen in a long perspective. Seeing that IPv6 probably will be around for many decades to come it might be wise to apply a somewhat more conservative allocation policy. A common view is that these resources should at least be good for a century or two. One possible approach would be to change the HD ratio of the assignments so that there would be less overhead for the ISPs or to change the default site allocation size. The latter would be simplified by changing RFC 3177 which talks in favour of having one allocation size. There is a proposal for an update of RFC 3177 which tries to highlight that there are no real technical reasons for having only a /48 boundary and suggests a /56 boundary for smaller sites, such as homes. This would save a huge amount of space, even more than changing the HD ratio. Some see the 64 bit division as a tremendous waste and that it perhaps should be revisited. But as it was commented at the meeting, the initial plan was to have only 64 bits for the next generation protocol and instead we now have 64 bits only for networks and people still aren’t content, perhaps nothing is enough to satisfy everybody! Changing the 64 bit division would also have a tremendous engineering impact since it is built-in to many implementations and also used in other standards. As IPv6 becomes a natural part of the Internet the work with IPv6 has to continue. One good example is the work with IPv6 over 802.16 or WiMAX, which was presented at the meeting. 802.16 differs somewhat from the usual Ethernet MAC layer addressing and IPv6 needs to be adapted to fit this. Another thing that shows that there is still work needed on the details is a draft about how to write a link local address in the web browser or other application. An application can’t know which address you are referring to if you only input the address without any reference to an interface. The draft suggests adding this reference to the input of the address. As part of showing that IPv6 now is mature the IPv6 working group (IPv6) is scheduled to be closed by the end of this year. One thing the chairs would like to do before the closure is to move the base specifications to Internet Standard to clearly mark that IPv6 is implemented and out in the market. There were some objections at the meeting about all documents not being mature enough, since they have been recently updated, and it would be fair to wait a little bit longer with these documents. A quick look at the work with mobile IPv6 shows that it is at more or less the same stage as the work with the core IPv6 specifications. The focus of the work is on optimizing the solutions to be able to work in the different emerging network scenarios, rather than on the basic spec. The work with optimizing mobile IPv6 will probably continue for quite a while as mobility becomes more and more important in many environments. IPv6 Operations What has been shown on the operational side is the limited operational experience. Many topics in the IPv6 operations working group highlight this problem. One example is the document on ICMP filtering. ICMP filtering is very different from IPv4 and something that will require rethinking. There is still a lot feedback needed from the community before there will be a good best practice document. Renumbering is another case where there has been an effort to try to document actual renumbering trials, but where it was pointed out that the experience with renumbering is still limited and that there are many pieces missing to make the renumbering effortless. To compensate for the lack of operational experience a lot of effort has gone into documents that describe different scenarios and how they should be tackled. The documents discussed at this meeting covered enterprise networks and broadband access networks. The broadband access network document covers many different deployment cases, but not all. It was pointed out that it doesn’t comply with the latest standard for cable networks, DOCSIS 3.0, but as the draft is more or less ready for last call there was bit of reluctance to wait too long for input on that topic. One document that highlights clearly the difference between IPv4 and IPv6 is the network architecture protection draft. It documents the perceived benefits of IPv4 NATs and shows how these benefits can be implemented in IPv6 without losing end to end connectivity. As it gives a very comprehensive view of a popular topic and includes solutions to all the problems it will hopefully soon be approved by the working group. Shim6 The lack of multi-homing capability is seen by many as biggest problem with IPv6. Therefore the Shim6 working group has put forward a very aggressive plan where most things should be documented and ready by the end of next year. As the multi-homing approach using a shim layer is extremely complex many new questions will arise as the work with the protocol progresses. Right now there are already a number of questions to be answered. One is the triggers to change communication path. To some extent this has already been documented in a draft about reachability detection. The discussion regarding this document showed that it isn’t trivial to define what is or is not a failure. This area will need continued work as will the work with upper layer interaction which was decided to be started as working group item. These are only small parts of the whole design but still very important. Another area that might have to be studied is traffic engineering, which today isn’t covered at all. Right now the focus is on getting the basic architecture through the standardization process. Tunnelling mechanisms Something that has been a hot topic for a long time is different tunnelling mechanisms and at the last IETF there was a BOF about a tunnel discovery and configuration protocol. That BOF didn’t lead to a working group but at IETF63 there was a new BOF on almost the same topic. This time the BOF was called Lightweight Reachability softWires (LRW) and tried to describe the problems instead of the solutions. Even with the focus on the problems it wasn’t clear what the use cases were since there were very many different scenarios where people saw a need for a deterministic tunnelling mechanism. As tunnel mechanisms are things that are needed in the initial stage of IPv6 deployment the time frame for this potential working group is short and the work needs to be started more or less now to be of any use. If the WG is approved the chairs wanted to have an interim meeting to write the problem statement before the next IETF. As a final note it is worth mentioning the Dynamic Host Configuration working group (DHC) which is a good example of where IPv6 has spread and is a natural part of the WG work. A lot of efforts are going in to writing standards for DHC that can work with both IPv4 and IPv6, which isn’t as trivial as it might seem at first glance, especially in a mixed environment with several DHC servers. Note: This article does not attempt to provide a complete summary of all IETF activities in this area. It reflects a personal perspective on some current highlights. Posted: Monday, October 3rd, 2005
IETF63 Review: Mobility and WirelessBy James Kempf Work on mobility and wireless topics for IETF has traditionally been confined to the Mobile IP working group, but today wireless and mobile activities are spreading, especially in the Internet area. As of IETF 63, the working groups developing technology important for the wireless Internet consist of one working group in the Application Area (GEOPRIV), nine working groups in the Internet Area (6LOWPAN, DNA, EAP, HIP, MIP4, MIP6, MIPSHOP, NEMO, and PANA), one working group in the Operations and Management Area (CAPWAP), one working group in the Routing Area (MANET), and one working group in the Security Area (MOBIKE). There were also four BOFs on mobility-related topics at IETF 63:
Finally, the MOBOPTS IRTF Research Group - which reviews research on mobility related optimizations for Mobile IPv6 and recommends topics for standardization that have reached an appropriate level of maturity - typically meets at IETF meetings as well. This is the first of what will hopefully be a regular column that focuses on mobility and wireless topics in the IETF. However, given the range of activities currently underway in the IETF, it is not possible in every column to provide a comprehensive summary of all the working groups and BOFs. Instead, each column will summarize the topic of BOFs and newly formed working groups, and take an in-depth look at the primary activities in one or two working groups dealing with wireless and mobile topics. In this issue, we’ll focus on one of the successors to the traditional Mobile IP working group, the MIP6 working group. Reader feedback on exactly how best to provide ongoing information about wireless and mobility related activity in the IETF is welcome. The MIP6 working group has been chartered to work on a few topics related to implementation and deployment of Mobile IPv6, including updating the protocol specification. Foremost on the list is a way to bootstrap a mobile node having nontopological information (like a DNS domain name of a home mobility service provider) to the point where the mobile node has a home agent address, a home address, and an IPsec security association with a home agent. With this information, the mobile node can perform Mobile IPv6 Binding Update to register its care-of address and start getting traffic routed through the home address. At IETF 63, the design team reported back on their work in this area. The work applies primarily to cases where administrative entity authorizing the mobile node for mobility service and the administrative entity authorizing for network access service are two different entities, but is also applicable to cases where the two different services are authorized by the same entity, such as the typical cellular operator. The design team specified the use of DNS for locating a home agent address (with DHCP also applicable in some limited cases), and IKEv2-based home address configuration. The team also designed a way for the home agent to update the mobile node’s FQDN within the DNS server with the new home address, so that the mobile node is reachable by applications. Another design team has been investigating transition issues related to Mobile IPv6. The transition scenarios addressed by the design team aim to ease the deployment of Mobile IPv6 and allow it to work independently of the access networks’ capability (i.e. IPv4 only or IPv6 only). The work will also allow mobile nodes using Mobile IPv6 to use IPv4 home addresses, which smoothes migration by allowing dual stacked hosts to use one mobility management protocol. Naturally, the design team also aims to make Mobile IPv6 work in networks using private IPv4 addresses and NATs. An important consideration is to avoid having to run both MIP4 and MIP6 on the mobile node, since various considerations have shown that this is difficult and cumbersome to do. The mobile node is assumed to be dual stack. Finally, the working group has also been discussing home agent reliability. The idea here is for a protocol to provide a way for home agents to communicate among themselves, and for a home agent or home agent cluster to communicate with mobile nodes, to allow failover if a home agent goes down either intentionally or inadvertently. A protocol for inter-home agent communication in an individual submission was discussed at IETF 63, as were a few protocols for home agent to mobile node communication. It wasn’t clear to the WG that there is a need for a standard protocol. Discussion will continue on the mailing list. Note: This article does not attempt to provide a complete summary of all IETF activities in this area. It reflects a personal perspective on some current highlights. Mobile IPv6 Working Group web page: Mobile IPv6 Working Group Mailing List: Posted: Monday, October 3rd, 2005
IETF63 Review: DNSBy Jaap Akkerhuis and Peter Koch DNSSEC key rollover The main subject on the agenda during the DNS Extensions (DNSEXT) meeting was automated DNSSEC key rollover. There are different views on how important the existence of such a mechanism is for initial DNSSEC deployment. There are also competing drafts (and methods) to do key rollover for DNSSEC for the roots. The plan is to advance one of them. Meanwhile the main differences between the various methods will be documented and published in order to get the discussion started. While technical solutions have been specified, there exist IPR claims (a patent has been filed in Israel) which make further work on the two existing Internet-Drafts troublesome. There was also a non-IETF meeting of several TLDs on Tuesday where Bill Manning presented his Client Authenticated DNS Request (CADR) system which should enable TLD managers to securely (and, hopefully, quickly) change their TLD’s delegation information (name server names and addresses). The prototype combines DNSSEC technology and a secured website to convey authenticated information to IANA. Currently the system has technical restrictions and also implies policy changes, so it is unclear how things will proceed. NSEC record There is progress on the definition of the new NSEC record and there is even the possibility of code for real testing within a couple of months. The fact that with this proposal the Opt-In proposal pops up again is something that might be cause for quite some discussion. The desire was expressed not to repeat the whole discussion. The chairs urged to leave out political arguments which made the previous debate ugly. Server Identification extension With the deployment of anycast for nameservers, there is a need to have an identification of which server actually answered the question. This would help debugging of anycast systems. Progress was made on the way this should develop and a new ID by Rob Austein is expected. Domain Name System (DNS) IANA Considerations To help experimenting with new RR types in DNS, Donald Eastlake proposed some policy rules for IANA to register these RR types. RFC 2929 Early Allocation for RRs (RFC 4020) is felt to be too strict. Policy being policy, this of course caused a lot of discussion. A new and less controversial ID is expected to be published soon. TAHI Test tool set There was a small presentation of an effort to do conformance testing (www.tahi.org). There is some overlap with the French group doing DNS infrastructure testing (www.idsa.prd.fr/index.php?lang=en) and both groups promise to work together. Best Current Practice for TLD Zones During the DNSOPS WG meeting Kurtis Lindqvist presented a draft which was trying to address best practices for TLD zones. It triggered a lot of discussion since it compares running TLDs to the proverbial blind man describing an elephant. Just what is involved? Is it running the name servers? Is it the registry, the Whois server, etc? Is it all of these or just some of them? Also, this might be taken as a requirements document to dictate on technical grounds political decisions in places such as, and not limited to, ICANN, ITU, WSIS, UN, OECD, Governments etc. This was of course not the purpose, but one never knows what will happen. The document will be split in, at least, two parts. One part on “how to run nameservers”, which is in itself not a trivial problem statement. For the “how to run a TLD registry” documents there will be some discussions with various groups (including ISOC) in order to define the scope of such a document. This is needed in order to avoid treading into level 9 space. Note: This article does not attempt to provide a complete summary of all IETF activities in this area. It reflects a personal perspective on some current highlights. Posted: Monday, October 3rd, 2005
IETF63 Review: New ‘Birds of a Feather’ (BoF) MeetingsApplications Area: Internet Area:
Ops/Mgmt Area: Transport Area: Security Area:
Posted: Monday, October 3rd, 2005
Recently-published RFCsFor the latest RFC list: http://www.ietf.org/iesg/1rfc_index.txt To search for an RFC: http://www.ietf.org/rfc.html
Posted: Monday, October 3rd, 2005
IETF Glossary
Posted: Monday, October 3rd, 2005
CalendarAutumn 2005 - 64th IETF
Spring 2006 - 65th IETF
Summer 2006 - 66th IETF
Autumn 2006 - 67th IETF
Spring 2007 - 68th IETF
Summer 2007 - 69th IETF
Posted: Monday, October 3rd, 2005
|
