Subject: (ngtrans) Minutes of NGtrans Interim meeting in Grenoble

From: Bob Fink <[email-masked]>
Date: Tue, 16 Feb 1999 06:35:53 -0800

NGtrans folk,

Finally got a first draft of the minutes done. Please send me comments,
etc., and I'll release the final version by early next week.

Thanks,

Bob

===
NGtrans Meeting

Feb 3, 1999

IMAG - INSTITUT D'INFORMATIQUE
ET DE MATHEMATIQUES APPLIQUEES DE GRENOBLE
Grenoble, France

---
Bob Fink opened the meeting and tendered his thanks to Alain Durand, and
IMAG, the meeting hosts for excellent arrangements!

Steve Deering and Tony Hain recorded the meeting, Bob Fink acted as editor
of the collective notes, etc.

Bob stated the goal of the meeting as:

• The NGtrans working group has developed a large set of transition tools,
including the original transition mechanisms (i.e., dual stack w/IPv6 over
IPv4 tunneling), 6over4 without explicit tunnels, translation, and other
tunneling techniques. The purpose of the meeting is for the working group
to converge on a smaller set of tools and mechanisms. 

• The meeting will include discussing specific transition scenarios and
evaluating how the current transition tools and mechanism work in these
environments.

The agenda for the meeting was presented:

(1) Review NGtrans mission and charter (brief) - 
  Bob Fink 30 mins
(2) Review transition tools/mechanism and how to
  evaluate them - Jim Bound 1.5 hours
  with help from various authors as needed 
  (Cyndi Jung, Kazuaki Tsuchiya, etc.)
(3) Discuss specific transition scenarios - 
  Tony Hain  2.5 hours  
  with help from various folk (Jim Bound, etc.)
(4) Evaluate tools/mechanisms against transition
  scenarios to establish which to converge on - 
  Bob Fink/Tony Hain  2.25 hours
(5) NGtrans mission and charter reprise (wrapup) -
  Tony Hain  15 mins

===
(1) Review NGtrans mission and charter - Bob Fink

In rough overview, the current ngtrans charter is:

• Define transition processes
 haven’t done this, so what does it take?

• Define & specify transition mechanisms
 have done so many, what to do we use?

• Create operational plan for transition
 should we do this? - we don’t think so.

• 6bone testbed for experience
 seems good, but not not robust & no apps!

To know how to write transition processes down we need to know what
transition scenarios are important and what tools/mechanisms we really need
to use to support scenarios. So we won’t worry about transition process
documents today, rather the scenarios and mechanisms.

===
The status of the NGtrans documents was then reviewed:

• Transition Mechanisms - RFC 1933 / at PS, waiting on final update (-02)
from Erik Nordmark

• Routing Aspects - RFC 2185 / Informational RFC DONE

• Stateless IP/ICMP Translator (SIIT-05) / submitted as Experimental RFC,
waiting on IESG processing

• 6Bone Routing Practice (-01) / Informational RFC DONE

• Network Address Translation - Protocol Translation (NAT-PT -04) / W.G.
“last call” for Experimental RFC, waiting on update (-05) from George Tsirtsis

• Dual Stack Hosts using the "Bump-in-the-Stack" Technique (-00) / W.G.
“last call” for Experimental RFC almost completed

• Categorizing Translators between IPv4 and IPv6 (-01) / W.G. processing as
Informational RFC, waiting to release a “last call” until after Grenoble

• Assignment of IPv4 Global Addresses to IPv6 Hosts (AIIH-01) / W.G.
processing as Experimental RFC, waiting on more discussion before a “last call”

• Dynamic Tunneling: A new method for the IPv4-IPv6 Transition (DTI-00) /
W.G. processing as Experimental RFC, waiting on more discussion before a
“last call”

• Connection of IPv6 Domains via IPv4 Clouds without Explicit Tunnels
(6to4-00) / W.G. processing as Experi-mental RFC, waiting on more
discussion before a “last call”

