draft minutes of ngtrans wg meeting at LA IETF - 9Apr98 version

[Bob Fink]

6bone & ngtrans folk,

Here is our first draft of the ngtrans minutes from the LA IETF.

Please send me any comments by the 20th.


Thanks,

Bob

________________________________________________________________________
________________________________________________________________________

ngtrans WG meeting
March 31, 1988
Los Angeles, CA IETF

Chairs:       Bob Fink rlfink@lbl.gov
              Robert Gilligan gilligan@freegate.com
              Tony Hain tonyhain@microsoft.com

Reported by Bob Gilligan, Alain Durand and Bob Fink

________________________________________________________________________

ngtrans tools portion of meeting, chaired by Tony Hain

Discussion:   ngtrans@sunroof.eng.sun.com
Subscribe:    majordomo@sunroof.eng.sun.com  "subscribe ngtrans"
Archive:
<ftp://playground.sun.com/pub/ngtrans>ftp://playground.sun.com/pub/ngtrans>
<ftp://playground.sun.com/pub/ngtrans>ftp://playground.sun.com/pub/ngtrans

Web site:
<http://www.6bone.net/ngtrans.html>http://www.6bone.net/ngtrans.html><http:
//www.6bone.net/ngtrans.html>http://www.6bone.net/ngtrans.html


____

AIIH I-D- Jim Bound

Jim Bound gave an overview on his new Internet-Draft titled
"Assignment of IPv4 Global Addresses to IPv6 hosts (AIIH)".  Note that
the acronym for this proposal has changed from NNAT to AIIH.  This
Internet-Draft replaces the earlier NNAT I-D.

The general objective of this proposal is to allow IPv6/IPv4 dual
hosts configured with permanent global IPv6 and get temporary
assignments of IPv4 global addresses to use when communicating with
IPv4 hosts.  This conserves the IPv4 address space since a small pool
of global IPv4 addresses can be used by a larger number of IPv6/IPv4
hosts.  This proposal does NOT employ header translation.

The proposal uses an "AIIH server" situated at the boundary between an
IPv4 and an IPv6 cloud which operates both as a DNS and DHCP server.
The AIIH server handles IPv4 DNS queries for IPv6/IPv4 hosts; assigns
temporary IPv4 addresses to IPv6/IPv4 hosts, and manages tunnels to
IPv6/IPv4 hosts.  The IPv6/IPv4 hosts use DHCP to acquire their
temporary IPv4 addresses.  Two cases of communication are handled:

   1)   IPv6/IPv4 host initiating communication with an IPv4 host.
   2)   IPv4 host initiating communication with an IPv6/IPv4 host.

IPv4 packets between the IPv6/IPv4 host and the AIIH server can be
carried in three forms:

   1)   Tunneled in IPv6.
   2)   Tunneled in IPv4.
   3)   Carried as native IPv4 packets.

More details on this proposal can be found in Jim's slides are located
at:

<ftp://sipper.zk3-x.dec.com/pub/aatn_aiih_0498.zip>ftp://sipper.zk3-x.dec.c
om/pub/aatn_aiih_0498.zip
<ftp://sipper.zk3-x.dec.com/pub/ngtrans_aiih_0498.zip>ftp://sipper.zk3-x.de
c.com/pub/ngtrans_aiih_0498.zip

A few questions were raised in the discussion of this proposal:

   -    Someone asked what specific changes an IPv6 host implementation
        would need to make in order to implement AIIH.  Jim said that
        the primary change would be adding the facility to acquire an
        IPv4 address via DHCP when needed.

Jim would like feedback on this proposal now.  He plans on releasing
an updated version of this document before the Chicago IETF meeting.

____

NAT-PT I-D- George Tsirtsis & Pyda Srisuresh

George Tsirtsis presented his new Internet-Draft titled "Network
Address Translation - Protocol Translation (NAT-PT)".  This is a
revision of his earlier I-D of the same name.  This draft adds a lot of
new material and is about 3 times larger than the old version.

