Subject: (ngtrans) draft Minutes of Oslo NGtrans WG Meeting

From: Bob Fink <[email-masked]>
Date: Tue, 27 Jul 1999 17:06:47 -0700

NGtrans folk,

Here are the Oslo draft minutes. Please let me have edits soon so I can submit
the minutes to the secretariat.

Thanks,

Bob

============================= 
Minutes of NGtrans WG Meeting 
12-13 July 1999 
Oslo IETF
___

Chairs: 

Alain Durand <[email-masked]> 
Bob Fink <[email-masked]> 
Tony Hain <[email-masked]>

This ngtrans meeting reported by Alain Durand, Bob Fink and Tony Hain.
Attendance was ~250.

Alain Durand chaired this meeting as well as organized it due to Bob Fink's
extended vacation preceding the meeting.

___

Administrative information:

Discussion ngtrans: <mailto: [email-masked]> 
Subscribe ngtrans: <mailto: [email-masked]> "subscribe ngtrans" 
Archive ngtrans: (I'll replace with the newer archive)
Web site: <http://www.6bone.net/ngtrans.html>

Discussion 6bone: <mailto: [email-masked]>| 
Subscribe 6bone: <mailto: [email-masked]> "subscribe 6bone" 
Archive 6bone: (I'll replace with the newer archive) 
Web site: <http://www.6bone.net>

___

Agenda 

Monday, July 12 at 1300-1500

6to4 - Brian Carpenter (1 hour)
- issues with draft-ietf-ngtrans-6to4-02.txt 
- complex 6to4 scenario discussion 
- next steps

Transition tools 
- NAT-PT-06 - George Tsirtsis (5min) 
- SOCKS -00 - Hiroshi KITAMURA (15min) 
- BIS-01 & toolnet6 - Kazuaki Tsuchiya (15min)
- WIDE Camp - Yuji Sekiya
- Tunnel broker-00 - Ivano Guardini (5min) 
- Transition of IP multicast - Ivano Guardini(10min) 

Tuesday, July 13 at 0900-1130

Transition tools 
- Transition mechanism-04 - Erik Nordmark (5min) 
- SIIT-06 - Erik Nordmark (5min) 
- Bump in the API - Erik Nordmark (5min) 
- DTI/AIIH (DSTM-00) - Laurent Toutain (40min)

Roadmap documents & transition scenarios 
- draft-ietf-ngtrans-introduction-to-ipv6-transition-01.txt -
  Ronald van der Pol (10min) 
- ALG - Hiroshi KITAMURA (10min)
- Roadmap document - Dale Finkerson (5 min)

Unified BSD update - Itojun (1min)

6bone activites
- 6bone report - David Kessens (1min)
- 6bone hardening-00 - Rob Rockell (30min)
- 6TAP - Bob Fink (10min)

Registries report - Mirjam Kuehne (5min)

___

6to4-02 - Brian Carpenter

Brian Carpenter presented an overview of the new and quite improved 6to4 draft
at <http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-6to4-02.txt>. This
presentation may be viewed at
<http://www.6bone.net/ngtrans/oslo/6to4-02-prstn.ppt>. The most important
enhancements over draft -01 are information on routing, multicast, relay
routers and configured tunnels.

Brian then describe example scenarios on how 6to4 might work using cute little
symboles too hard to recreate here (please refer to above presentation URL for
these scenarios). The scenarios include simple relays, multiple relays,
fragmented ipv4 worlds, fragmented ipv6 worlds, and net10 usage.

There was debate about how to find relay routers between native v4 and v6;
there is a need to define a v4 anycast address for this. 

Brian is expecting the ipng wg proposal for source selection (in the new
multihoning proposals) to solve 6to4's problem of address selection.
 
Need to investigate issues in common with automated tunnels.

Need to define RFC1918 addresses as site local to avoid problem when NAT
allocates v4 but does not support 6to4.

May need to split off as a BCP if too many operational issues arise.

A question on how complex 6to4 might be was answered by pointing out that if
the goal is to connect a v6 site over the v4 net it isn't too complex. It does
quit working when the v4 net is fragmented. It also doesn't work so easily
(yet) over native v6 networks.

Randy Bush thinks that MBGP could carry routes between isolated 6to4 domains.

Brian feels 6to4 needs help from BGP4+ geeks

Randy Bush will provide routing comments for updated draft.

Keith Moore spoke on several issues (not all recorded here):

To transition each network level without affecting apps, a subtle point is that
each level can have a v4 addr that is doing 6to4 within it.

If you have a NAT-like box with 6to4 in it, how does it know how to reach other
v6 addresses?

6to4 has no impact on v6 protocol docs, if the new multihoming proposal goes
thru (for address selection).

Should draft include text on why MUST is required on toxic waste dump (Brian
needs to provide rationales)?

There was consensus on immediately assigning TLA 2010::/16 for 6to4 test use as
it is being used already on the 6bone and this use will need to continue to
grow as the 6to4 testing grows. Alain will poll the ngtrans mail list on this
and if there is general consensus there as well will arrange to ask IANA for
the assignment by early next week. (chair note: this probably will be an
experimental allocation for now, similar to the 3FFE::/16 6bone allocation, at
least until finalization of 6to4 as an Internet standard).

Agreed that a next draft is required before a last call can be done.

Agreed that might need to separate out operational stuff later.

___

NAT-PT-06 - George Tsirtsis 

This draft is available at
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-natpt-06.txt>. There
were no presentation slides.

There needs to be some text to handle A6 records, then can go to last call.

NAT-PT relies on SIIT so will be processed when SIIT is forwarded.

___

SOCKS-00 - Hiroshi KITAMURA

This work has previously been discussed as two different drafts and has now
been merged into one draft at
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-socks-gateway-01.txt>.
This presentation may be viewed at
<http://www.6bone.net/ngtrans/olso/socks-00-prstn.ppt>. 

No protocol is proposed, two implementations exist and have been verified with
no performance problems. The source code is available.

Hiroshi asked if it should be processed as Informational or Experimental.

Randy Bush (our fearless ngtrans A-D) agreed it should proceed as
Informational.

___

BIS-00 & toolnet6 - Kazuaki Tsuchiya 

This draft is available at
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-bis-00.txt>. This
presentation may be viewed at
<http://www.6bone.net/ngtrans/oslo/bis-00-prstn.ppt>. (Note this was previously
called dual-stacks-host-01.)

It was noted that only binary (i.e., no source) of the BIS implemenation is
available.

This work is now ready for wg last call as Informational. (Chair note: the
current draft name is confusing and will be changed to bis.)

___

WIDE Camp - Yuji Sekiya

The recent March 1999 WIDE IPv6 Camp focusing on ipv6-only to ipv4-only
interoperation was described. This presentation may be viewed at
<http://www.sfc.wide.ad.jp/~sekiya/WideCamp>. 

___

Tunnel broker draft-01  Ivano Gardino

This draft is available at
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-broker-00.txt>. 

A few comments have been received on this drafts: the Broker Daemon proposal
and Peter Tattam's Dynamic Tunnel Configuration Protocol.
 
The draft will be revised and needs more technical comments as well as help on
English cleanup. Bob Fink agreed to work with Alain on this, then -01 will be
issued for wg last call as Informational.

___

Transition of IP multicast - Ivano Guardini

The concept of a Multicast Session Control Center (MSCC) was presented. The key
function for ipv6 is the bridging of multicast traffic between ipv4 and ipv6
networks.

This presentation may be viewed at
<http://www.6bone.net/ngtrans/oslo/mscc-prstn.ppt>.

___

Transition mechanism-04 - Erik Nordmark 

This draft is available at
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-mech-04.txt>.

Changes since the -03 draft are:
- a note that TOS change work is underway that might in the future define a
different behavior for the TOS byte when tunneling.
- a similar note for decapsulating

The IETF last call on -04 is done, and the IESG will now process it to replace
the current Mechanism RFC at Proposed.

___

SIIT-06 - Erik Nordmark 

This draft is available at
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-siit-06.txt>.

Changes since the -05 draft:
-added description on how to handle UDP/IPv4 packets with a zero UDP checksum
(drop 1st fragment with zero checksum and log an event
-clarified the scope of the document to be a component of a solution
-updated ftp text to talk about EPRT/EPSV and RFC2428
-editorial fixes

Erik askes again if SIIT needs to be a complete solution:
-how to allocate addresses (same as AIIH/DTI)
-routing implications in site (tunneling v6 inv6)
-separate draft

Need more implementations

Agreed to forward it to the IESG as Proposed Standard along with NAT-PT and BIS
that both rely on SIIT.

___

Bump in the API - Erik Nordmark 

The concept of a Bump-in-the-API was presented.

Allow some unmodified socket apps to work without porting (but don't delay
porting)

Idea implemented by Erik and Peter Tattam (Trumpet)

App operates on 32 bit tokens using existing socket API

Shim between app and protocol stack, DNS and address parsing, which maps
between tokens and v6 addresses

Limitations:

-similar as NAT & BIS
 but IP level things work (IPsec, MibileIP)
 assumes v6 stack, IKE etc.
-intercepting inet_addr() and inet_ntoa() makes literal v6 addresses work
 except ':' sensitive parsers like browsers
 breaks for apps that parse and print not using these functions
 e.g., accessing s_addr content directly
-implementation specific how to intercept API
 might be possible on some platforms
-inet_ntoa() will return longer strings (46 vs 16)
 in theory apps can crash
-IPPROTO_IP options (source route, etc.) might not work
 implementation specific
-SOCK_RAW may or may not work
-apps passing socket descriptors to other processes unlikely to work

Erik asked what his next step should be:
-produce draft intended for Informational
-merge with BIS
 similar limitations but rather different actual mechanisms used

Question about OS's that don't support DLL's: will not work here.

Question about merging with BIS: looking at them as black box, a call 
happens and bits appear on the wire; what happens in the middle is the 
difference.

Consensus was to keep separate from BIS and gave a separate draft intended for
Informational.

___

DTI/AIIH (DSTM-00) - Laurent Toutain 

This draft is available at
<http://www.ietf.org/internet-drafts/draft-toutain-dstm-00.txt>. This
presentation may be viewed at
<http://www.6bone.net/ngtrans/oslo/dstm-00-prstn.ppt>. 

DSTM was previously the AIIH and DTI efforts integrated into one new design,
thus a long presentation time was given for Laurent to give a thorough overview
of the concepts of DSTM. Please refer to the above URL for this information.

There was concern expressed that DSTM isn't simple (Laurent said he though it
is) and it needs to be simple in both concept and implementation to suceed.

The implemenation statusis that DTI has been implemented, but no AIIH has been
done yet. Also, DHCPv6 is needed.

It was noted that apps do not need to change.

Erik Nordstom noted that the presentation helped him understand the concepts
better and more of the details of the presentation need to be in included in
the draft.

Erik also noted that the draft needs to outline the requirements and consraints
on DNS implementations.

It was noted by Brian Carpenter that the IAB Network LAyer workshop strongly
expresses no more changes to the DNS model.

Hossam Afifi noted that DSTM doesn't rely on the new A6 record.

The question was asked if DSTM should be a wg draft. Brian expressed concern
about its compexity, but many felt it should still be a work item with a future
decision regarding its forwarding status to be made when appropriate.

It was agreed that an enhanced wg drat version would be generated and further
work done.

___

Roadmap documents & transition scenarios 

Alain Durand introduced this part of the agenda noting that the Grenoble
meeting resulted in ngtrans descriptive documents more recently called roadmap
documents to explain or overview the transition process, transition scenarios
to explain how various major transition scenarios would be handled with the
ngtrans tools/mechanisms and a matrix of features for each of the
tools/mechanisms.

The ngtrans chairs have agreed that Alain will oversee this overall
documentation effort for ngtrans.

Dale Finkelson has agreed to be responsible for getting the roadmap/overview
part done.

Alain has agreed to be responsible for getting the scenario part done.

Jim Bound has agreed to be responsible for getting the atrix part done, though
he has recently been unable to participate (or attend this IETF) due to
illness, this Alain will have to ascertain if Jim will still be involved.

The first presentation by Ronald van der Pol is a candidate for the roadmap
document.

___

draft-ietf-ngtrans-introduction-to-ipv6-transition-01.txt - Ronald van der Pol

Ronald van der Pol (SURFnet) gave an overview of work done by Henk Steenman
(AT&T), Wim Biemolt (SEC), Marijk Kaat (SEC) and himself.

This draft is available at
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-introduction-to-ipv6
-transition-01.txt>. This presentation may be viewed at
<http://www.6bone.net/ngtrans/oslo/intro-to-trans-01-prstn.ppt>. 

This work, as mentioned above, is a candidate for the Roadmap overview
document. 

No comments to the presentation were made. 

It will continue to be refined in conjunction with Dale Finkelson.

___

ALG - Hiroshi KITAMURA 

Hiroshi KITAMURA continued to describe Application Level Gateways as included
in his SOCKS presentation (see URL above under SOCKS agenda item).

Randy Bush noted that there were IPsec problems with this type of approach.

It was noted that the server location needs to be know.

___

Roadmap document - Dale Finkelson 

Dale noted that there were the three document sets to be generated as noted
above. He noted that the Pol, Steenman, et al document was good and definitely
a candidate for the Roadmap document. Dale has also submitted this document to
non-IPv6 experience network managers for comments as to usefulness.

Work on this draft, as noted above, will continue.

___

Unified BSD update - Itojun

Itojun gave a brief report of the integration effort to unify the KAME (JP),
INRIA (FR) and NRL (US) code for BSD unix.

The implementation will include a 6to4 implementation.

Itojun noted that everyone was too busy, and time zones and design differences
have slowed progress.

They are close to a working kernel.

After a kernel is available getting the code out needs to start.

Help is needed, volunteers appreciated.

BSDs are starting to have bundled v6 support:
  OpenBSD NRL
  BSDI NRL
  NetBSD KAME

They will migrate to the unified version as soon as it is available.

More at the next IETF!

___

6bone report - David Kessens 

Number of 6bone registry objects: current (previous)
ipv6-site:  412     (361)
inet6num:   281     (225)
person:     509     (428)
role:        32      (30)
mntner:     160     (135)

Number of countries: 42
AR AT AU BE BG BR CA CH CM CN CZ
DE DK ES FI FR GB GR HK HU IE IT 
JP KR KZ LT MX NL NO NZ PL PT RO
RU SE SG SI SK TW UA US ZA

3200 queries per day
8 updates per day

___

6bone hardening-00 - Rob Rockell 

Rob Rockell reported on his efforts since the last IETF to develop a newer set
of 6bone routing policies to "harden" the quality of 6bone routing. 

The goals were to:
-improve the backbone routing stability
-provide for a stronger tested for new services and technology
-provide better quality connectivity to the 6bone

The work was based on the current 6bone routing policy nowpublished as an
Informational RFC (see the 6bone homepage for the URL). This draft is available
at <http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-harden-00.txt>. This
presentation may be viewed at
<http://www.6bone.net/ngtrans/oslo/harden-00-prstn.ppt>. 

This work will soon be circulated for 6bone comment, then ngtrans wg last call,
and replace the current Informational RFC with a new one.

___

6TAP - Bob Fink 

Bob Fink announced the 6TAP becoming operational. The 6TAP is a project of the
6REN effort <http://www.6ren.net> to provide a high quality peering point for
native IPv6 networks at the Chicago NAP/StarTAP. Any IPv4 service provider with
an attachment to the StartTAP/Chicago NAP can establish a native IPv6 ATM PVC
to the 6TAP router and pickup all IPv6 routes (6bone, 6REN, etc.) as well as
transit service.

The 6TAP is a joint effort of ESnet (who has provided the routing equipment and
7X24 operation) and CANARIE (who will be providing Route Server services).

___

Registries report - Mirjam Kuehne 

The policy draft has been reissued with changes and is at IANA. IANA wants some
reverse DNS info which is being done this week.  It is hoped that IANA will
tell the address registries to start allocating this week.

Chair's note: at the open plenary on wed., the announcement was made that the
IANA had approved the policy draft, and given the initial address blocks to the
registries so that IPv6 addresses could now be allocated upon request, by the
registries per the new policy.

-end

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 30 Jul 1999 17:48:39 -0500

...
> (yet) over native v6 networks.

Not sure I understand the last sentence; it is not surprising that
6to4 doesn't run over native v6, since it isn't designed to do so.
If it means that there are still issues about routing 6to4 prefixes
over native v6, OK, but that is covered by the following points

> Randy Bush will provide routing comments for updated draft.

   Brian

---

From: [email-masked]
Date: Sat, 31 Jul 1999 09:53:57 +0900

>over native v6, OK, but that is covered by the following points

	I have one concern about 6to4, this may or may not be related to
	the thread...

	6to4 requires renumber of whole site (site prefix) when relay router
	is (IPv4-wise) renumbered, or replaced to a box with different IPv4
	address.   With RFC1993 (configured tunnel) tunnel endpoint IPv4
	address can be replaced without requiring site renumbering.

	I changed tunnel endpoint for my home, and for others several times
	in 6bone operation so this is not an academic example.
	I would like to see the above paragraph (or similar) added somewhere
	in the draft.

	I fear that, by embedding IPv4 address into address, IPv6 can be
	mistakingly considered as "subset of IPv4" or "dependent to IPv4".
	I want IPv4 and IPv6 to be as independent as possible...

itojun

---

From: Keith Moore <[email-masked]>
Date: Sat, 31 Jul 1999 10:44:50 -0400

This is certainly true. However, 6to4 uses IPv4 routing for packets
with destination addresses in 6to4-space, which seems likely to be
a lot more efficient than routing over configured tunnels.  Also, 
renumbering a 6to4 net when it changes its external IPv4 address 
doesn't seem any worse than renumbering a native v6 net when it 
changes its address prefixes - the same mechanisms can be used.

It should be clear that 6to4 is a transition strategy which uses v4
to bootstrap v6, in a very similar way as the ARPAnet was once used 
to boostrap the v4 Internet (and v4 prefix 10/8 corresponded to the 
ARPAnet).  It is true that 6to4 is dependent on v4, but ultimately 
IPv6 will be no more dependent on IPv4 than today's v4 Internet is 
dependent on the ARPAnet.

Keith