minutes from ngtrans/6bone meeting in Washington DC

[Bob Fink]

Sorry to be slow in posting these...they were actually completed right
after the meeting in December, but forgot to post them.

Bob

_____________cut
here___________________________________________________________

ngtrans tools WG meeting
December 9, 1997
Washington, DC IETF

Bob Gilligan chair, Tony Hain reporting

Discussion:	ngtrans@sunroof.eng.sun.com
Subscribe: 	majordomo@sunroof.eng.sun.com
Archive: 	ftp://playground.sun.com/pub/ngtrans
Chairs:		Bob Fink rlfink@lbl.gov
		Robert Gilligan gilligan@freegate.net
		Tony Hain tonyhain@microsoft.com


Updates to RFC-1933 - Bob Gilligan

Updates to RFC-1933, the current Proposed standard for Transition
Mechanisms, were discussed to move it to Draft status.  An I-D was
submitted for review at this meeting which contained, among other things,
the following:

	Remove ::127.0.0.1 from discussion

	Eliminated 'raw IPv6 form' when sending IPv4 on link
	(implementation complexity, low gain)

	Added definitions for operating mode
	(dual stack needs to know if one is to be turned off)

	DNS resolver filtering/ordering options clarified

	IPv4 compatible used only with automatic tunneling

	'v6 only' to 'v6 native'

	update MTU for new 1280 byte min MTU size

	misc. clarifications in text

	Needs: definition of link-local address for configured tunnels

	Automatic tunnel operational issues

	Source address selection when automatic tunnel

	Scope of IPv4-compatible address


Steve Deering noted that use of ND over pt-to-pt links will be discussed in
the IPv6 group on Thursday.

Need to clearly define mechanism where configured tunnel is unidirectional
with an automatic tunnel back. Issue is where to tunnel back since any
router attached to v4 cloud can forward to avoid injecting v4 routing table
into v6 cloud. Technique of using well-known v4 anycast as default tunnel
is written up, but actual pattern not defined.

Discussion diverted into should we or not, allow asymmetric use of
configured and auto tunnels.

Tony Hain commented that we are here to define the mechanisms, not define
how they get used.

Discussion about how to document injection of v4 routes or not into
v6. Should be a BCP from the 6bone implementers, since it is a topic for
that deployment timeframe.  Bob Fink said he would handle this one in
consultation with Steve Deering.

Bob Gilligan will revise the document as an ID and send to the list.


NNAT - Jim Bound

A No NAT (NNAT) draft was presented in Munich - Jim Bound gave an overview
and walkthrough of it here.

An IPv4 host requests DNS lookup, where a record is set as forwarder to
NNAT server which sends DHCPv6 reconfig message which hosts MUST listen to,
which is a temporary v4 address which allows building v4 compatible, then
the NNAT server updates DNS and responds back to original requestor.

Open issues:

	DHCPv4 use and CNAME fix
	TTL cache
	Hybrid Stack Question
	Tunnels move to egress router
	Use of RFC 1183 records
	Authoritative DNS Server Response
	Update to lifetime for long running clients
	Default reassignment hold-down time
	NNAT name of the draft - open to discussion

Concern that temporary assignment may get out of sync if host to be
reconfigured is not up at the time. Since the reconfig message is Ack'd,
the language will be clarified to note that the NNAT server will not
complete the DNS response if the Ack doesn't happen.


SIIT - Eric Nordmark

SIIT is a stateless header translator. It is not a single point of failure.
Assumes mechanism like NNAT for temporary v4 addr.
Transport-mode ESP works

Open issues:
	use v4 comp as address. Works as long as v6 cloud is clean.
	v4 traceroute


NAT-PT - George Tsirtsis

This is v6 to v4 NAT to connect the clouds. It is a combination of NAT in
outbound direction with NNAT in inbound direction. There is aminimal use of
compatible/mapped address only v6 hosts need to do anything
This breaks end-to-end principle...same issues as any NAT