• SOCKS / W.G. waiting for it to be submitted as an I-D and to clarify intent

And for completeness, the following draft was never fully processed as the
IESG felt that it wasn't our project to do.

• Multihomed routing domain issues for IPv6 aggregatable scheme (-00) F.
Dupont/ W.G. suspended activity pending scope of work - now being looked at
during IPng W.G. Interim

Also, this related draft is also on the table at IPng.

• Multi-homes Sites in the IPv6 Environment - Kazu Yamamoto/ also being
looked at during IPng W.G. Interim
(not an I-D yet, and not at NGtrans)

No further action or discussion is contemplated at this time on the
multi-homing issue at ngtrans.

During the review of docs, Jim Bound expressed dissatisfaction with
"Experimental" status of his and other transition mechanisms, believing
that it's a bad label to use in marketing terms. After discussion there was
unanimous consensus that we should process the post RFC 1933
tools/mechanism I-Ds as Informational, but not prejudicing the use of
standards track processing for all or part of one or more of these I-Ds in
the future.

Regarding "applications readiness", which came up during the document
review, Jim B suggested that a better term should be used, since
applications are things like Oracle,...  (perhaps should call "standards
readiness")

---
(2) Review transition tools/mechanism and how to evaluate them - Jim Bound 

Jim Bound then presented his "Taxonomy of IPv6 Transition Mechanisms",
slides available at:

	<http://6bone.net/misc/taxonomy.ppt>

On point about Intranet vs.Internet distinction, Steve Deering said must
not ignore the tougher general Internet problems.  Bob Hinden points out
that not-fully-general solutions can still be valuable for important niche
environments.

On "users want to preserve the end-to-end model", Steve D asked to be
concrete on exactly what end-to-end model means, i.e., which are the
important properties?

On slide 11, Steve D doubts point 2, Thomas Narten doubts point 6.

On slide 12, Erik Nordmark says should distinguish between dual hosts in
which IPv4 stack is used for all comm to v4 and dual hosts in which IPv4
stack is used only for local special purposes (and therefore might not need
global IPv4 address).  Also distinguish between those schemes that can do
port tricks (and thus need fewer v4 addresses) and those that cannot.

Bob Fink asked where does SIIT sit?  (in all node implementations?)  Erik N
says SIIT sits at the translation point, which could be at a gateway or in
the end host.

Thomas N noted the important property of siit is it allows v6-only nodes
(yes, they need to be assigned IPv4 addresses at the translator, at least
temporarily, but need not have v4 code in the end host).

Discussion about importance of eliminating v4 stack.  Not so important if
its a PC; might be important if it's an Internet pen.

Erik N wanted to add to taxonomy:

- size of host code required
- effects on routing (does IPv4 routing have to be supported up to the hosts

Alain Durand wanted to add symmetry (client end vs. server end)

Itojun said, no, symmetry is not an issue of client vs. server, but an
issue of incoming-to-the-site vs. outgoing-form-the-site.

On slide 15, Itojun noted that the purpose of bump-in-stack is to support,
e.g., making Win '95 talk IPv6 with no changes (only a new driver), because
do not have source code for Win '95. He noted that he was using "private
address" in a different sense than other uses of the term "private
address"; in his case, it's private within the node, not private within the
site.

George Tsirtsis noted that Itojun's proposal is just one case of NAT-PT. He
observed that this works symmetrically: could have IPv6-only host and
applications, with a bump-in-stack driver to allow talking to v4-only hosts.  

Then ensued a lengthy discussion of why you would want to do this (which
was then deferred to scenarios discussion later).

On slide 17, Rich Draves noted that 6over4 doesn't need a router in the
simple case of a few host talking to each other.

Alain Durand asked how widely is IPv4 multicast deployed within sites (re
the ability to use 6over4)?

Jim Bound & others felt that v4 mcast was not widely deployed.

Steve D (cheerfully) noted that this will help drive deployment of v4
multicast!

On slide 18, there were questions about Jim's terminology "v4 dominant" vs.
"v6 dominant".

Steve D asked what about 6-to-4?  Jim B said it's an addressing proposal,
not a mechanism. Others disagreed with this.

At the conclusion of Jim's presentation many felt that a list of transition
mechanism properties was needed to take up where Jim left off.

Bob Fink then suggested trying to get everyone's ideas on a single list,
and did so for the time remaining before lunch. 

---
Before lunch everyone's homework assignments were collected to collation
and use later in the day.

This homework fell in two categories: 

1. how you would evaluate the various transition tools/mechanisms under 
agenda item (2).

2. your favorite (i.e., most important) transition scenario to provide for 
under agenda item (4).

---
After lunch, Alain Durand (IMAG) and Ivano Guardini (CSELT) demonstrated
their work on a tunnel broker by actually demonstrating a client
workstation going to a tunnel broker web site, registering, downloading the
approriate code (Windows or unix) and automatically establishing a 6bone
tunnel. A quite impressive demo that showed how easy it could be to get a
user online using v6 for trial and apps testing.

Marc Blanchet then noted that he had done an almost exactly similar tunnel
broker, based on Alain's original brief presentation in Orlando.

---
Bob Fink then took the lead in filling in the properties grid created
before lunch. This was attempted by taking all the properties, and for each
known transition tool/mechanism trying to answer whether it had each property.

The list of properites was:

V4 address usage: pooled or shared, ratio of addr/host, Global?
Where is address mgmnt done?
Port multiplexing?
Performance costs & where they are?
V4 or v6 routing infrastructure needed?
Does it work for v4 only, for v6 only, or require dual stack?
Does it require host (apps, other), router, firewall/gway, or ALG?
What DNS effort (mods, xltn, content) are needed?
Does it solve intranet, Internet or parts of transition?
Does it transmit tunneled packets on wire?
Does it depend on DHCPv4 or DHCPv6?
What end-end properties does it break?
What state is required between end points?
What is the cleanup cost (or mess) at the end of transition?
What are symmetry characteristics, I.e., what is impact of initiation of
connection by v4 or v6 end?
What are components of end-to-end solution?
(at host, router, dns, dhcp, clator, client/server)
What is the ease of use?
What is cost of use?
Are tunnels explicit, topologically congruent?
Does it do protocol translation and/or address translation?
What are the single point of failure vulnerabilities?

The full list of mechanisms was:

RFC1933
SIIT
BItS (Bump-in-the-stack)
NAT-PT
AIIH
DTI
6to4
6over4
SOCKS
ALG (App layer gateway)

The first property was a bad first choice to evaluate because it did not
have simple yes/no/depends/not-applicable answers, therefore lots of
arguments about definition of terms ("pooled", "global",...).  After 45
minutes on the one slide, decision was to defer to a smaller group of
proposal authors and other interested folks, and followup on the mailling list.

---
(3) Discuss specific transition scenarios - Tony Hain
(4) Evaluate tools/mechanisms against transition scenarios to establish
which to converge on - 
  Bob Fink/Tony Hain

Tony Hain then presented a summary of the contributed homework notes on
evaluating tools, assumptions and favorite scenarios. These slides can be
seen at:

	<http://6bone.net/misc/tools-scenarios.ppt>

The check marks are the number of mentions in the collected notes. No check
means one mention.

This portion of the meeting was difficult due to the general lack of a
clear agreement on any specific tool, assumption or scenario. 

There was general quibbling over various bullets on Tony's slides (again,
which were from the homework papers).

Jim B laid out his scenario for a typical transition. But again, there was
no specific consensus of any kind for any specific direction (scenario)
with any specific tool/mechanism.

The only emerging consensus was that there was a need for many
tools/mechanisms and it was too early to prune any from the ngtrans "tool set".

This led into a general discussion of the goal of the meeting and for the
group in the future.

It was suggested that a WG roadmap document, pointing to mechansism
documents and (maybe) scenario documents would be the most useful WG
activity. Various comments and points about these documents were:

- maybe include basic terminology in roadmap doc or another doc
- maybe include general applicability info in roadmap document, with
finer-grain applicability left to mechanism docs and maybe other (scenario)
docs
- include grid of properties vs. mechanisms, perhaps as an appendix

---
At this point the meeting briefly paused to hear a welcome message from our
host, the director of IMAG. All attendees were again very appreciative of
the great support IMAG has given for the interim meetings.

---
More random, unproductive talking ensued about WG activities. Then Tony H
summarized needed dcoument content:

- road map to all ngtrans docs
- terminology
- scanarios & applicability
- identifying common modules and elements
  (e.g., header mapping, DHCP, DNS)
- motivations for deployment
- grid of properties

Allison Mankin noted that the WG should not take too long to do this given
its importance and timeliness.

It was agreed to start this documentation effort post haste and a call was
made for volunteers to approach the chairs. During the meeting at least 6
attendees expressed willingness to help with the document set.

(Editor's note: the grid of properties is now taking on a different role.
Rather than a way to evaluate for the purpose of pruning tools/mechanisms,
it will now be a guide to understanding features of tools/mechanisms for
the new document set.)

---
(5) NGtrans mission and charter reprise (wrapup) - Tony Hain

Tony H reviewed the WG charter, proposing to remove clause 3 of charter
("Articulate a concrete operational
plan...") as being inappropriate for ngtrans.

Erik N stated that we need to cause transition of root DNS servers to
support IPv6, at some point. There was no disagreement on this point,
rather a feeling that it might not be an ngtrans call.

It was suggested that Tony and Bob modify the charter (and milestones) as
they felt appropriate.

---
As a final discussion item, the question was asked what you tell your
CIO/CTO/CEO to convince him/her to move to IPv6

Rich Draves listed possible selling features:

• Explain to the CIO/CTO
 Plug & Play; TCO
 Deadline similar to Y2K problem (addresses will run out)
 Applications which require global addresses & nat fails
• Global addresses for every possible node
 Renumbering & multi-home site for robustness
• Freedom to choose ISP (drive features through flow label)
 Ease of management 
• Firewall rule management (goes away completely with IPsec)
• Routing efficiency; lower cost of routing complexity
• Hidden costs of private IPv4 address space (nat is not transparent)
• Merging private companies
 End to End IP security out-of-the-box improves scaling
 New applications (things that can take advantage of flow label & mobile IPv6)
 All at once upgrade, vs. multiple per technology

---
meeting adjourned

This editor and co-chair would like to thank everyone for their efforts to
make these meetings successful. In addition, Jim Bound did much work in
preparing for the Taxonomy discussion. This work is appreciated and will
help guide ngtrans work, along with the comments of others of course.  Bob
Fink.

-end

---

From: Jim Bound <[email-masked]>
Date: Tue, 16 Feb 1999 10:40:52 -0500

Bob,

Looks good.  I want to note that your text version had funny characters
in it like "=95" before sentences and the like.

What is missing is my input to the group that we MUST state our
assumptions for customers to use transtion and without them debate will
linger in directions that could be avoided.  That it is OK for each
proposal to solve different assumptions, but we have to understand what
the assumptions are in each spec.  I requested we make a list of the
assumptions in NGTRANS as we are the grid.  This should be reflected in
the minutes.

ALso my statement that experimental RFC is not good for marketing IPv6
it a bit out of context.  The point is as I said that no one will buy
the basic stack without transition mechanisms hence we need to answer
those questions.  If they are experimental that is a bad thing because
deployment will start this year and I don't think customers want to
deploy experimental things when it comes to transitioning their network
to IPv6.

I also stated most don't bother implementing experimental RFCs whether
we like it or not.

/jim