Minutes of NGtrans WG Meeting 8 November 1999 Washington DC IETF46 Chairs: - Alain Durand Alain.Durand@imag.fr - Bob Fink rlfink@lbl.gov - Tony Hain tonyhain@microsoft.com This ngtrans meeting reported by Alain Durand, Bob Fink and Tony Hain. Attendance was estimated as 200+ (didn't actually count the names). Alain Durand chaired the meeting. Administrative information: Discussion ngtrans: Subscribe ngtrans: "subscribe ngtrans" Archive ngtrans: (I'll replace with the newer archive) Web site: Discussion 6bone: Subscribe 6bone: "subscribe 6bone" Archive 6bone: (I'll replace with the newer archive) Web site: Agenda Tokyo meeting network configuration - Jun-ichiro itojun Hagino BSD Update - Jun-ichiro itojun Hagino NGtrans Project Status - Bob Fink 6bone Prequalification for Address Prefix Allocation (6papa-00) - Bob Fink Transition strategy for transition documentation - Alain Durand 6to4 (6to4-03) - Brian Carpenter DSTM (dstm-00) - Jim Bound Tunnel Broker (broker-02) - Ivano Guardini Tunnel setup protocol - Marc Blanchet Bump-In-the-Stack (bis-00) - Kazuaki Tsuchiya IPv6 Operational Topics Meeting (minutes attached at end of these minutes) Tokyo meeting network configuration - Jun-ichiro itojun Hagino Itojun described the Tokyo IPng Interim WG meeting network configuration. This network was an IPv6 only network with four IPv6 prefixes advertised and three native IPv6 connections (NTT, IIJ, WIDE), plus an IPv6 to IPv4 translator. Statistics of the meeting's network use are: 80+ attendees 20+ nodes (= IPv6 nodes) in user segment 100 times more IPv6 traffic than IPv4 traffic! 1627 translated TCP connection 878 http, 846 SSL, 88 pop3, 46 telnet, 32 ssh, 16 smtp, 5 ftp 3ffe:501:0:18aa::x.y.z.u gets translated to x.y.z.u DNS server side hack will automatically enable it DNS needed IPv4 (root servers) Src/dst selection, default router selection Latter seems more important in this config BSD Update - Jun-ichiro itojun Hagino Itojun reported on the project to unify IPv6 for *BSD systems by consolidating the best parts of the three NRL, INRIA and KAME stacks. Due to incompatibilites beween the three the *BSD version it was decided to base the *BSD version on KAME, with inputs from NRL and INRIA. NRL and INRIA will also do future IPv6 experiments on KAME. Status: - NetBSD: merged KAME stack in June 1999, will ship in 1.5 - FreeBSD: KAME merge effort started, will ship in 4.x - OpenBSD: hope to incorporate KAME into 2.7 - BSDI: 4.0 has NRL code, will switch to KAME You will be able to buy KAME/FreeBSD-ready PC off the shelf! NGtrans Project Status - Bob Fink Bob gave a status review of NGtrans Projects based on the new ngtrans project status webpage that he will keep up-to-date as possible. It may be seen at: Bob reported on the BT IPR notification and that the next step will be to follow IETF procedures with no discussion in ngtrans until that is done. These procedures call for requesting more information of the IPR holder, in particular details of the IPR and whether they will give low/no-cost licenses for its use. After all available information is in hand, the working group can decide whether or not to proceed with any project that may be affected based on this information. 6bone Prequalification for Address Prefix Allocation (6papa-00) - Bob Fink Bob gave a brief overview of the 6papa-00 I-D which resulted from the IAB/IANA/RIR IPv6 Prefix Allocation policy process when it was agreed to allow the 6bone as a prequalification process for address prefix allocation as a part of the RIR bootstrap process. See: , section 4.1.1: "... The requesting organization must demonstrate that it has experience with IPv6 through active participation in the 6bone project for at least six months, during which time it operated a pseudo-TLA (pTLA) for at least three months. The Regional IRs may require documentation of acceptable 6Bone routing policies and practice from the requesting organization." Bob noted that the RIRs are asking him (as 6bone lead and ngtrans co-chair) to validate if a subTLA requestor meets the 6bone pTLA requirements, to which he factually replies, not saying whether the requestor should get a subTLA, just that they meet the requirements agreed to by the above policy and the 6bone's own pTLA rules. Bob asked for consensus from the ngtrans/6bone community for the early RIR agreement by moving it into Informational RFC form and support for him to continue to handle the requests from the RIRs for this for now. Then in addition, help in setting up a 6bone steering group for this purpose so it's not just one person doing it. As next steps, Bob will issue a cleaned up 6papa draft (-01) for comment on the ngtrans and 6bone lists, and probe the 6bone list re the formation of a 6bone steering group for RIR request recommendations process. Transition strategy for transition documentation - Alain Durand Alain presented his ideas on the structure of transition for purposes of writing a transition document. See: Jim Bound asked Alain to remove his comment in the slides about 'no dns trick', as he claimed that customers have asked for it. Alain said that this will be released as separate document, or added to roadmap, TBD. The slides above show Jim's change. 6to4 (6to4-03) - Brian Carpenter Brian reported on the substantive changes from -02: Substantive Changes from -02 - changed to officially assigned TLA value - sections of text re-ordered for clarity - "do not fragment" is now SHOULD NOT (adopting the decision reached for 6over4) - new version of address selection text - bogus MTU text deleted - a few additional scenarios and pictures - clarifications/response to detail comments Issues: - Address selection text needs revision when general WG debate is settled; precedence for 6to4 versus native addresses needs to be configurable. - Concern that routing loops must be shown to be impossible by construct (Randy Bush) - Concern that multicast routing needs more precision (Erik Nordmark) - Some people object to referring to a "6to4 interface" and others object to calling it a "pseudo-interface" (Draves, Nordmark,…) - Some people object to discussing BGP and routing updates at all (Bound et al) - Sending rule needs to cover next-hop as well as final destination (Bound et al) - Need to clarify that IPv4ADDR = link layer address (Bound et al) - Bugs in alignment and padding text (Bound et al) - some other clarification/explanation points (Bound et al) - terminology section and applicability statement - host-only model and draft Brian noted that comments on address selection are deferred until the outcome of IPng WG work on this. A comment was made that Randy's concern about about routing loops be 'impossible' is too strong. A comment was made that there needs to be clarity between text and potential implementations. - v4 is link layer leads to interface rather than pseudo Jim Bound commented that either cover BGP fully or don't mention it at all. Brian asked Jim when the rest of his group's comments would come on 6to4 as he had noted in the original comments he made that there would be more. Jim replied that 2 weeks. Brian noted that he would like to have an additional co-author due to his and Keith Moore's time constraints. Steve Deering that 6to4 is not a complete solution: dns, basic mechanisms, need to make sure doc is clear about applicatbility, terminology needs to be added, and may need additional specs for host implementations. It was noted that several implementations were in progress. Perry Metzger wanted *bsd as default stack implementation. Jim Bound noted his company is moving into production mode to ship. ; linux focus Steve Deering noted that boundary routers are the implementation target not host. Bob Fink noted that a 6to4 relay was being agressivly worked for the 6tap. DSTM (dstm-00) - Jim Bound Jim Bound gave a high level overview of the DSTM-00 draft recently issued, noting that it is integrated DTI and AIIH. Jim promised a new draft soon with reworked diagrams and other improvements. He will submit extensions to the DHCPv6 wg. He hopes to be able to send DSTM to the IESG for PS in July, 2000. Brian Carpenter asked Jim to describe the remaining relationship to dns? Jim said there is a gethostnymane call, the AIIH server returns a cname, which will be forwarded to site to the site dns which concatenates it. Alain Durand asked will the dns part be 'required' to be DSTM. Jim responded that needs to be discussed. Jim expressed his desire to have no translators be PS. When asked if there are any implementations, Jim responded that there is one partially done that might be done in a few months. Tunnel Broker (broker-02) - Ivano Guardini Ivano gave a tunnel broker status report. See: Ivano asked for links to be placed on well know pages for the tunnel brokers so they can be easily found. Perry Metzger said that he will put one on v6.org right after this meeting. Tunnel setup protocol - Marc Blanchet Marc presented his ideas for tunnel setup: He noted that tunnel broker uses scripts which have many limitations. Peter Tattam's protocol have some limitations, one of them is the fact that the authentication scheme is fixed, and negociation between client and server is limited. His proposal is to extend the Peter Tattam's protocol. Marc was encouraged to update the draft for submission as an ngtrans draft. Jim Bound asked why not use DHCPv6. MArc was concerned about the time to resolve DHCPv6 and/or to add to it. Marc was concerned about how a host can send dhcp queries over the IPv4 Internet without a dhcp relay. Perry Metzger noted that you need to add a DHCPv6 request in v4 packet. Erik Nordmark noted that, compared to DHCP, this proposal is useful because it takes care of authentication. Introduction to IPv6 Transition (iit-02) - Henk Steenman Henk noted that the -02 version included Tim Larder's independent draft, as well as adding examples & tools. He expecgts completion at the next IETF. Brian Carpenter noted that the Utrecht meeting recommendation wants ngtrans to address evolution from a NAT-based IPv4 world as well. Alain Durand noted that one scenario had included NAT. Perry Metzger noted that ISPs may be blocking some protocol types, which affects use of tunneling. He noted that GRE over UDP as a tool needs a standard port number. Bump-In-the-Stack (bis-00) - Kazuaki Tsuchiya It was noted that bis-oo will be forwarded to the IESG after this IETF. Kazuaki kindly abbreviated his presentation due to limited meeting time to speak of only the recent Toolnet6 Installation Workshop held during the IETF IPng Interim Meeting in Tokyo last month. Toolnet6 is a transition tool based on the BIS draft. An early realease of the new version was given to participants, including in its features Stateless Address Autoconfiguration and a DNS resolver function via IPv6. All participants succeeded in the installation of Toolnet6, which included 1 WinNT and 4 Win98 users. Meeting adjourned. IPv6 Operational Topics meeting IETF46 in Wash DC 11 November 1999 Organizers: Bob Fink Marc Blanchet This ngtrans meeting reported by Marc Blanchet and Bob Fink. Attendance was estimated as 75-100. Bob Fink chaired the meeting. This meeting is actually part of the ngtrans/6bone activity, but designed to focus a little more on general operational topics beyond just the 6bone, e.g., 6REN and other early production IPv6 nets, hence the title "IPv6 Ops Topics". Bob Fink asked attendees if they had any preference as to how this meeting be held in future IETFs. Matt Crawford suggested under the IEPG, to which Bob noted that he and Marc had given some IPv6 presentations at at this IETF, but was not sure this was the best time as there is limited attendance on Sundays. Zombie routes in 6bone Ikuo Nakagawa and Kunihiro Ishiguro spoke on the phenomenon they called Zombie routes, which are non-aggregated routes that happened to be announced from somewhere, but not actually the neighbor forwarding them, and they are not even in the ASpath. The behavior is that the originator has announced once, but no more announce it, but someone propagates infinitely. It is most liekly a bug in some routing code. To fix one has to find which site and then find which code they run and then upgrade ASAP. Marc Blanchet noted that we should not fingerpoint at people, rather we should try to collaborate, as we always have on the 6bone. Francis Dupont pointed out the need to move to the latest BGP4+ draft. Ivano Guardini commented that aggregration has to be fixed as it is currently very poor. Rob Rockell commented that most problems can be fixed by filtering. He asked if we should do a draft on how to filter? William Maton note that onecould use the registry and RPSL to help filtering. 6bone Registry David Kessens noted that he would like to soon provide a web interface to help people filtering in config files, which is work that Marc Blanchet and the Viagenie folk have done. Joao Damas, RIPE NCC, noted that the inet6num object is used by RIPE-NCC and APNIC, but not ARIN at this time. David Kessens noted that a subgroup of db-rpsl works on the ipv6 features in the current registry. In reference to keeping RIR ipv6num data commonly available in the 6bone registry, David said he will do a script to automatically fetch v6 objects from the RIR registries. Alain Durand commented that if we provide tools for filtering, then people will be interested in updating their objects. Wilfried Woeber commented that instead of throwing away problems by upgrading software, we should fix the problems. WIDE IPv6 addressing architecture Kengo Nagahashi presented an overview of the WIDE IPv6 addressing architecture. The WIDE production subTLA (2001:200::/35) has been divided into 2 spaces: - NLA1 divided at /41 for ISPs - NLA2 divided at /48 for end-sites - 2001:200:0::/48 is used for the backbone Use policies are: - not for commerce - do not connect to grand-children orgs - must announce aggregated routes - must report the status of IPv6 utilisation of each org - must update registry database 6PAPA Bob Fink noted that he had written the 6papa-00 I-D (under ngtrans) to formalize the RIR-6bone pre-qualification process. An updated version will follow soon which will be then sent to WG last call for forwarding to the IESG as an Informational RFC. NSPIXP-6 v6 exchange in Japan Akiro Kato gave an overview of the NSPIXP-6 IPv6 exchange in Japan. - experimental purpose: route server, IX-based address - single FE switch - 5 ISPs connected: 2 sTLAs, 2 NLA1s - extensions via ATM/FE bridge, using ATM network via apan/transpac to - startap, to Korea, Singapore and Malaysia It was noted that there are v6-exchanges at: - 6tap, Chicago NAP/STAR TAP - ISI-LA v6 Exchange - NSPIXP-6, Japan - AMS-IX - Amsterdam/ND - plans for New York/US, Palo Alto/US PingERv6 Bob Fink briefly noted that the US Energy Research PingER (over IPv4) project lead by SLAC now supports IPv6. Ping statistics are gathered with extensive data basing, analysis and graphical display. Bob asked people to send host addresses to be pinged, or ping sources, as had been previously announced on the 6bone list.