The general objective of this proposal is to allow areas of IPv6-only
nodes, or IPv6/IPv4 dual nodes using only IPv6 addresses (no IPv4
addresses), to be deployed.  This would allow sites to achieve the
benefits of converting a site completely to IPv6, avoiding the need
to maintain and administer IPv4 throughout the site.

The proposal employs techniques analogous to IPv4 NAT and port
translation to allow IPv6 nodes to communicate with IPv4 nodes.  It
envisions NAT-PT translator nodes being deployed at the borders of
IPv6 networks.  The same technique could be used for stub dual
IPv6/IPv4 networks, or stub IPv4 networks.

The NAT-PT translator nodes perform stateful header translation
between IPv4 and IPv6, basing the translation on mappings between IPv6
addresses and IPv4 addresses that are generated on the fly (in
response to traffic) or in response to DNS queries.  The translators
may manage pools of IPv4 addresses that are used for these mappings.
Additionally, they may intercept and translate DNS queries and replies.

Changes to the I-D in this version include:

   -    Extended to allow the use of any prefix
   -    Added some new DNS interactions
   -    Added support for port translation
   -    Merged in the header translation mechanisms from Erik Nordmark's

        SIIT Internet-Draft

The presentation walked through three different scenarios: one case of
an IPv6 node initiating communication with an IPv4 node, and two cases
of an IPv4 node initiating communication with an IPv6 node.

More details of the proposal can be found in George's slides at:

<ftp://ftp.labs.bt.com/pub/tsirtsg/41-IETF-NATPT.zip>ftp://ftp.labs.bt.com/
pub/tsirtsg/41-IETF-NATPT.zip

Several issues were raised in the discussion that followed:

   -    Tony Hain pointed out that the document needs to discuss
        applicability of this technique (what types of sites could use
        it, what types should not), and also needs to discuss scaling
        issues.

   -    Brian Carpenter suggested that the group needs to consider how
        this technique would combine with the various other transition
        techniques, and API issues it raises.

   -    Concern was raised about the translation of DNS queries and
        replies.  It was not clear whether this could be made to work
        with signed DNS queries/replies.

____

SMTP issues in IPv4/v6 environment - Kazuhiko Yamamoto

A presentation of SMTP use in dual-stack environments was given by Kazu
Yamamoto of the WIDE project.  The WIDE project now has dual IPv4/IPv6 stack
MTAs ready for testing, and thus experimented with registering MX records for
IPv6 MTAs and what happens to IPv4 only MTA servers.

Results were that IPv4-only Sendmail/Bind has no problem with AAAA
records(Sendmail 5.61 or later and Bind 4.8.3 or later), but when MX records
were used which refer to A and AAAA records there were problems.  

Further experimentation is planned and will be reported as appropriate.

(chair's note:  this work probably falls more under the 6bone rather than the
tools portion of ngtrans, thus will be scheduled there in the future.)

________________________________________________________________________ 

ngtrans 6bone portion of meeting, chaired by Bob Fink

Discussion:   6bone@isi.edu (6BONE Mailer) 
Subscribe:    majordomo@isi.edu "subscribe 6bone" 
Archive:     
<http://www.ipv6.nas.nasa.gov/6bone/>http://www.ipv6.nas.nasa.gov/6bone/ 
Web site:     <http://www.6bone.net/>http://www.6bone.net

____

6bone Status report - Bob Fink & David Kessens

A brief status of the 6bone was given by Bob Fink of ESnet and David
Kessens of
ISI.

    240 sites in 32 countries
    14 host and 14 router implementations (probably more at this time)
    45 sites participating in the 6bone backbone
    site, routing and address delegation done thru 6bone registry at ISI
      courtesy of David Kessensof ISI
      some new RPSL features in use on the registry
    maps and many statistics automatically made up from 6bone registry
      courtesy of Andrew Scott of Lancaster Univ.
    reverse DNS registry courtesy of Bill Manning of ISI

____

6bone routing issues I-D - Bertrand Buclin & Alain Durand

A presentation was made of <draft-ietf-ngtrans-6bone-routing-issues-02.txt>
was
made.  This I-D is based on the following routing principles:

