CURRENT_MEETING_REPORT_ Reported by Tony Hain/LLNL - ESnet Minutes of the New Generation Transition Working Group (NGTRANS) and the Transition and Coexistence Including Testing BOF (TACIT) The NGTRANS Working Group met in two sessions at the Danvers IETF meeting. The first meeting was held on Monday morning, and the second, a joint meeting with the TACIT BOF, was held on Wednesday afternoon. First Session -- Monday There were approximately 120 attendees. Tony Hain opened the meeting noting that the goal of the meeting was to address outstanding issues with the Internet-Draft ``Transition Mechanisms for IPv6 Hosts and Routers,'' in preparation for a working group last call and forwarding that document on the standards track. Outstanding Issues Bob Gilligan lead a discussion of the document. He asked the group for issues that were outstanding. The group raised the following issues: 1. Can an IPv4 compatible address be assigned to IPv6-only nodes? 2. IPv4 loopback addresses as an IPv4 compatible address. 3. Dealing with RFC 1597 networks during transition. 4. Traceroute visibility -- is there need for it? o If yes, how? o If yes, in this document? 5. Implementation status (discussion of which was delayed until the future joint NGTRANS/TACIT meeting). 6. Should well known tunnel addresses be defined in the draft specification? Discussion The outstanding issues were discussed. Issue One Can an IPv4 compatible address be assigned to IPv6-only nodes? It was noted that, at the interim IPng meetings at Xerox PARC, it was decided to define IPv4 compatible addresses for tunneling, as opposed to their previous usage that defined translation which was judged too complex and was changed. This is addresses of the form ::. It was noted that if IPv6-only nodes would not need an IPv4 compatibility address, a regular IPv6 address should be used. Ross Callon noted that if you have a compatibility address you must be a dual stack system (IPv4 and IPv6) and know how to do auto encapsulation. Jim Bound noted that the answer to the question is ``no.'' Ross Callon noted that real IPv6-only systems needed real IPv6 addresses. Bob Gilligan noted that this usage (of IPv4 compatible addresses) was a transition mechanism only, but a system must have one of these addresses if it is a tunnel end point. The issue was concluded with a clear understanding that IPv4 compatible addresses can not be assigned to IPv6-only nodes. Issue Two IPv4 loopback addresses as an IPv4 compatible address. In IPv4 implementations, the address 127.0.0.1 is a loopback address. What does the IPv6 address ::127.0.0.1 mean? Someone noted that the address is needed for application compatibility (which was later challenged by Mike O'Dell, but not resolved). Another noted that the semantics meant simply to tunnel to oneself, and there are no other valid uses. As a side note, it was noted that an address of the form 1234::127.0.0.1 was a legitimate IPv6 address, not a loopback address, which led to the comment that it was always a mistake to guess a function or meaning for an IPv6 address from looking at only some lower part of it. Bob Gilligan contended that the loopback address did not need to be in the draft, but that it could be in the draft where the dual mode specification is to make it clear that it is only an IPv4 mechanism. It was then noted that in the future a profile specification might be needed, and that this would be appropriate to be addressed then. Allison Mankin noted that it would be best to get some transition experience first, before such a document. Issue Three Dealing with RFC 1597 networks during transition. Someone asked if networks using a private IPv4 address space, such as the address blocks defined in RFC 1597, would be dealt with by the transition mechanisms. The answer is that this specification was not designed to address the issue of private IPv4 address spaces. Sites with private address spaces may use the techniques outlined in the specification, but this would not make their private address spaces globally reachable. Issue Four Traceroute visibility -- is there need for it? If yes, how? If yes, in this document? This subject was discussed briefly to get a start for future discussion at the joint NGTRANS/TACIT meeting. Over an IPv6 path that is tunneled through an IPv4 network (or path), the IPv4 routers would not be visible to a traceroute. It was noted by Bill Manning that previous experience, e.g., BGP4 and the MBONE, shows that the tunneled portion should be treated just like a point-to-point link, and should be thought of as just that for an IPv6 traceroute as well. Several ways were hinted at as to how to show the hidden tunnel path, including one which had the boundary points (both going into and out of the tunnel) noting in their ICMP response that there was an IPv4 tunnel being traversed, so that an explicit traceroute of that v4 path could be done if desired. The discussion was then postponed for the joint meeting. Issue Five Implementation status. Discussion of this was delayed until the future joint NGTRANS/TACIT meeting. Issue Six Should well known tunnel addresses be defined in the draft specification? This issue is whether a well known IPv4 address for IPv4-to-IPv6 border routers should be published in the draft specification, in some sense as an ``anycast'' equivalent function. Mike O'Dell noted that it would have to be a network prefix, not a host address, as some internal routing protocols (e.g., RIP) would not be able to advertise it otherwise. Ross Callon asked if there should be a tunneling redirect. The consensus was ``no.'' Bob Gilligan stated the assumption of global connectedness of IPv6 for the single well known advertisement, to which Matt Crawford responded that one day it might be and the next day it would be divided, hence busting this assumption. Bob reasked his question of whether the well known address should be in the draft. The question was then asked, what source IPv4 address is used in tunneled packets sent by the border router? Should it be the well known address or the border routers own IPv4 address? Mike O'Dell challenged wiring this address into the draft saying that it would cause future problems. Ross Callon favored including it as a low priority route when other methods of discovering the boundary router(s) fail. There were various ideas of what methods might be used to find a tunnel address. Mike O'Dell then restated that it was a bad idea to build in a special hack for a particular network. Someone asked if there was really enough of a problem that we need an automatic mechanism? It was noted that this address was really more like an ``anycast'' address. Defining it as a well known global address could be a problem. Someone pointed out that one could get an address from a configuration server, e.g., DHCP. Bob Gilligan noted that whatever, there needed to be an address, or a manual configured address, or a new protocol defined. To specify the well known address might mean more complexity in configuring. Allison suggested that a small (one page) Informational RFC defining the address be published. This document would be used for deployment testing. The transition mechanism document would explain the mechanism of a tunnel logical address, but not specify that address. There was general consensus for this approach. Second Session -- Wednesday This was a joint meeting with the TACIT group. The meeting was opened by Tony Hain, stating the goal was to address the need for traceroute visibility and finish the mechanisms document. Bob Gilligan reviewed the tunnel visibility options: Option 1: Blind tunnel. Always ignore lower layer. Option 2: Encapsulating border. Black hole errors in the tunnel Option 3: Encapsulating border. Returns error messages for each IPv4 point in tunnel (requires soft state). Option 4: Special message at borders. Extension to ICMP to mark tunnel boundary and return far end address. Alex Conta proposed a special ICMP message for traceroute which would use a IPv4 format ICMP message to cross the border. The discussion questioned the validity of using ICMP, as some vendors would special case the message and not return a valid indication of network characteristics. Someone raised concern that soft-state would be required for path MTU in any case, so why not add it for ICMP errors? Several comments were made that were sympathetic to defining a general ICMP extension that would indicate that an error occurred on entry to a tunnel, the type of the tunnel, and the endpoint of the tunnel. There was general consensus that this document did not need to define a mechanism for tunnel visibility at this point. There was also consensus that treating IPv4 as a special subnet type is a bad idea. Concerns were raised about the mechanism of maintaining error state information about tunnels. Problems could be caused if this information becomes stale. Some people also felt that maintaining error state information about a tunnel would be complex to implement, and it was unclear what value it would provide. Bob asked if this section should be removed from the document? There was general consensus to remove the sections of the document pertaining to maintaining tunnel error state and ttl mapping. There was consensus that after these changes are made, the document could be put up for a last call and then forwarded onto the standards track.