Minutes of NGtrans WG Meeting
17 March 1999
Minneapolis IETF

___

Chairs: 
Alain Durand <Alain.Durand@imag.fr>
Bob Fink <rlfink@lbl.gov>
Tony Hain <tonyhain@microsoft.com>

This ngtrans meeting reported by Alain Durand, Bob Fink and Tony Hain.

Attendance was ~180-190.

___

Administrative information:

Discussion ngtrans: ngtrans@sunroof.eng.sun.com
Subscribe ngtrans: majordomo@sunroof.eng.sun.com "subscribe ngtrans"
Archive ngtrans: ftp://playground.sun.com/pub/ngtrans
Web site: http://www.6bone.net/ngtrans.html

Discussion 6bone: 6bone@isi.edu
Subscribe 6bone: majordomo@isi.edu "subscribe 6bone" 
Archive 6bone: http://www.ipv6.nas.nasa.gov/6bone/
Web site: http://www.6bone.net


Bob Fink announced that Alain Durand (Alain.Durand@imag.fr) has been
designated as 3rd co-chair of the NGtrans wg (welcome Alain) and that Randy
Bush (randy@psg.com) has replaced Harald Alvestrand as the OPS AD for
NGtrans (thanks to Harald and welcome to Randy).

___

Agenda 

0900-0905    context for this meeting (Grenoble, etc.) - Bob Fink
0905-1005    6to4 draft - Brian Carpenter/Keith Moore
1000-1015    additional topics (Shu NAKAMAE & Ivano Guardini)

1015-1100    planning roadmap documents - various
1100-1115    6bone hardening proposal - Bob Fink 

1545-1800    Tools/mechanisms review for forwarding
             status (SIIT/AIIH/DTI/BIS/NAT-PT)

___

Context for meeting - Bob Fink

Bob then gave a short overview of the NGtrans interim meeting in Grenoble,
and the context for the agenda for this meeting:

IPng, NGtrans and deployment (ipv6.org) met in Grenoble, France (thanks to
Alain Durand and IMAG for a great meeting!!) 2-4 Feb 99. The primary
ngtrans goal was to evaluate which transition tools/mechanisms to
keep/discard. Consensus was we need them all at some time (and to make them
informational not experimental for purposes of conveying more usability).

It was also agreed to develop Roadmap Documents to explain transition
scenarios and how to use tools/mechanisms.

After Grenoble, the OPS ADs wanted NGtrans to make a best (last?) effort to
move our tools/ mechanisms to standards track, only relying on other tracks
on a case by case basis as appropriate.

There has been great interest in the 6to4 draft since Grenoble, indicating
that we need to move it aggressively (or not) at this meeting.

The IPv6.org deployment group has expressed strong opinions to make 6bone
good for early production deployment of ipv6 service. thus necessitating
work on the 6bone to harden it for production use.

___

6to4 draft - Brian Carpenter/Keith Moore

Brian Carpenter gave a brief overview of the 6to4 concept (see
Draft-ietf-ngtrans-6to4-01.txt). 6to4 uses the global IPv4 Internet as a
link layer by assigning a TLA (e.g. 2010::/16) so that a full IPv4 address
can be imbedded in the remainder of the external routing prefix (i.e.,
2010:IPv4::/48). The IPv4 "NLA" is the IPv4 address of the site border
router that supports 6to4 tunneling. The immediate benefit: sites get an
IPv6 prefix without going to the registries, as well as automagically
tunneling over the v4 cloud separating v6 sites.

Basic scenario: Site A & B are 6to4 only
Relay scenario: Site A is 6to4 only, site B is multi-homed 6to4 & real v6
network

Routing at site A:
Site A: prefix is 2010:C001:0203::/48
Egress router has configured internal route to 6to4 encapsulator for 2010::/16
If site A wants to communicate to non 6to4 sites using site B as a relay,
it has to configure a default route to relay router of site B.

Routing at site B:
Site prefixes are 2010:09FE:FDFC::/48 and e.g.; 2001:0600::/48
It advertise routes to 2001:0600::/48 and 2010::/16 into the global IPv6
routing.
Issue: what is the scope of those advertisements?
Question: can you advertise a longer prefix than 2010::/16?
Answer: Brian: donĆt do that.

Scope of 6to4 prefix adverts
- 2010:xxxx:xxxx::/48 are never advertised into IPv6 routing
- 2010::/16 is advertised by relay routers

MTU needs to be 1280 but may be 576, in that case, return packet too big
ICMP. Encapsulation in IPv4 is as for regular tunnels with protocol type
41. IPv6 multicast is not mapped to IPv4 multicast. 6to4 should use v6
multicast routing.

IPv4 NAT? If you collocate the boundary router and the NAT box, it works,
but itĆs no different than having a configured tunnel on the NAT box.
Issue: what if there is a second (inner) IPv4 NAT?

Multicast support need to be worked out, help is required on that topic. We
must avoid the Multicast over NBMA swamp.