The 6bone is a hierarchical network with
    backbone sites acting as pseudo TLAs (pTLAs)
    pseudo NLAs (pNLAs) providing transit services below pTLAs
    leaf sites

pTLAs MUST use BGP4+ between them

Multihomed sites SHOULD use BGP4+

Leaf sites MAY use default routing

Aggregation MUST be performed by border routers
    Specially true for pTLAs

There are a set of rules for 

    Link Local prefixes
    Site Local prefixes
    Special case prefixes
    Multicast prefixes
    IPv4 mapped prefixes
    IPv4 compatible prefixes
    Undefined Unicast prefixes
    Default routes
    Aggregation and advertisement issues
    Inter site links

This document will be revised based on minor comments and recirculated.

____

6bone routing reports and related issues - Masaki Hirabaru

A presentation of the new Merit 6bone Routing Reports was given by Masaki
Hirabaru of Merit.  These reports are collected by an MRT routing daemon and
processed with the IPMA statistics tool.  An email list for the daily reports
is available that gives the size of the 6bone routing table, how many unique
AS's are in use, how many BGP4+ announcements, withdrawals and unique routes
there are, a list of the most poorly aggregated announcments and the top five
most active prefixes.  A route flap graph is also available.

Initial use of the tool shows too many routing changes for so few routes, thus
indicating possible routing software/protocol problems.  The reports can also
be used to encourage aggregation and detect incorrect configurations.
Feedback on, and use of, these reports is encouraged.

The reports can be subscribed to by sending email to majordomo@merit.edu with
"subscribe 6bone-routing report" in the message.  A hypemail archive is
available at:

   
<http://www.merit.edu/mail.archives/html/6bone-routing-report>http://www.mer
it.edu/mail.archives/html/6bone-routing-report

The Rout Flap Graph is at:

   
<http://www.merit.edu/mail.archives/~ipma/java/FlapGraph.html>http://www.mer
it.edu/mail.archives/~ipma/java/FlapGraph.html

____

Multihomed routing domain issues for IPv6 aggregatable scheme I-D - Francis
Dupont

A presentation was made of current ideas for handling IPv6 site multihoming by
Francis Dupont of Inria.  A one hour session on this topic was held in the
hour
preceding this ngtrans meeting.  There are several different approaches
possible to this problem, several of which share problems and solutions with
IPv4.

Bob Fink noted that this work may best be done under the Routing Area to
encourage wider participation in the discussion and solutions for site
multihoming, a path he has agreed to pursue with the head of the Routing Area.

____

6bone transit through CAIRN - Maryann Maher

A brief overview was given of Allison Mankin's CAIRN native IPv6 6bone
backbone
proposal by Maryann Maher of ISI-East.  In brief, the CAIRN project is willing
to provide native IPv6 backbone service across the US, on a testing use basis,
from CAIRN's points of prescence at LBL, ISI-West, MCI, ISI-East and UCL.

____

IPSEC proposition - Maryann Maher

Maryann maher of ISI-East presented Allison Mankin's request to the 6bone
project that IPSEC AUTH functionality be required in 6bone routers by the end
of the year. Though there was a sense of agreement that it was appropriate for
the 6bone to push the development and testing of security for routers, there
was also a bit of confusion of just what was meant by this proposal.  Bob Fink
will request Allison to make a specific proposal that can be considered on the
mail list.

____

Win-NT IPv6 public source - Richard Draves

A short presentation of the new Windows NT IPv6 implementation by Microsoft
Research was given by Richard Draves of Microsoft.  He noted that this work
was
also being supported by Allison Mankin's group at ISI-East.

The source and binary release was made on March 24, 1988, and can be retrieved
from:

   
<http://www.research.microsoft.com/msripv6>http://www.research.microsoft.com
/msripv6

It is being released to promote research, education and testing, and is not
intended for commercial use.  There is no support for Windows 95 or 98.  It is
copyrighted and distributed under a license.  Richard specifically encouraged
those with troubles agreeing to the license to contact him to see if something
mututally agreeable can be arranged.

Richard noted that, although it was released for NT version 4, he had been
able
to easily run it on NT version 5 as well, though he needed to make an
installation procedure change.

Initially the following works:

