home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
ietf
/
ngtrans
/
ngtrans-minutes-95jul.txt
< prev
next >
Wrap
Text File
|
1995-10-18
|
6KB
|
125 lines
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'' <draft-ietf-ngtrans-trans-mech-01>, 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'' <draft-haskin-ipv6-routing-aspects-01.txt>,
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.