IP: Next Generation Area Directors: o Scott Bradner: sob@harvard.edu o Allison Mankin: mankin@isi.edu Area Summary reported by Scott Bradner/Harvard and Allison Mankin/NRL Meetings of the following groups were held during the 31st IETF meeting in San Jose: o IPNG Directorate (NGDIR) o IPv6 MIB BOF (IPV6MIB) o New Generation Transition BOF (NGTRANS) o Next Generation and OSI BOF (NOSI) o Transition and Coexistence Including Testing BOF (TACIT) o Address Autoconfiguration Working Group (ADDRCONF) o Address Lifetime Expectations Working Group (ALE) o IPNG Working Group (IPNGWG) The IPng Recommendation by the IPng Area to the IESG (RFC 1752) had been passed in between the Toronto and San Jose IETF meetings. This was the first meeting at which the new IPng Working Group met (and met, and met, and met...). The IPng Directorate had a final open meeting, at which the main topics were the duties of the IPng Area before its closing down and international implications of requiring the encryption protocol header for IPv6. The IPng Area was asked to shepherd a group of specifications (between 10 and 20) to submission, rather than just the base specification. The IESG Security Area Director, Jeff Schiller, sat in and led the security discussion, which renewed consensus for the recommendation. The co-Area Directors had two plenary presentations, one a status update and the other an overview of the state of IPv6 address assignment, with presentations by Bob Hinden, Daniel Karrenberg, Yakov Rekhter and the IANA (Jon Postel). Given the recommendation that the IPv6 suite of specifications be ready for submission to the IESG before the 32nd IETF, it was an even busier meeting for the IPng Area than Toronto. The IPng Area will be dissolved by the time of the Danvers IETF, having completed the duties with which it was charged. IPv6 MIB BOF (IPV6MIB) This was the first BOF to discuss network management for IPv6. It met for one session in San Jose. The agenda included changes to existing standards track SNMPv2 documents, potential changes to existing MIBs and new and additional MIBs. The relationship between IPv4, IPv6, and Applications was briefly addressed. For example, should (can) we strive for common Managed Objects between IPv6 and IPv4? If so, should (can) all or some of the Managed Object be in common? The list of MIBs affected by IPv6 were determined to include: o MIB-II o Forwarding Information Base o Routing Protocols o Link specific MIBs (e.g. IPCP) o Accounting MIB o RMON-II o Host MIB Though there is keen interest in management work related to IPv6, the BOF did not take up the question of proposing one or more working group charters. It was decided to take this up with the the IPng co-Area Directors and also to start a mailing list for follow up of the BOF's initial work, ip6mib(-request)@research.ftp.com. New Generation Transition BOF (NGTRANS) and Transition and Coexistence Including Testing BOF (TACIT) The charter for NGTRANS was passed by the IESG and IAB two weeks after the San Jose meeting, but it met as a BOF for two sessions at San Jose. The NGTRANS BOF met on Tuesday December 6 and Wednesday December 7. The Wednesday meeting was a joint meeting with the TACIT BOF. The Internet-Drafts discussed at the meeting included Bill Simpson's ``IPv6 deployment'' draft, Bob Gilligan's ``transition mechanisms'' draft, and Ross Callon's and Dimitry Haskin's ``transition routing issues'' draft. Alan Lloyd presented some ideas on addressing. The group's charter was briefly discussed, as was a general proposal for a division of responsibility between the TACIT and NGTRANS groups. The group agreed in principal to the division of work, with the details to be taken up on the mailing list. Bob Gilligan agreed to re-issue the ``transition mechanisms'' Internet-Draft as a ``mechanisms only'' document, with policy issues to be discussed in another document. Remaining work for the group includes specifying the transition mechanisms in detail, and working out the routing issues. Next Generation and OSI BOF (NOSI) About 35 people attended the BOF. Presentations were made by Brian Carpenter (summary of possible requirements, scenarios and mechanisms); Ross Callon (outline of the Avoid Brutal User Transition (ABUT) plan); Jim Bound, Jack Houldsworth and Dan Harrington (three variants of how to carry NSAPs in IPv6 headers). Rapid agreement was reached that three mechanisms should be pursued in any case: o RFC 1006bis (ISO transport over TCP, small mods to existing RFC) o Classic CLNP over IPv6 tunnels (NextHeader = CLNP; probably no new document needed, at most a very short RFC) o TP4 over IPv6 (requires some real work, volunteer needed) It was also agreed that Ross Callon should write up the ABUT outline. There was a lot of discussion about the need for and the details of carrying NSAPs in IPv6 packets. The ideal would be to find a way to combine the best aspects of the three proposals. It was agreed to continue this discussion on the NOSI list in the expectation of reaching closure at the next IETF in a second BOF. Also the IANA is looking at Alan Lloyd's and Jack Houldsworth's proposals to allocate some IPv6 address space as genuine NSAP space. Address Autoconfiguration Working Group (ADDRCONF) The three ADDRCONF sessions were spent discussing open issues in the latest draft document. The issues spanned design details such as the constraints needed to ensure unique addresses when operating in stateless mode, how to form addresses on media other than IEEE 802 links, the need to support address reuse, and how hosts determine a server is available after it has been down. Larger issues were also discussed such as the protocol used to transport messages (link layer, ICMP or UDP), the need to support DNS autoregistration and the relationship to DHCPng. One significant issue was raised regarding whether it would be better to separate the stateless versus stateful protocol, but this question was not resolved within the sessions themselves. The issue was discussed in the last IPng Working Group meeting and is to be followed up on the ADDRCONF mailing list. Some of the above issues were resolved; having a separate stateless protocol is likely to make resolution of the remaining issues easier. Address Lifetime Expectations Working Group (ALE) The ALE Working Group met on Wednesday evening. As a result of the apparent growth trends presented during the Toronto meeting, the group recommended to the International Engineering Planning Group (IEPG) that it may soon become necessary for IANA to start assigning network numbers out of the upper half of Class A (aka: `A-sharp') number space for CIDR-like IPv4 address assignments. The IEPG asked ALE to identify the issues that such a plan would raise and recommend workarounds. One issue was discussed during the CIDR Deployment Working Group (CIDRD) meeting earlier that afternoon: a router that was configured with a default next-hop address and a route to a single subnetwork of a Class A network number was unable to forward packets to the other subnetworks within that same Class A network. A software upgrade solved this problem; ALE and CIDRD recommend having all service providers require `classless' routers. Since the IPng Area is expected to disband in the near future and much of the remaining work also falls within the scope of the CIDRD Working Group, it was suggested that the IPv4-ALE group merge with CIDRD. While performing the numerical analysis during the preceding weekend, an inconsistency was discovered in the two most recent IP Allocation Reports: the counts of Assigned and Allocated Network Numbers in the October report had dropped by 1% for Class B numbers and 14.4% for Class C when compared to the August report. Since there is no mechanism in place for numbers to be returned to IANA, it was assumed that there must be a bug in the program generating the reports; representatives from the InterNIC were notified of the problem earlier in the week and planned to investigate it as soon as possible. The linear growth model, presented by Tony Li, included these last two data points while the logistic model, presented by Frank Solensky, did not. Both models currently suggest that IPv4 addresses would be depleted around 2008, give or take three years. IPNG Working Group (IPNGWG) The IPng working group held five working group sessions and one implementors meeting. The Friday session included joint discussions with ADDRCONF and NGTRANS. A highlight of the Sunday meeting was the presentation, by Joel Halpern, the Routing Area Director, on progress on IPv6 routing protocols: SDRP, OSPF, IDRP and IS-IS are all working on IPv6 versions. The RIPv2 Working Group has a proposal for RIPv2ng ready. The IPng group presented a number of arguments to Joel against his reservations about allowing a RIP to continue into IPv6. [Note: Subsequent to this session, the RIPng work was approved by the Routing Area Director and the RIPV2 Working Group will take on this task.] The rest of the Sunday meeting was devoted to specific implementor concerns, all of which were then brought to the full working group in the rest of the week. [Note: an implementor's meeting does not make decisions regarding protocol issues. Thus, any apparent agreement at an implementor's meeting is not binding, but rather is just a recommendation to the working group.] The working group agenda for its many sessions was to review all of the specifications and resolve all open issues that could be identified, either from the March and Sunday implementors' input or from the floor of the working group. The agenda overview was: o Review results of implementors meetings o IPv6 base protocol Specification o ICMP/IGMP o Addressing Architecture o Unicast Provider Address Formats o NSAP Addressing o Security o Neighbor Discovery o DNS Specification o Flow IDs o Header Compression o Proposed New Header Types A very high level summary is presented here from a long set of notes prepared by Bob Hinden. The working group chose not to split up the base protocol document, so it will contain the complete ``basic set'' of headers. The type 0 routing header will be merged with/replaced by the format developed in the Source Demand Routing Working Group (SDR) for Explicit Routing Protocol. In address architecture, there was consensus to use the Pack approach instead of clusters: For any particular cluster/pack: Take any specific unicast address (which is appropriate for this topological part of the network), assign it for use in this way, and use it as a cluster address. The pack address approach therefore avoids the problem of requiring that the prefix not have a trailing zero (since this would create an ambiguous cluster address), but requires that systems which need to know their address and also their associated cluster address will need to be configured (or auto-configured) with two complete addresses, rather than an address plus a prefix length. However, this ``Two-Address-Configuration'' is probably a good idea regardless of which format is used. A problem for cluster address approach is that: (i) you effectively lose one bit at each level (the last bit at each level must be ``1''); (ii) If you add a new level split in the middle, you may have to renumber (and also lose the bit in the middle). The only way to guarantee that you will not have to renumber in this case is to only use addresses with ``1''s in all bit positions, which is clearly impractical. The proposed unicast provider address formats review centered on registry format and clarification of the document. An address registry can have multiple blocks of addresses assigned to it. The IANA is the highest level Internet address registry. All that routers should assume about address formats is that they are doing longest prefix match, on bit boundaries. It was agreed that the document must make this very clear, as discussion indicated that it seemed to convey that there was a fixed 3 bits of registry ID in the format. It was agreed that the ``actual allocation'' draft should list actual providers/address registries, and the address prefixes that are assigned to them. These might happen to be assigned geographically/topologically, with space left for expansion, but we do not want to stress any geographic basis of this. Detailed notes on the other agenda topics will be found in the full IPng Working Group minutes.