BaSic IPv6 header processing
Neighbor Discovery
Stateless autoconfiguration
Partial ICMPv6 (basically ping support, but not error messages)
Partial Multicast Listener Discovery
Automatic and configure tunnels
IPv6 over IPv4 per the Carpenter/Jung draft
UDP and TCP over IPv6
ping, traceroute, ttcp, ftp/ftpd, NetMon

What's missing:

Security and Auth headers
Mobility support
Routing
Applications as follows
  Web client/server
  File client/server (i.e., Microsoft Networking)
  DNS client/server
v6/v4 translation

____

pTLA asignment rules - Bob Fink

Delayed to an informal lunchtime meeting the day after the ngtrans meeting.
When presented to the lunchtime group, there was no further comment on the
pTLA
assignment rules presented by Bob Fink of ESnet, other than that some folk are
unwilling to say a site cannot do something.  Bob noted that these rules have
been presented before on the 6bone list and that he will continue to require
new pTLA requestors to respond to the four criteria, to the list, so general
sentiment can be heard.  He will then make a decision based on the requestor's
response and the sentiment expressed.

Bob encouraged those that do not like any particular policy he is enforcing to
comment to him directly or to the list.

____

steps to clean up the backbone - Bob Fink

Delayed to an informal lunchtime meeting the day after the ngtrans meeting.
Bob
Fink of ESnet presented some of his problems and possible solutions about the
6bone backbone and its general cleanup:

Various problems
– reliability 
– old addresses in use
– invalid tunnels
– routing loops
– non BGP4+ peering
– incomplete registry info
– no address delegation through the registry

Various solutions
– enforcing registry rules (e.g., if no correct entry no listing shown)
– pulling pTLAs for sites not providing good service or incomplete and
inaccurate registry entry
– publish top ten “worst site” list
– various tools to show what doesn’t work

Alain Durand then spoke in favor of terminating pTLA sites that were not
following various rules as expressed in the 
6bone routing issues I-D.  Several folk (Bertrand Buclin, Guy Davies and
others) spoke against the harsh enforcement of rules as being inappropriate
for
the 6bone and its testing nature.

The general consensus seemed to be that report-based enforcement was more
appropriate for the 6bone.  Thus a set of rules would be agreed upon (say the
Buclin/Durand draft) and reports would target those not complying. 

It was also agreed that a 6bone-ops list made up of 6bone registry contacts
would be a better place for reports than the main 6bone list.  This would also
help enforce the use of the registry for participating sites.

Bob agreed to publish to the 6bone list a general proposal for a way to start
the cleanup process based on discussions from this session.

____

tools to help clean up the backbone - Ivano Guardini - 10 mins

Delayed to an informal lunchtime meeting the day after the ngtrans meeting. 
Ivano Guardini of CSELT gave a presentation of the new ASpath-tree tool that
monitors BGP4+ routing, resulting from work of both Ivano and Paolo Fasano
also
of CSELT.  This tool provides a graphical view of the BGP4+ routing tree
towards the 6bone.  The results are obtained by elaborating the AS path
information available in the BGP4+ routing table of an IPv6 border router
terminating BGP4+ capable tunnels.  Results are presented automatically as
html
pages.  See:

   
<http://carmen.cselt.it/ipv6/bgp/index.html>http://carmen.cselt.it/ipv6/bgp/
index.html

The tools was developed as a set of unix scripts in Perl 5.0, and tested on a
Solaris 2.5.1 workstation.  BGP4+ routes are collected using rsh commands, and
the current script handles Cisco routers.  Required inputs for the program
are:

    the 6bone registry database

    the 6bone pTLA list

Ivano then showed various sample results from a CSELT viewpoint using
ASpath-tree.  For future work the following was given:

    Automatic detection of BGP4+ routing anomolies
      unaggregatedprefixes, wrong prefix advertisements ...

    Provide information on BGP4+ routing stability

    Use of SNMP for data acquisition

    ...and the desire for suggestions from the 6bone community

Ivano asked that other pTLA sites install the code, which is available at:

    ftp://carmen/cselt.it/pub/ASpath-tree.tar.gz

-end