(ngtrans) draft minutes of NGtrans WG Meeting at IETF-47 in Adelaide

[Bob Fink <[e-mail]>]

NGtrans folk,

Enclosed are the draft minutes of the Adelaide ngtrans meetings. Please 
send any errors, omissions, changes, etc. directly to me.

Sorry for the delay, but have been on travel from Adelaide until this week.


Thanks,

Bob

=============================
Minutes of NGtrans WG Meeting
27/29 March 2000
Adelaide IETF-47
___

Chairs:

Alain Durand <[e-mail]>
Bob Fink <[e-mail]>
Tony Hain <[e-mail]>

This ngtrans meeting reported by Bob Fink and Tony Hain.
Attendance was ~150.

Alain Durand & Bob Fink chaired the meeting.

___

Administrative information:

Discussion ngtrans: <mailto: [e-mail]>
Subscribe ngtrans: <mailto: [e-mail]> "subscribe ngtrans"
Archive ngtrans: <http://www.wcug.wwu.edu/lists/ngtrans/>
Web site: <http://www.6bone.net/ngtrans>

Discussion 6bone: <mailto: [e-mail]>
Subscribe 6bone: <mailto: [e-mail]> "subscribe 6bone"
Archive 6bone: <http://www.wcug.wwu.edu/lists/6bone/>
Web site: <http://www.6bone.net>

___

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:

<http://www.6bone.net/ngtrans/ngtrans_project-status.html>

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:

<http://6bone.net/ngtrans/IETF47-Adelaide/draft-itojun-ipv6-transition-abuse 
-00a.txt>

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 was 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:  <http://www.socks.nec.com>
   KAME: <ftp://kame.net/pub/kame/misc/socks64-...>

• 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:
<http://6bone.net/ngtrans/IETF47-Adelaide/tep1.ppt>

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:

<http://6bone.net/ngtrans/IETF47-Adelaide/pinger61.ppt>

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 [e-mail] 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
<http://www-iepm.slac.stanford.edu/>

• Very interesting Polish 6BONE ping site
<http://6bone-gw.6bone.pl/mrtg/>


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

<http://www.6tap.net>

---

pTLA reliability report - Ivano Guardini

Ivano gave a report on the reliability of routing in the 6bone:

<http://6bone.net/ngtrans/IETF47-Adelaide/reliability-6bone.ppt>

• 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:
  <http://carmen.cselt.it/ipv6/bgp/graphs/index.html>

===

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