Minutes of NGtrans WG Meeting 27/29 March 2000 Adelaide IETF-47 ___ Chairs: Alain Durand Bob Fink Tony Hain This ngtrans meeting reported by Bob Fink and Tony Hain. Attendance was ~150. Alain Durand & Bob Fink chaired the meeting. ___ Administrative information: Discussion ngtrans: Subscribe ngtrans: "subscribe ngtrans" Archive ngtrans: Web site: Discussion 6bone: Subscribe 6bone: "subscribe 6bone" Archive 6bone: Web site: ___ Agenda Project status report - Bob Fink BT Patent IPR status - Bob Fink MECH-04 update status - Erik Nordmark 6to4-04 new draft - Brian Carpenter DSTM-01 new draft - Laurent Toutain SOCKS-03 new draft - Hirsohi Kitamura TRANSLATOR-03 new draft - Kazu Yamamoto BROKER-02 - Ivano Guardini Tunnel Discovery - ALain Durand TCPUDP-RELAY-00 new draft - Jun-ichiro itojun Hagino TRANSITION-03 new draft - Alain Durand 6PAPA-01 new draft - Bob Fink pTLA-00 new draft - Bob Fink ABUSE-00 new draft - Jun-ichiro itojun Hagino Interim NGtrans meeting planning - Alain Durand & Bob Fink PingERv6 Report - Les Cottrell Relocated 6bone registry - David Kessens 6tap report - Florent Parent pTLA reliability report - Ivano Guardini Root name server issues - Akira Kato --- Project status report - Bob Fink Bob presented the status of all ngtrans projects from the ngtrans web site's project status pages: Let Bob know of any errors. --- BT Patent IPR status - Bob Fink Bob Fink related the background and current status of the BT patent issue. 1. BT notified the IETF Secretariat on Nov 5, 1999 that: "In accordance with the IETF Rules, BT would like to disclose that we have recently applied for patents in the IPv6 space relating to: * the establishment of tunnels using DNS as the tunnel endpoint discovery mechanism and * a mechanism that enables translation and tunneling to be combined into a single device. BT does so in the belief that these recent patent application are relevant to present discussions within the IETF." 2. After the IETF Secretariat queried BT, a reply was received on Nov 12, 1999, saying: "Also in accordance with IETF Rules, BT hereby gives the assurance that, following approval by the IESG of the relevant Internet standards specification, BT will grant licences under these patent applications and under any resultant patents, on openly specified, reasonable and non-discriminatory terms, to implement the Internet standards specifi- cation, provided the licensee similarly grants licences under its necessary applications/patents." 3. BT is under no responsibility to say more about their possible patents than they already have. 4. From the information on hand, or likely to become available, there is no clear way of telling if any work now underway in ngtrans is possibly affected by BT patents. 5. If any ngtrans work eventually is covered by BT patents, BT's assurance to grant licenses is minimally acceptable according to Steve Coya, IETF Secretariat: "Note that during the Stockholm meeting, the concept of determining whether the licensing was openly specified, reasonable and non-discri- minatory terms would be based on implementor feedback (i.e. if enough folks entered into an agreement, that would be sufficient to "prove" or demonstrate that the licensing arrangements were palatable. This will be treated like an option when/if the protocol is submitted for consideration as a Draft Standard." 6. Thus there is no reason to do other than proceed with all work now underway in ngtrans. Not hearing anything to the contrary, Bob declared the BT issue closed for now. --- ABUSE-00 new draft - Jun-ichiro itojun Hagino Itojun gave a report of potential abuses to IPv6 transition mechanisms that is available at: The document talks about possible abuse of IPv6 transition technologies, which may lead to denial-of-service (DoS) attacks and other problems. IPv6 transition technologies, namely IPv6 over IPv4 tunnelling speci- fications and some others, have room for abuse by malicious parties. Detailed descriptions and possible workarounds are supplied. The specific areas of problems noted were: Abuse of IPv4 compatible address Abuse of 6to4 address Abuse of IPv4 mapped address For which he gave possible solutions (see the paper). His recommendations to future proposals were: If you use tunnels, require explicit configuration Manual configuration Authenticated automatic configuration Don't put IPv4 address into IPv6 address, for purpose of relays Do not define IPv6 addresses that are not used on the wire Makes it much harder to check and his summary: Bad guys can abuse some of transition techniques Don't run 6to4/auto tunnel relay, if you don't need one Be careful about v4 mapped address What to do next? Incorporate checks presented here, into original proposals Publish it as separate document (informational?) Let us check other proposals as well Let us deploy native IPv6 network sooner, so that we no longer need tunnels --- MECH-04 update status - Erik Nordmark Erik noted changes he has made to MECH-04 in preparation for MECH-05. - Specified when to put IPv6 addresses in the DNS. - Added reference to the tunnel mib for TTL specification for the tunnels. - Added recommendations for use of source and target link layer address options for the tunnel links. - Added checks in the decapsulation checking both an IPv4-compatible IPv6 source address and the outer IPv4 source addresses for multicast, broadcast, all-zeros etc. Erik will issue MECH-05 as soon as he can (already done on April 6 and a wg last call issued). --- 6to4-04 new draft - Brian Carpenter Brian presented the changes from -03 to -04 and highlighted issues remaining. CHANGES • added terminology section • another revision of address selection text • described link local address formation • changed sending rule to refer to next hop • removed confusing text on IPv4 header padding • clarification/corrections to exterior routing discussion (scenarios with & without BGP) • clarified MTU text again • added section on routing loops • added and removed text on multicast • added text on RSIP • reformulated section on Intranet usage (use of Net 10 addresses now forbidden) • clarifications/response to detail comments ISSUES • text on PIM-SM needs checking by a PIM-SM expert • Is link-local address really needed? • host-only draft: volunteer needed • Is this ready for PS? Brian thanked Jim Bound's group for their comments. Regarding link local there was a debate about its need. Itojun argued that it wasn't necessary, and it was agreed to pursue this discussion on the list. There was discussion of the need to rewrite the multicast section. Steve Deering was asked to comment on PIM-SM usage in 6to4. He felt that the problem generalized to the NBMA network case, noting that MARS was the state-of-the-art in this regard. There was concern about the applicability of IPv4 tools in the IPv6 space There was a call for review of the multicast section by experts. Brian noted that the security section already talks about ingress filtering in regards to Itojun's abuse concerns (covered earlier in these minutes). Brian stated that he would like to try to move 6to4 to PS before Pittsburgh. --- DSTM-01 new draft - Laurent Toutain Laurent made a few comments on the new DSTM-01 draft and DSTM status in general: • cleaned up text • 6->4 is mandatory • 4->6 is optional • 4->4 is optional • implementation in bsd (inria) • dhcpv6 concurrent work : only 4 messages needed • modify dns when v4 query fails • question about timeouts : timer in dstm based on pool • will use implementations to adjust timers : new text next time --- SOCKS-03 new draft - Hirsohi Kitamura Hiroshi gave a status report on the new -03 draft: • IESG comments were incorporated into -03 • there are two available independent implementations NEC: KAME: • there are about 5000 downloads/year of the SOCKS code from 80 different countries • a -04 will be out soon to answer other comments --- TRANSLATOR-03 new draft - Kazu Yamamoto Kazu gave a status report on the new -03 draft called Overview of Transition Techniques for IPv6-only to Talk to IPv4-only Communication, which was previously called Categorizing Translators between IPv4 and IPv6 Background • The previous version "02" was published in Oct 1999 • Comments from IESG in Dec 1999 Wording Bilingual -> dual-stack Proxy -> application level gateway Definition of "translator" is unclear Weakness Some explanations in this memo are not applicable to SIIT (FTP, IPsec, ...) SOCKS5 is not TCP-relay Situation is changing This draft was based on a paper of INET 1998 (written in 1997) It is getting harder to modify IPv6 hosts • Version "03" was published in Mar 2000 Differences between -02 and -03 • Title OLD: Categorizing Translators between IPv4 and IPv6 NEW: Overview of Transition Techniques for IPv6-only to Talk to IPv4-only Communication • Wording Defined "translator" in this memo an intermediate component between an IPv4 host and an IPv6 host to enable direct communication between them, without requiring any modifications to them • Accepted IESG's comments • Assumption OLD: We can change IPv6 hosts as we like NEW: It is difficult to change IPv6 hosts Outside the scope SOCKS5 SIIT BIS Mechanisms requiring specific functionality for IPv6 hosts • Address mapping: OLD: Suggested to use both DNS hack and resolver hack NEW: Suggest to use DNS hack only Resolver hack means changing IPv6 hosts Next step • Authors hope: to publish it as Informational RFC then to help the ROADMAP document project Kazu asked the chairs to please return -03 to the IESG to continue processing there towards Informational RFC. --- BROKER-02 - Ivano Guardini Ivano gave a status report of the older -02 draft: • WG last call after Washington IETF • One comment about MIME type • -02 draft not updated yet • Plan A: Include MIME media-type definition in the document? Other WG may benefit from the MIME-type • Plan B: Publish framework as Informational Publish MIME-type as separate,informational RFC • Actions for Plan B Remove implementation section (appendix) Add short discussion as MIME-type as implementation option Open door for the use of Tunnel Broker concept in other areas Publish framework as Informational RFC Publish MIME-type description in a separate document • Proposed MIME type application/tunnel parameters: ipv6/ipv4 src,dst v4 & v6 address Tunnel management procedure TTL with sub-parameter TTL value something smarter? Textual description ... • a -03 draft will be published soon --- Tunnel Discovery - ALain Durand Alain presented his ideas on Tunnel Endpoint Discovery, exploring new directions: Granularity of tunnel end point discovery mechanism • Automatic tunnels: 1 host (/128) • 6over4: 1 host (/128) • Tunnel broker: typically 1 host (/128) • 6to4: 1 site (/48) • Might be a need for other granularity: /64, /56, /49 intra-site /35, /29, /24 wan Potential candidate: DNS... • DNS is a natural distributed model network administrators know DNS DNS can handle different levels of granularity • But: DO NOT CREATE ANY NEW RR TYPE DO NOT CALL DNS FOR EVERY SINGLE PACKET Tunnel End Point Discovery Process Steps 1. Source S sends a packet to D1, packet goes to exit router R, but R has no route for D1... 2. Router R uses DNS to discover Tunnel End Point (TEP) IPv4 address. It also discovers that TEP is responsible for P/24. There is a TTL associated to the DNS response. 3. Router R create a uni-directional tunnel to TEP and add a route for P/24 through that tunnel. Packets are routed to D1 using P/24 IPv6 infrastructure 4. Source S2 now sends a packet to D2. As D2 is part of P/24, router R already has a route for it. It does not need to do another DNS query. It routes the packet through the existing tunnel. 5. After TTL expires, router R delete the tunnel and the route for P/24 DNS mechanism • Dedicated reverse tree tunnel6.ip6.int • DNAME for delegation • Wildcard entries for PTR • Reserved label "tunnel6" tag prefix len Configuration example • Tunnel end point for 3ffe:0300::/24 is 129.88.26.7 \[x3ffe/16].tunnel6.ip6.int IN DNAME 16.tunnel6.6bone.net. \[x03/8].16.tunnel6.6bone.net. IN DNAME 24.tunnel6.imag.fr. *.24.tunnel6.imag.fr. IN PTR basta.imag.fr. basta.imag.fr IN A 129.88.26.7 Query example • Query: PTR for 1.0.0....0.0.3.0.e.f.f.3.tunnel6.ip6.int. • Response: 1.0.0....0.0.3.0.e.f.f.3.24.tunnel6.imag.fr. IN PTR basta.imag.fr. basta.imag.fr. IN A 129.88.26.7 At the end of Alain's presentation there were various comments: • that iesg needs to decide about ipv6.int • that using dns to do routing is a bad idea • that using dns for real-time services will fail • that using dns will be more painful than the account can absorb • that this needs service location & routing to make it work • question about what is better about this than 6to4 No conclusion was reached about the pursuit of this effort, stay tuned. --- TCPUDP-RELAY-00 new draft - Jun-ichiro itojun Hagino Itojun gave a presentation of his new draft called An IPv6-to-IPv4 transport relay translator: • Transparent TCP relay Has been used in firewall-oriented products like TIS gauntret • We can use it for IPv6-to-IPv4 translation • No extra configuration/code on end node • No tricky MTU issues • Stateful TCP relay box A TCP connection goes through single TCP relay box Can place multiple boxes against multiple clients • We have been using it for more than 3 years, working just great ... we thought we'd better document it • The talk will focus on: IPv6-to-IPv4 translation (IPv4-to-IPv6 is possible) TCP relay (UDP is also possible) Transparent TCP relays (IPv4-to-IPv4) • A originates TCP to X (A -> X) • TCP relay box hijacks the connection and terminate it at B (A -> B) • TCP relay box originates TCP to X (Y -> X) • TCP relay box relays content across two TCP connections • originating node (A) --> TCP relay box (as X, interface is B) address on IP header: A -> X • TCP relay box (Y) --> destination node (X) address on IP header: Y -> X Transparent TCP relays (IPv6-to-IPv4) • Reserve an IPv6 /64 prefix R6::/64, announce routes • A6 originates TCP to C6::X4 (A6 -> R6::X4) • TCP relay box hijacks the connection and terminate it at B6 (A6 -> B6) • TCP relay box originates TCP to X4 (Y4 -> X4) • TCP relay box relays content across two TCP connections • IPv6 TCP: originating node (A6) --> TCP relay box (as R6::X4, interface is B6) address on IPv6 header: A6 -> R6::X4 • IPv4 TCP: TCP relay box (Y4) --> destination node (X4) address on IPv4 header: Y4 -> X4 Address mapping • Similar to other translation techniques • Modified DNS server For installation to large site • Special entries in /etc/hosts For small installation • Modified resolver on the originating node Not recommended, modifying originating node makes it hard to deploy Multiple servers, for scalability/availability • Setup multiple TCP relay boxes • Assign different reserved prefix, advertise all of them • Present different fake address by DNS round-robin or alike Once TCP is established we don't change address pair • When B6/Y4 goes down, connections through D6/Z4 will be okay Notes • No need to care about path MTU/fragmentation issues Per-packet translation needs a great care • Need to care about urgent data • Can relay UDP Recognize UDP "connection" like NAT does • Can relay IPv4-to-IPv6 Address mapping issue • To relay FTP need to rewrite payload data • Access control is mandatory Malicious party can take advantage of it to anonymize connection • KAME has been using this for 3 years, works quite well Served 100+ nodes at ipngwg Tokyo interim meeting We have been using it in many occasions • Two "tricky" name server implementations exist totd/newbie {Free,Net,Open}BSD includes this FreeBSD 4.0: IPv6 enabled by default! Wrap-up • IPv6-to-IPv4 translation using TCP relays • Simple implementation, works very well • No change in end node - can serve any of existing IPv6 nodes • Would like to issue it as an informational RFC, to help future implementers Not a new protocol, fits best to informational • ngtrans project, or individual submission? • To try it out from terminal room: to your IPv4 133.138.1.134, telnet 3ffe:501:4819:ffff::133.138.1.134 ssh -v 3ffe:501:4819:ffff::133.138.1.134 Travels Adelaide -- Tokyo -- your place, may add delay Noted that it should refer to existing list of applications affected by nat It was agreed that ngtrans would take on this as a project. Tthere was some minor debate about whether it should be Informational or Standards track, which resulted in the chairs determining (for now) that Informational RFC was most consistent with other ongoing and past projects. --- TRANSITION-03 new draft - Alain Durand Alain gave a status report on the "roadmap" transition document effort: Update • New scenarii large new IPv6 network ISP • Update of all references • Clarification text on Tunnel Broker, Bis, BiAPI, 6to4, DSTM, OSPF, 6PAPA • Remove all mention to particular implementation New Structure 1. Introduction 2. General deployment issues 3. Basic transition mechanisms (RFC1933 & update) 4. The tools 4.1 connecting IPv6 islands 4.2 communication between IPv4 & IPv6 5 & 6. scenarii Work continues! --- 6PAPA-01 new draft - Bob Fink Bob noted that he had not issued a new draft for balloting, nor the 6bone steering committee, as the RIRs were now reviewing their IPv6 address allocation policies which could affect 6PAPA. Thus he will wait until it is clear that the 6bone prequalification for sub-TLA allocation will stay in place. --- pTLA-00 new draft - Bob Fink Bob reported that he had written the pTLA draft for the purpose of documenting existing pTLA/pNLA 6bone prefix formats, and would soon do a wg last call for Informational. --- Interim NGtrans meeting plannng - Alain Durand & Bob Fink Alain & Bob expressed the need to have an interim ngtrans meeting to: • review state of the tools for security issues & corner cases • recent proposals • explore new directions • industry evaluation It was proposed to hold it in the San Francisco area, probably hosted by Sun. Some possible dates were balloted for interest: ~4 for May 23-25 ~6 for May 30-31, June 1 (just after US memorial day) ~8 for June 6-8 (conflict in Japan) Sentiments seemed low on the need for an interim. The chairs agreed to continue looking into the viability of a meeting as well as when it might be, if one was held. Stay tuned. --- PingERv6 Report - Les Cottrell Bob Fink introduced Les Cottrell (of the US SLAC accelerator laboratory) noting that his group's efforts to use inexpensive and easily deployable methods to measure the quality of Internet paths had been highly successful for IPv4, and that Les' group at SLAC had extended them to IPv6. Les presented their work: PingER (for IPv4) • Simple active end-to-end ping monitoring • Main community is HENP & ESnet sites • 30 monitoring sites in 15 countries • 593 nodes at 424 sites in 72 countries • ~ 2200 pairs PingER6 (for IPv6) • A small amount of bandwidth is carved off ESnet connection to provide native IPv6 service to SLAC • Recompiled Linux 2.2.5-15 (Red Hat 6.0) kernel with IPv6 support • Downloaded & installed inet-apps (including ping) from inner.net and patch for glibc-2.1 systems • Wrote Perl module to provide IPv6 DNS lookup • Currently one monitoring site at SLAC • PingER6 has been an international effort • 6Bone and 6REN sites participating in 10 countries, 40 sites • Currently little knowledge of networks and connections. • Not surprisingly, same issues as the ipv4 Internet. Not enough bandwidth • but it is only experimental • How to persuade users to try it out ? Bob Fink big help in signing people up Contact warrenm@slac.stanford.edu to join PingER6 • Next steps Address concerns over security More Monitoring Sites • 6-Tap a good place for a PingER • China ? Les thanked all the sites who have participated. More Information requested from all possible participants •IEPM/PingER home site • Very interesting Polish 6BONE ping site Les was asked to discuss relationship to similar tools, and Les responded that PingER results were well aligned to special hardware solution, like Internet Surveyor, for a cheap solution. Les noted that icmp is treated differently, but that practice shows there is little affect in most places due to rate limiting. When this is observed to be a problem new target sites are chosen. He closed noting that the PingER6 efforts will continue and encourage all interested to participate. --- Relocated 6bone registry - David Kessens --- 6tap report - Florent Parent Florent reproted on the current status of the 6tap, which is jointly managed by Canarie/Viagenie and ESnet at the Chicago StarTAP. • a tunnel server will be installed next week as an extension of native IPv6 service to provide site-level tunnel support (as opposed to the tunnel brokers individual host tunnel support). • in addition, a route server & registry service will be developed solaris 8 server w/ATM to ESnet MRTd (Merit) IPv6 registry (Kessens) • next: 6to4 relay service & stats --- pTLA reliability report - Ivano Guardini Ivano gave a report on the reliability of routing in the 6bone: • bgp4+ monitoring effort • ~50% more prefixes announced than the pTLA list would suggest • unaggregated prefixes are the bulk: multi-homed leaking • filtering out nosiest sites: 80% of sites are almost always reachable • most stable plotted against most unstable: instability growing • upper bound of route instability for 80% of sites is less than 5% • stability is good for 80%: multihoming is a problem Results • The results of the CSELT's 6bone monitoring effort confirm that BGP4+ routing within the 6bone backbone has become highly reliable both with respect to stability and route availability • this in turn highlights the good level of maturity reached by the currently available IPv6 technology some other issues still need to be solved • multihoming is still a problem • A subset of these results is regularly updated at: === Root name server issues - Akira Kato Akiro gave a brief report on upcoming experimentation plans for the new BIND release in the root name servers • experimental operation is planned with a few servers which will be operational soon • separate box for v6 • 3ffe:000[1-d]::/32 for each server or use /24 or/28 to each server advertise /32 : may violate 6bone routing need to modify bgp pathlen filters Various comments and questions were made: • why special addresses? • are these unicast or anycast? • routing propagation is the issue: special addr not necessary • no room to add aaaa/a6 in 512 byte • is edns0 mandatory for ipv6 queries • ip6.int may be server as well • one or two servers operational soon • 512 mtu is bogus in v6 • deployment requires careful thought • don't worry about edns0 because it covers IPv4 requirements • separate roots proposed --- Meeting adjourned. -end