CURRENT MEETING REPORT

Reported by Tony Hain, Microsoft Corporation, and Bob Gilligan, Freegate Corporation

NGTRANS Working Group Meeting (ngtrans)

Bob Gilligan opened the meeting with the agenda:

1. Review of "Routing Aspects of IPv6 Transition", an Internet-Draft by Dimitry Haskin & Ross Callon.
   
2. Use of the ::127.0.0.1 as a Loopback address.
   
3. Use of "raw IPv6" packet format between nodes on the same link using IPv4-compatible addresses. (issue from UNH testing)
   
4. Are IPv4 multicast addresses mapped into the IPv4-compatible IPv6 address space?
   
   

Review of "Routing Aspects of IPv6 Transition"

Dimitry Haskin presented an overview of the the document. (Slides of the presentation follow these minutes.) A number of issues were raised by the audience during the course of the presentation:

• Alex Conta pointed out that his new IPv6-over-IPv6 tunneling specification uses some different terminology from this document. In particular, it uses the term "fixed exit" to describe configured tunnels, and "free exit" to describe automatic tunnels. Others pointed out that the "routing aspects" ID adheres to the terminology used in the document "Transition Mechanisms for IPv6 Hosts and Routers". The group agreed to stick with the current terminology.
  
• Many people commented on the use and allocation of an IPv4prefix for the "IPv4 anycast" address to be used for the "default configured tunnel". Some people suggested that using just a single IPv4 address shared by all IPv4/IPv6 routers at the border of the IPv6 cloud would suffice, and be simpler to manage.
  
• Someone suggested that the IPv4 address of default configured tunnel could be a global constant defined in this spec. Others pointed out that this idea has been suggested previously but that there was concern about "hard coding" an address into implementations. An alternative suggestion was then proposed that implementations should have a single default address for the default configured tunnel, but that implementations should have the ability to override this.
  
• There was discussion about the leaking of IPv4 routinginformation into the IPv6 routing system.
  
• Someone raised a concern that in dual IPv4/IPv6 routing topology, determining when to tunnel a packet added additional complexity and need for configuration. A simple alternative approach would be to have the first dual router that the packet encounters along the path tunnel the packet to its end destination.
  

There was a general concern expressed by a number of people that this spec covered a wide variety of options, but made no recommendations as to which was preferred. Since the group's intent is to publish this document as a "Best Current Practices" (BCP) RFC, it should recommend the preferred alternative when many approaches are possible. After much discussion, the group agreed that the document should be pared down, eliminating the alternatives are clearly not recommended, and structured so as to identify the recommended approach for each item. Dimitry agreed to refine the document along these lines in the next revision.

IPv4-compatible Loopback Address

Steve Deering raised the issue that the Transition Mechanisms spec, recently approved by the IESG to be published as a proposed standard, defines the address ::127.0.0.1 as an IPv6 loopback address. This is the IPv4 loopback address represented as an IPv4-compatible IPv6 address. The concern is that this may be viewed as requiring all IPv6 routers to implement a filter for this address, and this additional check would need to be in the forwarding path. Treating ::127.0.0.1 as a loopback is unnecessary since the IPv6 already defines the address ::1 as loopback.

It was proposed that section 3.1.1 (the section defining ::127.0.0.1) simply be deleted from the Transition Mechanisms spec. This would not prevent hosts from using ::127.0.0.1 as a loopback address, but would relieve routers from the requirement to filter it. There was no objection to this proposal. (Indeed, some people thought that this resolution had been made at an earlier meeting!) The group agreed that this section should be deleted before the document is published as an RFC, if possible.

Use of "raw IPv6" packet format when sending to IPv4-compatible destinations

An issue came up at the UNH test event in early February about the proper way for two nodes on the same datalink, both configured with IPv4 compatible addresses, to interoperate. Some implementors interpreted to spec to say that they should use the "raw IPv6" packet form, and use neighbor discovery for address resolution. Others interpreted the spec as saying that it is legitimate to use the IPv6 in IPv4 tunneled form for all communication, even with other nodes on the same link. The result was that connectivity was asymmetric, depending upon which system initiated communication.

This item generated a good deal of discussion. There was general agreement that the transition mechanisms spec needs to be revised, or a clarifying spec issued, to ensure that all IPv6 nodes using IPv4-compatible addresses will interoperate. However, there was not agreement on what the spec should require.

Arguments were made on both sides. It was pointed out that sending packets in the "raw IPv6" form is more efficient, since it avoids transmitting an encapsulating IPv4 header. On the other hand, always sending in the tunneled form is a simpler model to implement. The group agreed to take discussion of this issue up on the mailing list.

Are IPv4 multicast addresses mapped into IPv4-compatible space?

During the discussion of item 2, someone raised the question whether the IPv4 multicast addresses can be "mapped" into IPv4-compatible addresses space. The transition mechanisms spec does not specifically prevent this, but the general consensus of the group was that this should not be allowed.