Issue: source address selection
In case of multi-home site (6to4 and global IPv6), source address must be
6to4. However, source address selection is not specified in IPv6. For 6to4
it is sufficient for the sender to perform longest match across all source
and all destination address. This will affect all hosts, some modification
are needed.

Issue: you need a route to a default router. How do you find that route?
Suggestion: use IPv4 anycast
Comment: you can do similar things with tunnel brokers

Issue: not only does a relay router need a route to a native IPv6 router,
but there must be a route in the other direction. This is just the same as
a configured tunnel (but it is in effect a tunnel to a whole 6to4 cloud,
not to a single site). 

Question: if you have several sites behind the ingress 6to4 router? Things
might get complex.
Comment: 6to4 is using IPv4 as NBMA as a large cloud and not as point to
point links. It is having 2 level of routing which do not know each other.

Other comments were directed to the mailing list

The chair polled the sense of the room as to 6to4 being worth continuing.
There appeared to be very near complete consensus to continue refining
6to4. More work is needed, however, before ngtrans can fully evaluate the
proposal. Also, more illustrations and concrete examples of how 6to4 works
are needed, and guidance on how 6to4 can be useful in the ngtrans toolkit.

___

An IPv6 visualization - Shu Nakamae

Shu Nakamae from Keio Univ. and the Wide project, presented his work for a
3D visualization unique to IPv6 that can show topology and hierarchy at
once. Entries taken from a registry database, are output as a VRML graph.

        <http://www.sfc.wide.ad.jp/~baseman/ietf/>

Bob Fink has set a pointer to this work on the 6bone tools page.

___

Tunnel broker - Ivano Guardini

Ivano Guardini from CSELT presented the tunnel broker work that will be
published soon as <draft-ietf-ngtrans-broker-00.txt>, that provides a
service to manage tunnels on behalf of the users, thus making it almost no
work to connect to the 6bone.

This work is an addition to the current ngtrans tool set.

___

Roadmap document set - various

Bob Fink stated the goal as outlining what we want in the roadmap docs, how
to structure them, and then assigning the work to be done. He invited those
who had prepared comments on the roadmap docs to come forward to present
their ideas.


Transition roadmap - Jim Bound

Put the various scenarios in matrix and have each author address a set of
questions.
Some of the main entries of the matrix:
- transition assumption
- evolution assumption of IPv6
- IPv6 deployed at Edges or Core?
- IPv4 global addresses required?
- how IPv4 addresses are assigned to hosts
- is translation required, is tunneling required?
- what are the affects to IPsec, to renumbering?
- is new software required and where?
- how do you retire a mechanism,

Question: is this not just duplicating each document into the matrix?
Answer: no, just put checkmark or very simple text in the matrix.


What are the issues for the end user? - Dale Finkelson

What is the problem IPv6 is trying to solve?
Meaning of transition
Taxonomy of transition mechanism
Discussion of real situation
Terminology needs to be detailed



Information needed by network architects: Alain Durand

Network operation models are different from shop to shop, tool
documentation is required.

This includes:
- what problem is the tool trying to solve?
- what are its limitations?
- how to use it?
- what are the requirements?
- how does it interact with other tools?
- when not to use it?

Other documents are needed.

Suggestion: call for white papers on general views of transition requirements
Suggestion: have a companion document with applicability statement for each
transition mechanism


General comments - Bob Hinden

Separate tool documentation from scenarios. Request that we pick 3
scenarios to focus on - identify requirements for them.


Jim Bound agreed to work on a tools/mechanisms comparison document to
engage authors to help catgorize their respective efforts. 

Dale Finkelson agreed to work on a roadmap overview document (using
volunteer efforts as appropriate).

Alain Durand agreed to work on a transition scenarios document (using
volunteer efforts as appropriate).

___

6bone hardening - Bob Fink

Goals for the 6bone are changing:
ň The 6bone is almost 3 years old, and has focused mostly on testing out
standards and implementations
ň There is no restriction on running production traffic over the 6bone 
  (especially with the recent AUP clarification that itĆs up to the 6bone
participants to apply their own AUPs as appropriate, not the 6bone)
ň There is growing sentiment to harden the 6bone and start running
production traffic over it downside/upside?
ň Using a 6bone pTLA-derived prefix has only one downsideŕ eventually
everyone has to renumber

When that will be is anyoneĆs guess, but it wonĆt be until there is no
longer a useful deployment role for the 6bone
ň Meanwhile, the 6bone community can decide how to allocate its addresses,
and how to operate its networks through the IETF NGtrans WGĆs oversight
ň Oh yes, some might think it a downside that the 6bone is under the IETF
(you decide)

So what might hardening entail?
ň Review of "6bone Routing Practiceö I-D 
ň Route filtering to exclude non TLA routes
ň BGP4+ session monitoring to look for instability (a sub question is if
the Merit 6bone-routing-report is accurate)
ň Tunnel peering strategy to provide better routes
ň Registry changes related to improving the backbone
ň DNS issues related to improving the backbone
ň other issues appropriate (e.g., rules for becoming a pTLA)

