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.