CURRENT_MEETING_REPORT_ Reported by Robert Gilligan/Sun Microsystems Minutes of the New Generation Transition BOF (NGTRANS) and the Transition and Coexistence Including Testing BOF (TACIT) NGTRANS met as a BOF in San Jose, but has since become a working group. The New Generation Transition BOF (NGTRANS) met in two sessions at the 31st IETF. The first session on Tuesday, 6 December, was a meeting of the BOF alone, while the second meeting on Wednesday, 7 December, was a joint meeting with the TACIT BOF. NGTRANS BOF Meeting Bob Gilligan led the discussion the first day. After bashing, the following agenda was developed: o Meeting Objectives - Gilligan o Transition Routing - Callon/Haskin o Auto-tunneling Defaults - Gilligan o Sending Rules - Simpson o Transition Specification - Gilligan o Addressing Issues - Lloyd o Review Internet-Draft Status - All o Charter of the Group - All o Interoperability Testing - All o Deployment Draft - Simpson o Applications Transition - Bound Objectives Bob Gilligan proposed that the primary objective for the meetings this week should be to nail down the basic near-term transition mechanisms such as IPv4-over-IPv6 tunneling. There was general agreement from the group on this point. Reading List Bob Gilligan presented a slide listing the Internet-Drafts that people should have read by now. Bill Simpson questioned the lack of recognition of his ``IPv6 Deployment'' Internet-Draft written in September, then formally objected. Bob agreed it will be included in reading material, and a slot on the agenda was added for Bill to present his proposal. Charter There was a brief discussion of the charter for the group. There were a number of issues raised. One was the relationship with the TACIT group. Since a joint meeting with the TACIT group was scheduled for the following day, the group decided to table the discussion until then. Deployment Draft Bill Simpson gave a presentation on his ``IPv6 Deployment'' Internet-Draft. This draft outlines a series of steps a site can take in transitioning from IPv4 to IPv6. This approach does not use host-to-host tunneling. Except on a local subnet, IPv6 hosts would continue to use IPv4 until IPv6 routers were deployed. Bill thinks that the general approach in transition should be to first define the end goal then find out what mechanisms are required. There was some discussion about the differences between ``deployment'' specifications and ``mechanisms'' specifications. Sending Rules Bill Simpson talked briefly about an issue he had raised on the mailing list having to do with the sending rules that are defined in the ``Transition Mechanisms for IPv6 Hosts and Routers'' Internet-Draft. Bill's issue has to do with how the sending rules interact with the IPv6 neighbor discovery protocol. After a brief discussion it was agreed that the people present did not have enough context to discuss the issue in detail, so we agreed to take the issue up on the mailing list. There was a short discussion about using the existence of AAAA records in the name space as a key to use IPv6 format. There was no resolution. Auto-tunneling Defaults Bob Gilligan led a discussion of the default rules for tunneling. The issues revolved around whether IPv4/IPv6 hosts should be required to implement automatic tunneling; and, if it were required, whether tunneling should be employed by default, or only used when administratively enabled. Bob's initial proposal was that automatic tunneling should be implemented by all hosts, and that it should be enabled by default. Jim Bound and others raised objections to this, and a lengthy discussion ensued. Specifically, many people felt that automatic tunneling should not be enabled by default, and that it should only be used when explicitly configured by administrators. Some of their objections derived from a concern that administrators have the ability to control how the transition takes place within their sites. While there was significant concern about the use of automatic tunneling, many people felt that general-purpose configured tunneling was a useful mechanism. Near the end of the discussion, there was a suggestion that the specification of the tunneling mechanism be separated from the policies of its use. The group agreed to explore this further at the meeting the next day. Miscellaneous A couple of miscellaneous issues were brought up during the session. Bill Simpson brought up the issue of structure of the transition specifications. He believes that each of the transition mechanisms (tunneling, DNS resolver algorithms, etc.) should be split out into a separate specification document. Bob argued that the specification should remain as one document so that implementors have a single place to find all of the transition mechanisms. The group exhibited no consensus on this. Joint NGTRANS/TACIT Group Meeting Tony Hain led the meeting the second day by presenting the following revised agenda: o Charters of both NGTRANS and TACIT groups o Presentation of IPv6 address registry ideas - Alan Lloyd o Presentation on IPv4/IPv6 routing issues - Ross Callon o Discussion of issues in ``transition mechanisms'' specification - Bob Gilligan Charters Tony Hain presented a proposal for how the work would be divided between the NGTRANS and TACIT groups. The NGTRANS group would be chartered to develop and specify the transition mechanisms (e.g. IPv6-over-IPv4 tunneling, header translation, etc.), while the TACIT group would be chartered to develop the operational policies and plans that would be used in deploying IPv6. Quite a bit of interaction would be required between the two groups. The NGTRANS group would need operational feedback from the TACIT group in order to understand whether the mechanisms it specifies would be operationally viable. The TACIT group would need the implementation feedback from the NGTRANS to understand whether the deployment scenarios it develops are feasible. A number of joint meetings of the two groups would be held, with a goal for at least one per IETF. Tony proposed that the details of the charters of the two groups be worked out on the mailing lists. There was general consensus of the group to go ahead with this. Routing Issues Ross Callon presented a discussion of transition routing issues using some potential topologies, both physical and logical. The basic routing approach is dual-stack. The routing system routes both IPv4 and IPv6. This could be accomplished by entirely separate routing systems, or integrated routing. The physical topology can include a mixture of IPv6-only, IPv4-only, and dual IPv4/IPv6 areas. Header translators and encapsulators are located at the borders between IPv4 and IPv6 areas. The issues include locating the translators and encapsulators. The routing systems must carry packets that need to be translated to a translator, and packets that need to be encapsulated to an encapsulator. The mechanisms also include manually configured tunnels. This is relatively well understood technology that is widely used. Translation and encapsulation require consistent routes between the IPv4 and IPv6 routing systems. This requires the ``leaking'' of routing information (``route leaking'') between the two routing systems. Route leaking can be accomplished in a couple of ways. Translators could announce into each routing system the prefixes it will translate. Or translators could advertise default routes. A couple of hard problems remain: o When an IPv4 packet arrives at a translator, should it be translated to IPv6, or encapsulated within IPv6 (to transit the IPv6 area)? o When IPv4 packets are translated to IPv6, which prefix should be used? 0:0:0:0:0:0 or 0:0:0:0:0:ffff? The former should be used if the destination is an IPv4-only host, while the latter should be used if the destination is an IPv6 node. As currently specified, the translator must have configuration information in order to know which prefix to use. This could be difficult to manage. Ross suggested that the initial router could pick 0s and trust that the last router would fix it later. o Finer scale translation. If IPv6-only hosts are sprinkled into an area with IPv4-only hosts, then translation and encapsulation must be performed at a much finer granularity than currently envisioned, perhaps in every router. Ross' conclusions are that: o Dual-stack routing with manually-configured tunnels is relatively straightforward. o Header translation and automatic-encapsulation are more complex. The details need to be specified. The problem may be simpler if additional constraints are accepted. Sites may be able to avoid some of the complexity by carefully configuring their topology. o The prefix issue should be fixed. There are a couple of proposed solutions that need to be discussed in more detail. Registry Issues Alan Lloyd presented some of his ideas on addressing and address registration for IPv6. One concern is that organizations have private IPv4 address spaces. The addressing plan should leverage the investment these organizations have made in their addressing plans. The general addressing goals are: o Provide harmonization between ISO NSAPs and IPv4 and IPv6 addresses. o Permit ISO to administer some portion of the IPv6 address space. One should understand the differences between the IPv6 specifications, products that routes IPv6, and the Internet. Addressing requirements are: o Enable Legacy ITU 20-byte NSAPs to be carried in IPv6 packets without any loss of information. IPv6 addresses could be used as an NSAP for CLNP. They can be carried with an ICD assigned by the British Standards Institute (BSI) to ISOC. The 16-byte IPv6 address could follow the ICD. Internet NSAPs: A 16-byte address format could be defined that can be used both as a CLNP NSAP and an IPv6 address. To do this, a high-order 8-bit IPv6 prefix would need to be assigned to ISO. The same prefix would have to be assigned as an NSAP. Migration ideas: 20-byte NSAPs could be consolidated into Internet NSAPs. The private IPv4 address spaces could be ``Nationalized'' by assigning high-order 12-byte prefixes, to make 16-byte IPv6 addresses. Concern raised over finding a recognized national body to provide registries. There was some discussion on this presentation. Scott Bradner mentioned that he had discussed this proposal with the IANA (Jon Postel), and noted that the IANA ``owns'' the IPv6 address space. Scott suggested that Alan should discuss this proposal with Jon. He also suggested that these addressing issues should be discussed in more detail in the NOSI BOF. Transition Mechanisms Specification Bob Gilligan started off the discussion of the IPv6 transition mechanisms specification by proposing that all of the policy specification (e.g., specific host requirements for supporting the mechanisms) be stripped out of the specification, leaving a ``pure mechanism'' specification. The policy specification would be taken up by the TACIT group as part of its charter to define the deployment policy. There was a general consensus on this by the group, and Bob agreed to issue a revised specification with the policy wording removed. The discussion then moved on to the details of the mechanisms. Someone brought up the question of DNS queries for A and AAAA records, suggesting that a new query type could be defined to look up both record types in a single query. The specification currently defines this as two separate queries. There was no objection to this idea, but some people thought that there might be interoperability problems in dealing with servers that do not support the new query type. Bob pointed out that the mechanism as specified would work, and that the single-query approach would be an optimization. The resolution was that the specification would be left as-is, but if someone wanted to propose a new query type to get both A and AAAA records, they should go ahead and write up a proposal and send it to the list. There was a long discussion of the TTL to use when tunneling IPv6 packets in IPv4. The specification currently calls for the IPv4 ``hops'' to be counted in the IPv6 TTL for both configured and automatic tunnels. (This is accomplished by copying the IPv6 hop limit field into the IPv4 TTL field when encapsulating, and then copying the IPv4 TTL field into the IPv6 hop limit field when de-capsulating.) A number of people pointed out that administrators may wish to configure whether the tunnels are ``visible'' or not. Implementors noted that this is possible when the tunnels are configured, because then the administrator has the opportunity to select one method or the other. But with automatic tunnels, since there is no prior co-ordination between the encapsulating and de-capsulating nodes, it is impossible for the administrator to configure their ``visibility.'' The general consensus was that administrators should have the ability to configure ``visibility'' of configured tunnels, but that automatic tunnels should remain as they are currently specified. Bob agreed to make the specification reflect this. A concern was raised about tunnel end points needing to maintain state for all flows across tunnel to do the right thing with errors. Resolution to be worked on mail list. A suggestion was made ICMP error message could explicitly identify errors that occurred within tunnels. There was no consensus either way on this. A question was raised about extending amount of ``offending packet'' to be returned by IPv4 ICMP error messages to 576 bytes? Someone noted that this was already in the IPv4 router requirements document. It was also noted that even with this, the transition mechanisms must be prepared to deal with only 8 bytes of ``offending packet'' (the amount in the original IPv4 ICMP specification) that older IPv4 routers will return.