Minutes of NGtrans WG Meeting Orlando IETF Dec 98
Bob Fink
rlfink@lbl.gov
Sat, 12 Dec 1998 19:01:53 -0500
--=====================_464915961==_.ALT
Content-Type: text/plain; charset="us-ascii"
Minutes of NGtrans WG Meeting
8 December 1998
Orlando IETF
Chairs: Bob Fink fink@es.net
Tony Hain tonyhain@microsoft.com
This ngtrans meeting reported by Alain Durand, Bob Fink and Tony Hain
Attendance: 170 signed in, estimated at 200 actually present
________________________________________________________________
Administrative information:
Discussion ngtrans: ngtrans@sunroof.eng.sun.com
Subscribe ngtrans: majordomo@sunroof.eng.sun.com "subscribe ngtrans"
Archive ngtrans: ftp://playground.sun.com/pub/ngtrans
Web site: http://www.6bone.net/ngtrans.html
Discussion 6bone: 6bone@isi.edu
Subscribe 6bone: majordomo@isi.edu "subscribe 6bone"
Archive ngtrans: http://www.ipv6.nas.nasa.gov/6bone/
Web site: http://www.6bone.net
___
The chairs announced there will be a joint ngtrans/ipng interim meeting in the
San Francisco area in early February for future planning of IETF IPv6 work.
Further revisions to the ngtrans charter will await these discussions and due
process in the WG. An announcement will be made to all the mail lists as soon
as possible as to time and place.
Bob Gilligan has resigned as a co-chair of ngtrans due to other commitments.
The continuing co-chairs would like to thank Bob for all his past IPv6 work,
for the IPng WG and NGtrans WG. Newcomers should be aware that Bob helped craft
IPv6's excellent Transition Mechanisms concepts and architecture.
___
Erik Nordmark from Sun concluded discussion on the I-D for replacement of RFC
1933 (Transition Mechanisms) and will proceed with a last call on this work.
Items that will be included in the -01 to -02 version of the I-D are:
Will add clarification that configured tunnels can be unidirectional or
bidirectional.
Will add description of bidirectional virtual links as another type of tunnel,
and that nodes MUST respond to NUD probes on such links and SHOULD send NUD
probes.
Will add reference to [6over4] work.
Will clarify that IPv4-compatible addresses are assigned exclusively to nodes
that support automatic tunnels.
Will add text about formation of link-local addresses and use of Neighbor
Discovery (ND not used on unidirectional links.)
Will add restriction that decapsulated packets not be forwarded unless the
source address is acceptable to the decapsulating router.
___
Announced conclusion of last call for SIIT, which will now be forwarded for
IESG processing as Experimental RFC.
___
Discussed WG last call for NAT-PT Experimental RFC forwarding with agreement
that the author would cleanup references to, and duplication of, SIIT work.
Then another last call will be done.
___
Announced conclusion of last call for 6bone Routing Practices, which will now
be forwarded for IESG processing as Informational RFC.
___
Kazu Yamamoto from the Internet Initiative Japan gave a presentation on
"Categorizing Translators Between IPv4 and IPv6"
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-translator-00.txt>
(co-author is Munechika Simikawa from Hitachi). This work has value to the
transition activity as an Informational RFC, so this will be explored with the
authors.
___
Kazuaki Tsuchiya from Hitachi gave a presentation on "Dual Stack Hosts Using
the Bump-in-the-Stack Technique"
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-dual-stack-hosts-00.
txt>
(co-authors are Hidemitsu Higuchi and Yoshifumi Atarashi, also from Hitachi).
This work allows IPv6 access to IPv4 applications through a translator
installed in the target host. There was some question as to whether this work
could progress as is, and whether it should be Informational or Experimental.
This will be pursued on the mailing list by the author. The presentation is
available at <http://www.hitachi.co.jp/Prod/comp/network/pexv6-e.htm>
___
Hiroshi Kitamura from NEC and Shinji Kobayashi from Fujitsu jointly presented
their work on "SOCKS5 based Transition Technology" which has been published as
<draft-kitamura-socks-ipv6-trans-arch-00.txt> and as
<draft-jinzaki-socks64-00.txt> (co-Author Akira Jinzaki from Fujitsu). This
presentation is available at
<http://www.v6.wide.ad.jp/Presentations/ietf43-ngtrans-socks/>. The three
authors will now decide how to jointly prepare an I-D for processing either as
Informational or Experimental RFC.
___
Hossam Afifi presented "A Dynamic Tunneling Interface"
<ftp://ftp.rennes.enst-bretagne.fr/pub/network/draft-toutain-dti-00.txt>
(co-author Laurent Toutain from ENST-Bretagne). The motivation for the work was
to make the smallest number of modifications to applications and components to
communicate between IPv4 and IPv6 applications. IPv4 packets from the
application are intercepted in a dynamic tunnel interface (dti) library to look
in DNS to see if there is an IPv6 destination address, and a dynamic v4 in v6
tunnel is set up. The authors will submit their I-D as an ngtrans draft and
circulate it on the mail list for comment. This work would presumably be
eventually processed as an Experimental RFC.
___
Brian Carpenter from IBM presented his ideas for "A '624' TLA for Automatic
Tunneling". The concept being that a special TLA would be allocated to indicate
that the NLA 32-bit field below it contained the IPv4 address for an IPv6 over
IPv4 tunnel endpoint to be used in communicating with the host so advertising
that IPv6 address.
Presumably this would be done by hosts with no direct IPv6 connectivity between
them. Thus if a TLA=624 was discovered by DNS lookup, IPv6 packets could be
automatically encapsulated in IPv4 protocol 41 tunnels to the IPv4 address in
the NLA portion of the TLA=624 address.
It is believed that there is no impact to IPv6 routing tables. When IPv4 goes
away then these prefixes would also. One open issue identified is that you
could not use these addresses for multicast.
Brian will formulate this into an I-D and circulate it.
___
Laurent Toutain presented his work on "Manipulating the 6bone Registry Objects
Through a Web Interface", work which will integrated with David Kessens' IPv6
registry work. This effort should make the process of IPv6 sites managing and
updating their objects much easier. This work is very helpful to all!
___
Bob Hinden discussed the Sub-TLA block allocation I-D
(draft-ietf-ipngwg-iana-tla-00.txt) that was written jointly by the ngtrans and
ipng WG chairs to advise the IANA on initial Sub-TLA allocations to APNIC, ARIN
and RIPE-NCC. It is hoped that this I-D will allow the initial Sub-TLA registry
assignment process to continue to successful conclusion in the first quarter of
1999.
___
David Kessens gave a brief update of the 6bone. There are now 51 6bone
backbone sites and a total of 332 6bone sites in 39 countries. The registry is
seeing 1700 queries and 8 updates a day. David announced that he has moved to
Quest, and that Quest has agreed to have him move the 6bone registry from ISI
to Quest. Thanks as always to David, and now Quest, for his fine efforts on
IPv6 registries.
___
Ivano Guardini from CSELT gave an update of 6bone backbone routing activity and
analysis by CSELT. Since the last IETF he has been collecting BGP4+ routing
information provided by ASpath-tree. The BGP4+ routing table of their border
router is downloaded and analyzed every 5 mins. Then 6bone routing behavior is
measured in terms of number of advertised prefixes, overall route availability
and overall route unstability.
These studies are showing increasing pTLA route availability, and an
unstability of 2.5%. These studies are from CSELT's perspective, and Ivano
would like others to join in analyzing this data from their sites perspective.
Please contact him at ivano.guardini@cselt.it or Paolo Fasano at
paolo.fasano@cselt.it.
The reports and other information is available through
<http://carmen.cselt.it/ipv6/index.html>.
Thanks also to Ivano for his fine efforts on helping us understand the
stability of routing on the 6bone.
___
Rob Rockell presented his views on the need to tighten 6bone backbone routing
policing, and for everyone to follow the 6bone Routing Practices I-D rules.
He discussed why good 6bone routing policy is needed for proper IPv6 testing,
to figure out multi-homing problems, and downstream routing policy concerns.
Policy is needed between pTLAs as addresses aren't portable, and routing is
supposed to be simple and aggregated.
He strongly encouraged 6bone pTLA peers to accept only top-level aggregates
(i.e., /24s) and reject anything more specific. Only accept more than your
neighboring peer pTLA if agreed upon for providing transit for other pTLAs.
Also, pTLAs should not pass on things that cause trouble, don't waste the BGP
and line sending unaggregated routes. Therefore, only send your aggregates and
whatever other pTLAs you want to give transit for.
Do not allow more specific routes.
Only allow the space that you have delegated (to NLAs below you) to be
announced up through you into your AS.
Allowing other TLA space through your routing domain disables the good value of
the iPv6 addressing hierarchy.
___
Bob Fink from ESnet presented the new 6REN production IPv6 Research and
Education Networks (RENs) initiative. The 6REN is not a network like the 6bone,
rather a collaborative effort, sponsored and established by ESnet, to move RENs
to production IPv6 service as soon as possible to allow momentum to be
maintained in the release of IPv6 in production systems and routers, and to
facilitate getting applications operational over IPv6.
The 6REN effort started in October with production native IPv6 over ATM
peerings between ESnet, vBNS, CAIRN and CA*net2. As soon as the regional
address registries can allocate Sub-TLAs to these networks (which they have
requested), they will renumber out of 6bone space.
The 6ren is a no cost, open to all, initiative, including for-profit production
IPv6 networks. It is not an IETF activity, though it will present information
as appropriate to the ngtrans WG to assist in transition activities.
-end
--=====================_464915961==_.ALT
Content-Type: text/html; charset="us-ascii"
<html>
Minutes of NGtrans WG Meeting<br>
8 December 1998<br>
Orlando IETF<br>
<br>
Chairs: Bob Fink fink@es.net<br>
Tony Hain tonyhain@microsoft.com<br>
<br>
This ngtrans meeting reported by Alain Durand, Bob Fink and Tony
Hain<br>
<br>
Attendance: 170 signed in, estimated at 200 actually present<br>
________________________________________________________________<br>
Administrative information:<br>
<br>
Discussion ngtrans: ngtrans@sunroof.eng.sun.com<br>
Subscribe ngtrans: majordomo@sunroof.eng.sun.com
"subscribe ngtrans"<br>
Archive ngtrans:
<a href="ftp://playground.sun.com/pub/ngtrans" eudora="autourl">ftp://playground.sun.com/pub/ngtrans</a><br>
Web
site:
<a href="http://www.6bone.net/ngtrans.html" eudora="autourl">http://www.6bone.net/ngtrans.html</a><br>
<br>
Discussion 6bone: 6bone@isi.edu<br>
Subscribe 6bone: majordomo@isi.edu
"subscribe 6bone"<br>
Archive ngtrans:
<a href="http://www.ipv6.nas.nasa.gov/6bone/" eudora="autourl">http://www.ipv6.nas.nasa.gov/6bone/</a><br>
Web
site:
<a href="http://www.6bone.net/" eudora="autourl">http://www.6bone.net</a><br>
<br>
<br>
___<br>
<br>
The chairs announced there will be a joint ngtrans/ipng interim meeting
in the San Francisco area in early February for future planning of IETF
IPv6 work. Further revisions to the ngtrans charter will await these
discussions and due process in the WG. An announcement will be made to
all the mail lists as soon as possible as to time and place.<br>
<br>
Bob Gilligan has resigned as a co-chair of ngtrans due to other
commitments. The continuing co-chairs would like to thank Bob for all his
past IPv6 work, for the IPng WG and NGtrans WG. Newcomers should be aware
that Bob helped craft IPv6's excellent Transition Mechanisms concepts and
architecture.<br>
<br>
___<br>
<br>
Erik Nordmark from Sun concluded discussion on the I-D for replacement of
RFC 1933 (Transition Mechanisms) and will proceed with a last call on
this work. Items that will be included in the -01 to -02 version of the
I-D are:<br>
<br>
Will add clarification that configured tunnels can be unidirectional or
bidirectional.<br>
<br>
Will add description of bidirectional virtual links as another type of
tunnel, and that nodes MUST respond to NUD probes on such links and
SHOULD send NUD probes.<br>
<br>
Will add reference to [6over4] work.<br>
<br>
Will clarify that IPv4-compatible addresses are assigned exclusively to
nodes that support automatic tunnels.<br>
<br>
Will add text about formation of link-local addresses and use of Neighbor
Discovery (ND not used on unidirectional links.)<br>
<br>
Will add restriction that decapsulated packets not be forwarded unless
the source address is acceptable to the decapsulating router.<br>
<br>
___<br>
<br>
Announced conclusion of last call for SIIT, which will now be forwarded
for IESG processing as Experimental RFC.<br>
<br>
___<br>
<br>
Discussed WG last call for NAT-PT Experimental RFC forwarding with
agreement that the author would cleanup references to, and duplication
of, SIIT work. Then another last call will be done.<br>
<br>
___<br>
<br>
Announced conclusion of last call for 6bone Routing Practices, which will
now be forwarded for IESG processing as Informational RFC.<br>
<br>
___<br>
<br>
Kazu Yamamoto from the Internet Initiative Japan gave a presentation on
"Categorizing Translators Between IPv4 and IPv6"
<<a href="http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-translator-00.txt" eudora="autourl">http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-translator-00.txt</a>>
(co-author is Munechika Simikawa from Hitachi). This work has value to
the transition activity as an Informational RFC, so this will be explored
with the authors.<br>
<br>
___<br>
<br>
Kazuaki Tsuchiya from Hitachi gave a presentation on "Dual Stack
Hosts Using the Bump-in-the-Stack Technique"
<<a href="http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-dual-stack-hosts-00.txt" eudora="autourl">http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-dual-stack-hosts-00.txt</a>>
(co-authors are Hidemitsu Higuchi and Yoshifumi Atarashi, also from
Hitachi). This work allows IPv6 access to IPv4 applications through a
translator installed in the target host. There was some question as to
whether this work could progress as is, and whether it should be
Informational or Experimental. This will be pursued on the mailing list
by the author. The presentation is available at
<<a href="http://www.hitachi.co.jp/Prod/comp/network/pexv6-e.htm" eudora="autourl"><font color="#0000FF"><u>http://www.hitachi.co.jp/Prod/comp/network/pexv6-e.htm</a></font></u>><br>
<br>
___<br>
<br>
Hiroshi Kitamura from NEC and Shinji Kobayashi from Fujitsu jointly
presented their work on "SOCKS5 based Transition Technology"
which has been published as
<draft-kitamura-socks-ipv6-trans-arch-00.txt> and as <br>
<draft-jinzaki-socks64-00.txt> (co-Author Akira Jinzaki from
Fujitsu). This presentation is available at
<<a href="http://www.v6.wide.ad.jp/Presentations/ietf43-ngtrans-socks/" eudora="autourl"><font color="#0000FF"><u>http://www.v6.wide.ad.jp/Presentations/ietf43-ngtrans-socks/</a></font></u>>.
The three authors will now decide how to jointly prepare an I-D for
processing either as Informational or Experimental RFC.<br>
<br>
___<br>
<br>
Hossam Afifi presented "A Dynamic Tunneling Interface"
<font color="#0000FF"><<a href="ftp://ftp.rennes.enst-bretagne.fr/pub/network/draft-toutain-dti-00.txt" eudora="autourl"><u>ftp://ftp.rennes.enst-bretagne.fr/pub/network/draft-toutain-dti-00.txt</a></u>></font>
(co-author Laurent Toutain from ENST-Bretagne). The motivation for the work was to make the smallest number of modifications to applications and components to communicate between IPv4 and IPv6 applications. IPv4 packets from the application are intercepted in a dynamic tunnel interface (dti) library to look in DNS to see if there is an IPv6 destination address, and a dynamic v4 in v6 tunnel is set up. The authors will submit their I-D as an ngtrans draft and circulate it on the mail list for comment. This work would presumably be eventually processed as an Experimental RFC.<br>
<br>
___<br>
<br>
Brian Carpenter from IBM presented his ideas for "A '624' TLA for Automatic Tunneling". The concept being that a special TLA would be allocated to indicate that the NLA 32-bit field below it contained the IPv4 address for an IPv6 over IPv4 tunnel endpoint to be used in communicating with the host so advertising that IPv6 address. <br>
<br>
Presumably this would be done by hosts with no direct IPv6 connectivity between them. Thus if a TLA=624 was discovered by DNS lookup, IPv6 packets could be automatically encapsulated in IPv4 protocol 41 tunnels to the IPv4 address in the NLA portion of the TLA=624 address. <br>
<br>
It is believed that there is no impact to IPv6 routing tables. When IPv4 goes away then these prefixes would also. One open issue identified is that you could not use these addresses for multicast.<br>
<br>
Brian will formulate this into an I-D and circulate it.<br>
<br>
___<br>
<br>
Laurent Toutain presented his work on "Manipulating the 6bone Registry Objects Through a Web Interface", work which will integrated with David Kessens' IPv6 registry work. This effort should make the process of IPv6 sites managing and updating their objects much easier. This work is very helpful to all!<br>
<br>
___<br>
<br>
Bob Hinden discussed the Sub-TLA block allocation I-D (draft-ietf-ipngwg-iana-tla-00.txt) that was written jointly by the ngtrans and ipng WG chairs to advise the IANA on initial Sub-TLA allocations to APNIC, ARIN and RIPE-NCC. It is hoped that this I-D will allow the initial Sub-TLA registry assignment process to continue to successful conclusion in the first quarter of 1999.<br>
<br>
___<br>
<br>
David Kessens gave a brief update of the 6bone. There are now 51 6bone backbone sites and a total of 332 6bone sites in 39 countries. The registry is seeing 1700 queries and 8 updates a day. David announced that he has moved to Quest, and that Quest has agreed to have him move the 6bone registry from ISI to Quest. Thanks as always to David, and now Quest, for his fine efforts on IPv6 registries.<br>
<br>
___<br>
<br>
Ivano Guardini from CSELT gave an update of 6bone backbone routing activity and analysis by CSELT. Since the last IETF he has been collecting BGP4+ routing information provided by ASpath-tree. The BGP4+ routing table of their border router is downloaded and analyzed every 5 mins. Then 6bone routing behavior is measured in terms of number of advertised prefixes, overall route availability and overall route unstability. <br>
<br>
These studies are showing increasing pTLA route availability, and an unstability of 2.5%. These studies are from CSELT's perspective, and Ivano would like others to join in analyzing this data from their sites perspective. Please contact him at ivano.guardini@cselt.it or Paolo Fasano at paolo.fasano@cselt.it.<br>
<br>
The reports and other information is available through <<a href="http://carmen.cselt.it/ipv6/index.html" eudora="autourl"><font color="#0000FF"><u>http://carmen.cselt.it/ipv6/index.html</a></font></u>>.<br>
<br>
Thanks also to Ivano for his fine efforts on helping us understand the stability of routing on the 6bone.<br>
___<br>
<br>
Rob Rockell presented his views on the need to tighten 6bone backbone routing policing, and for everyone to follow the 6bone Routing Practices I-D rules. <br>
<br>
He discussed why good 6bone routing policy is needed for proper IPv6 testing, to figure out multi-homing problems, and downstream routing policy concerns.<br>
<br>
Policy is needed between pTLAs as addresses aren't portable, and routing is supposed to be simple and aggregated.<br>
<br>
He strongly encouraged 6bone pTLA peers to accept only top-level aggregates (i.e., /24s) and reject anything more specific. Only accept more than your neighboring peer pTLA if agreed upon for providing transit for other pTLAs.<br>
<br>
Also, pTLAs should not pass on things that cause trouble, don't waste the BGP and line sending unaggregated routes. Therefore, only send your aggregates and whatever other pTLAs you want to give transit for. <br>
<br>
Do not allow more specific routes. <br>
<br>
Only allow the space that you have delegated (to NLAs below you) to be announced up through you into your AS. <br>
<br>
Allowing other TLA space through your routing domain disables the good value of the iPv6 addressing hierarchy.<br>
<br>
___<br>
<br>
Bob Fink from ESnet presented the new 6REN production IPv6 Research and Education Networks (RENs) initiative. The 6REN is not a network like the 6bone, rather a collaborative effort, sponsored and established by ESnet, to move RENs to production IPv6 service as soon as possible to allow momentum to be maintained in the release of IPv6 in production systems and routers, and to facilitate getting applications operational over IPv6. <br>
<br>
The 6REN effort started in October with production native IPv6 over ATM peerings between ESnet, vBNS, CAIRN and CA*net2. As soon as the regional address registries can allocate Sub-TLAs to these networks (which they have requested), they will renumber out of 6bone space. <br>
<br>
The 6ren is a no cost, open to all, initiative, including for-profit production IPv6 networks. It is not an IETF activity, though it will present information as appropriate to the ngtrans WG to assist in transition activities.<br>
<br>
-end<br>
<br>
</html>
--=====================_464915961==_.ALT--