This is a statefull version of SIIT.

George will work with Eric and Jim to see if a combined document is possible.


WIDE Translators - K. Tsuchiya, K. Yamamoto, T. Niinomi

Three translators developed by members of the WIDE project in Japa were
presented.

NR60 Translator - K. Tuchiya

	A modified DNS, address mapper & header translator used
	Straight NAT using DNS as resolver in both directions
	Implemented all on one node

FAITH - K. Yamamoto

	Header conversion has limitations
	Address conversion in legacy applications is difficult
	AH works when translator is trusted and rebuilds connection

Socks64 - T. Niinomi

	No DNS modification or address mapping management
	Application level gateway based on Socks 5
	Distributes fake v4 address for v6 end points
	Only modifies clients where other 2 modify infrastructure

These three translators represent actual implemented work.  The chairs
would like to thank the Wide project members for their willingness to come
a long distance to share their ideas and extensive experience, and hope
that it will continue.

_____________cut
here___________________________________________________________

ngtrans 6bone WG meeting
December 9, 10 & 11, 1997
Washington, DC IETF

Bob Fink chair, Ben Crosby, ALain Durand and Bob Fink reporting

Discussion:	6bone@isi.edu (6BONE Mailer)
Subscribe: 	majordomo@isi.edu  "subscribe 6bone"
Archive: 	http://www.ipv6.nas.nasa.gov/6bone/
Chairs:		Bob Fink rlfink@lbl.gov
		Robert Gilligan gilligan@freegate.net
		Tony Hain tonyhain@microsoft.com
Web site:	http://www.6bone.net


Due to limited time in the main ngtrans session, the discussions on 6bpne
routing issues were handled in two lunchtime disussions on 10/11 December.


WIDE 6bone status - K. Yamamoto

A brief status report of the WIDE 6bone project was given. Of special note
is the broad participation of many research/educational and industry
partners, and the development of many IPv6 implementations.

WIDE efforts started when, on June 9 1996, NAIST and Tokyo were connected
via a 64kbps circuit using v6 and then on July 16, 1996 connection was made
to the 6bone.

Currently 28 sites are connected to 4 backbone routers using RIPng.  BGP4+
conversion is delayed until later in the month.

Future plans include linking the WIDE registry to the 6bone registry,
creating an IPsec testbed, and of course BGP4+.

Again the Chairs want to thank the WIDE project members for sharing their
extensive IPv6 experience.


6bone status - Bob Fink

A brief status report of the 6bone and the backbone conversion project was
given.

	206 sites, 30 countries
	14 hosts & 13 router implementations (probably more at this time)
	42 sites using aggregation address format
	auto address delegation done via registry
	auto map generation from registry daily courtesy of Andrew Scott of
	Univ. of Lancaster
	reverse registry courtesy Bill Manning of ISI

	The backbone conversion to aggregation was accomplished on schedule


	Different strategies are emerging for sub-delegation

A brief overview of the inet6num registry object and how it relates to
automatic IPv6 address delegation through the registry was given.  This is
a result of David Kessens' work at ISI.

Discussion of backbone routing policy issues was reserved for the two
lunchtime meetings on the following two days (10/11 December).


Palo Alto IPv6 Exchange Point - Stephen Stuart

The new PAix IPv6 exchange point was described.  A LAN switch has been
devoted to native IPv6 transported in the PAix, with DIGITAL-CA, UUNET-UK
and NWNET currently peering across it.  Stephen encouraged others
interested and able to secure rack space in the exchange to particpate.


CAIRN 6bone Report - Suresh

CAIRN is a network testbed funded by DARPA. Currently CAIRN's 6bone peering
is done with NRL. Futire peering is planned with University College London,
PAix, and UUNET-UK.  The transatlantic link will be native IPv6 peering
over T1.


UK Status: Ben Crosby

An overview of the current IPv6 links in the UK was given. It was noted
that there is a move to native links to janet, and to the Univ. of
Southampton.