How to proceed
ň A small Task Group to recommend to the the 6bone list, then to NGtrans in
Oslo
  (Bob noted that he had asked Rob Rockell of Sprint to lead the task group)
ň Folks volunteering should have strong pTLA and IPv4 routing experience
ň Contact Bob Fink to volunteer

Other issues
ň Might it make sense to have both production and experimental sides of the
6bone to differentiate need for backbone routing stability?  (have task
group speak to this as well)

ň Change in 3FFE:/16 usage structure to allow for more growth

Address change:

Move to a 13 bit pTLA 19bit NLA and exercise our renumbering skills.

Concern: this will make DNS delegation difficult in the absence of the A6
and binary records with this 13 bit boundary
Suggestion: 12 bits pTLA to keep bit boundaries multiple of 4.

Bob will send out to the 6bone list a proposal for this change.

___

Tools/mechanisms review for forwarding status (SIIT/AIIH/DTI/BIS/NAT-PT)

First, Harald  Alvestrand as the current OPS AD for NGtrans agreed to give
an overview of why and how to make a standard.

The purpose of the IETF is to make the Internet work and to provide standards.

Who decide if something is a standard? The AD does.

Standards: standards specify behavior
-       Must be asked for
-       Must be competent (must not have known problems)
-       May be useful. Need operational experience
-       Experimental means unstable: please go and experiment, we want to
document it, but we will change it
-       Informational means it will not go standard track
-       does not belong to IETF
-       descriptive material

___

SIIT - Erik Nordmak

Environment: one part is v6 only or dual stack, but some nodes are v6 only
and want to communicate to v4 hosts. SIIT does not specify how does the v6
only host gets the ôtranslatableö address.

Open issue: in IPv4 you can send UDP packets without checksum. This is not
allowed in IPv6.

Question to the room: how important is this? Case of running NFS over UDP.
But on large networks, you prefer to use TCP.

Question: what about NTP? Is there any other IPv4 UDP application which
turn off UDP checksums?

Question: can protocol translator be standards? Answer: yes

Question: do you need v4 routing within sites? You night use IPv6 in IPv6
tunnels.

In the draft, it says ôthe way you route within the site is out of the
scope of the documentö

Jim Bound general comments: ôexperimental means unstable, the market will
not accept itö.

Question: SIIT does not do authentication, which is mandatory in IPv6ŕ but
you are talking to a v4 system, not a v6, so the rule does not apply. This
is the kind of question that the IESG might ask, so weĆd better get ready
to answer this before going to standard track.

It seems that the SIIT meets the criteria for making it a standard, so
ngtrans should attempt to push SIIT forward to PS. Erik agreed to proceed
to ready SIIT for PS.

___

AIIH/DTI - im Bound

Jim announced that the AIIH and DTO authors have just started the
integration of AIIH and DTI into a new draft to be submitted soon.

>From AIIH: DNS mechanisms and address assignment, DHCPv6 reconfigure for
Ipv6/IPv4 nodes.

>From DTI: dynamic tunneling setup/dynamic tunneling interface/dynamic
tunneling black box.

Required components:
-       DHCPv6/DNS communication
-       DTI black boxes
-       DTI interface on IPv4/IPv6 hosts
-       Statically configure IPv4 pool of addresses
-       Statically configure tunnel end-points

We should wait for the new draft to decide what to do with the proposal,
but there is a good feeling that it meets the criteria to go to Standard Track

___

NAT-PT - Georges Tsirkis

Geroge gave a short generic presentation of NAT-PT. He noted that there are
3 implementation of NAT-PT at the moment.

NAT-PT is a complement to SIIT, so they are somehow linked. If we
standardize SIIT, we should standardize NAT-PT. Also, as NAT-PT references
SIIT, it is another incentive to standardize SIIT.

Comment: we should wait for the evaluation matrix before having any
document going to PS.

Comment: none of the draft is well written in good English.

Margaret Wasserman volunteered to review the English of NAT-PT

Comment: going to PS will draw more attention to the proposal.

It seems that the NAT-PT meets the criteria for making it a standard, so
ngtrans should attempt to push NAT-PT forward to PS. George agreed to
proceed to ready NAT-PT for PS (waiting on Margaret for her review).

___

Bump In the Stack (BIS) - Kazuaki Tsuchiya

Kazuaki gave a short general presentation of BIS.

Question: how does it relate to NAT-PT? The translation is the same, but
they are targeting different scenarios and are placed in different places.

Question to the room: is this mechanism useful? Answer: yes.

The are no outstanding technical issues with BIS, and it was agreed that
this mechanism can be useful. Thus it was agreed that BIS be reviewed for
quality by WG as if it would become PS, but accepting the fact that the
IESG might decide it should be informational. 

-meeting adjourned