CURRENT_MEETING_REPORT_ Reported by Mike Davis/Bay Networks and Bob Gilligan/Sun Microsystems Minutes of the New Generation Transition Working Group (NGTRANS) These minutes are based on excellent notes by Mike Davis with edits and additional detail added by Bob Gilligan. Introduction The NGTRANS Working Group met for one of its two scheduled sessions on Tuesday, 18 July. Bob Gilligan lead the session. All work was completed by the end of first session, so the second session was cancelled. The agenda for the meeting was: o Document status o Routing aspects draft o Auto tunneling and multicast o Implementation status Alan Lloyd, who had asked to discuss the topic ``Auto Tunneling and Multicast,'' was not present, so this topic was not discussed. Document Status The working group document, ``Transition Mechanisms for IPv6 Hosts and Routers'' , has been in Last Call for about two weeks, with only one significant comment. The chair could see no barriers to a swift promotion to Proposed Standard. Routing Aspects Ross Callon gave a presentation on the Internet-Draft ``Routing Aspect of IPv6 Transition'' , written by himself and Dimitry Haskin. This occupied most of the meeting. The talk followed the organization of the paper. A number of issues were discussed along the way: o Terminology. It was noted that this specification and the transition mechanisms specification use different terms for the same thing in a few cases. For example, what this specification calls ``semi-automatic tunneling'' is termed a ``configured default tunnel'' in the mechanisms specification. It was agreed that this specification should use the same terms as the mechanisms specification. o Router to Router automatic tunneling. Since automatic tunneling is a mechanism to reach the final end host, it is not clear whether ``router to router automatic tunneling'' makes any sense. It was agreed that it will be either left undefined or disallowed in the specification. o Host to Host automatic tunneling. The specification as currently written specifies that hosts should only use automatic tunneling when there is no IPv6 router on their attached link. When there is an IPv6 router on the link, the traffic should be sent in ``raw IPv6'' form via the IPv6 router. Many people raised the concern that this was a policy decision that should be left up to the network administrator. Some sites might wish to tunnel over IPv4, even though an IPv6 path exists, because the IPv6 routing system is less reliable. Other sites might prefer sending via the IPv6 routers in order to speed up the transition. It was noted that the transition mechanisms specification leaves this policy decision up to the user, and it was agreed that this specification should as well. o Host to Router tunneling. The current draft specifies that a host only uses this mode of tunneling when there is no on-link IPv6 router. Some people felt that this, too, was a policy decision that should be left up to the administrator. The group agreed to relax this constraint. Matt Crawford was given homework to write language for the draft on this topic. o Router to Host automatic tunneling. IPv6 routers that perform automatic tunneling and that are connected to the IPv6 routing system need to advertise reachability into the IPv6 routing system for IPv4-compatible destinations. There was a lot of discussion on the best way to do this, but no decisions were made. Further discussion on the list was encouraged. o Automatic tunneling to IPv4 multicast addresses. The question was raised how a node should transmit an IPv6 packet when the IPv4 address embedded in the destination IPv4-compatible address is an IPv4 multicast address. One thought is to ``tunnel'' the packet to the IPv4 multicast address. Neither this specification nor the transition mechanisms specification say anything about this situation. Since it is not clear whether this would be useful or not, it was agreed to leave automatic tunneling to IPv4 multicast addresses undefined for the time being. o Ross will clean up the example on page 15. o Overlap with transition mechanisms specification. Someone noted that this specification re-defines mechanisms that are also defined in the transition mechanisms specification. The definitions are not in conflict, but having multiple definitions for the same mechanism could confuse readers, so it was agreed that the redundant definitions will be deleted from the routing specification. o Progress of this specification. It was decided to publish at least one more revision of this document in Internet-Draft form, as a product of this working group. The group agreed that the eventual disposition of this document should be as a ``Best Current Practice'' RFC, rather than an Internet standards-track document. Implementation Status Jim Bound gave an update of the implementation work. As far as anyone in the group commented, Bay Networks is the only router vendor that is implementing IPv6. Several host implementations exist or are in progress. There was hope of conducting interoperability testing at or before the next IETF meeting in Dallas. We particularly need to test tunneling.