6bone Routing Issues I-D - Alain Durand

An early draft outline of 6bone Routing Issues was presented and discussed
in greater detail. The following is an outline of the topics covered:

- Identify all special cases
  - link local prefixes MUST NOT be advertised
  - site local only within a site - but what is a site?
     Should refer IPngwg work on that topic
  - loopback address and unspecified MUST NOT be advertised
  - multicast prefixes
   - should they be advertised in BGP 4+ ?
     - decided that they SHOULD / MUST NOT be advertised
   - ipv4 mapped addresses
     - wait on the decisions from NGtrans on "ipv4 translatable" addresses
     - this applies only to backbone
       The draft should specify for each section if it applies to all
       routers or only to backbone routers
   - ipv4 compatible SHOULD NOT be advertised on 6bone
     - perhaps they should be banned
     - suggestion that they should only be used on tunnels
     - be careful in case there is a good reason to use them in the future
   - advertise some compatible bridges using a ::/96
     - NEW SERVICE
     - general consensus not on the backbone
     - dimitri haskin wants this to happen automatically
     - auto tunnels dont need to have addresses advertised ?
     - one router to provide auto tunnelling ?
     - suggest that this is handled by the IGP ?
     ACTION - bob to send the idea to the mailing list.
   - No cases in which you would accept something that you wouldnt send on
     Stephen Stuart - liberal in recieve, but careful in sending
     Alain Durand - Ok to receive, but be carefull on what you put on
                    your routing table
   - what happens with prefixes that dont yet exist - e.g. not 2000::/8
     - routes SHOULD be discarded
   - Aggregation SHOULD be mandatory at every level - SLA, NLA, TLA
   - Backbone routers MUST be default free
   - sites MAY have a default route
   - Tunnels - prefix length ?
             - which address space ?
             - DMZ ?
   - Point to point tunnels could use a /128
     - hardware implementation problem ? (some refuse to use /128 prefixes)
     - point about the use of /128 - BGP 4+ problems due to not sharing subnet
     - dimitri says use link local but this raises next hop routing problems
       - then routers automatically change into Site level ?
       - routing entry in IGP to support the /128 ?
     This is an IDR wg issue, not a 6bone one.
   - Tunnel meshing/transit issues
     - all pTLAs MUST advertise all pTLA routes to/from each other
     - for prefixes not in pTLA, should not advertise more specific routes
     - e.g., never advertise less that /24
     - never aggregate for someone else (no proxy aggregation)

It was suggested making all the changes above and send out to the list as a
draft BCP spec for the 6bone. The purpose would be to thus document our
operating policies on the 6bone backbone.


6bone General Planning - Bob Fink

What to do nextwas discussed, given that the backbone has been converted to
the new addressing. It was agreed that it was time to declare all 0ld
(5f00) test addresses personna non grata - i.e., as of now we stop routing
them.

The general registry issue was also addressed, i.e., a lot of sites'
registry entries have not been touched since they were automatically
generated. Bob proposed deleting entries not cleaned up, given some
warning.  It was agreed to discuss this on the mail list.


Multihomed Sites - Ben Crosby et al

The general multihoming issue, i.e., how to do it at all, was discussed.
An example of 2 TLAs, with NLAs allocated in each TLA, and a site
multihomed to the 2 NLAs was used for this.  One idea was to inject a /48
site level for the given site in both NLA & TLA, which there was general
agreement on, i.e., this does not scale!!!

A 2nd idea was to use limited multihoming - the problem is that this loses
benefits of multihoming.

In further discussion on Thursday a way was discussed to attempt this by
using mobility.  Matt Crawford presented the concept during the IPng
meeting on Friday. and there was enough interest that it will at least be
pursued at the discussion level.

Note that this issue is only slightly different for IPv6 than it is for
IPv4, and there needs to be more participation from IPv4 folk experienced
in routing and multihoming to help move IPv6's multihoming issue along.

-end