Next Generation Transition (ngtrans) Charter

2.3.12 Next Generation Transition (ngtrans)

NOTE: This charter is a snapshot of the 52nd IETF Meeting in Salt Lake City, Utah USA. It may now be out-of-date. Last Modified: 11-Oct-01

Chair(s):

Bob Fink <rlfink@lbl.gov>
Tony Hain <tony@tndh.net>
A Durand <alain.durand@eng.sun.com>

Operations and Management Area Director(s):

Randy Bush <randy@psg.com>
Bert Wijnen <bwijnen@lucent.com>

Operations and Management Area Advisor:

Randy Bush <randy@psg.com>

Mailing Lists:

General Discussion:ngtrans@sunroof.eng.sun.com
To Subscribe: majordomo@sunroof.eng.sun.com
In Body: subscribe ngtrans
Archive: ftp://ftp.ietf.org/ietf-mail-archive/ngtrans/

Description of Working Group:

1. Specify the tools and mechanisms that might be used for transition to IPv6.

2. Write documents outlining how the various transition tools and mechanisms might apply to various scenarios for a transition to IPv6.

3. Coordinate with the IPv6 6bone testbed, operating under the IPv6 Testing Address Allocation allocated in Experimental RFC 2471, to foster the development, testing, and deployment of IPv6.

4. Coordinate appropriately with other IPv6 related IETF activities and activities in other organizations.

Goals and Milestones:

Mar 01		Progress 6to4-multicast to PS
Mar 01		Decide to either merge 6to4-DSTM with DSTM or move it separately to Informational
Mar 01		Decide if BGP-tunnel is Informational or Experimental
Mar 01		Progress 6papa to Informational
Mar 01		Decide fate of ipv4survey as it has been deleted from I-D registry
Mar 01		Progress translator back to IESG for Informational
Mar 01		Decide how natreq4ipv6 should be processed
Mar 01		Progress socks-gateway back to IESG for Informational
Mar 01		Progress tcpudp-relay back to IESG for Informational
Mar 01		Decide what to do with personal draft hain-6to4-scaling
Mar 01		Decide what to do with personal draft tsao-mobileip-dualstack
Mar 01		Decide what to do with personal draft itojun-ipv6-local-experiment
Mar 01		Decide what to do with personal draft templin-v6v4compat
Mar 01		Decide what to do with personal draft durand-ngtrans-tunnel-endpoint
Mar 01		Decide what to do with personal draft tsuchiya-mtp
Aug 01		Progress 6to4-dns to either Informational or PS
Aug 01		Progress mimetype to PS
Aug 01		Progress DSTM to PS (keyed to DHCPv6 forwarding)
Aug 01		Progress hometun to Informational
Aug 01		Progress Transition description to Informational
Dec 01		Progress v4-over-mipv6 to Informational
Mar 02		Progress 6to4 to DS
Mar 02		Progress MECH to DS
Mar 02		Progress SIIT-DSTM to either Informational or PS
Aug 02		Progress NAT-PT to DS
Aug 02		Progress SIIT to DS

Internet-Drafts:

Request For Comments:

RFC	Status	Title

RFC2185		Routing Aspects of IPv6 Transition
RFC2765	PS	Stateless IP/ICMP Translation Algorithm (SIIT)
RFC2766	PS	Network Address Translation - Protocol Translation (NAT-PT]
RFC2767		Dual Stack Hosts using the Bump-In-the-Stack Technique (BIS)
RFC2772		6Bone Backbone Routing Guidelines
RFC2893	PS	Transition Mechanisms for IPv6 Hosts and Routers
RFC2921		6BONE pTLA and pNLA Formats (pTLA)
RFC3053		IPv6 Tunnel Broker
RFC3056	PS	Connection of IPv6 Domains via IPv4 Clouds
RFC3089		A SOCKS-based IPv6/IPv4 Gateway Mechanism
RFC3068	PS	An anycast prefix for 6to4 relay routers
RFC3142		An IPv6-to-IPv4 transport relay translator

Current Meeting Report

Minutes of NGtrans WG Meeting
13-14 December 2001
Salt Lake City IETF-52

=======
Chairs:
Alain Durand <Alain.Durand@eng.sun.com>
Bob Fink <fink@es.net>
Tony Hain <tony@tndh.net>

Alain Durand and Tony Hain chaired the meeting. Bob Fink took the minutes.
Attendance was just over 150.

===========================
Administrative information:

Discussion ngtrans: <mailto: ngtrans@sunroof.eng.sun.com>
Subscribe ngtrans: <mailto: majordomo@sunroof.eng.sun.com> "subscribe ngtrans"
Archive ngtrans: <http://www.wcug.wwu.edu/lists/ngtrans/>
Web site: <http://www.6bone.net/ngtrans>

Discussion 6bone: <mailto: 6bone@isi.edu>
Subscribe 6bone: <mailto: majordomo@isi.edu> "subscribe 6bone"
Archive 6bone: <http://www.wcug.wwu.edu/lists/6bone/>
Web site: <http://www.6bone.net>

======
Agenda
---
Thursday, 13 December, 1530-1730
-
Agenda Bashing, Chairs - 2 minutes

WG Status, Bob Fink - 3 minutes
<http://www.6bone.net/ngtrans/ngtrans_project-status.html>

Survey of IPv4 Addresses in Currently Deployed IETF Standards, Phil Nesser 15-30 mins
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-ipv4survey-01.txt>

NGtrans IPv6 DNS operational requirements and roadmap, Alain Durand - 15 mins
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-dns-ops-req-03.txt>

Plans for transition from ip6.int to ip6.arpa - Alain Durand 5 mins
<no draft published yet>

IPv6 SMTP operational requirements, Itojun - 15 mins
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-ipv6-smtp-requirement-04.txt>

Connecting IPv6 Islands across IPv4 Clouds with BGP, Dirk Oooms - 5-10 mins
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-bgp-tunnel-03.txt>

Dual Stack Transition Mechanism (DSTM), Laurent Toutain - 5 mins
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-dstm-05.txt>

Intra-Site Automatic Tunnel Addressing Protocol (ISATAP), Fred Templin - 5 mins
<http://www.6bone.net/ngtrans/misc/draft-ietf-ngtrans-isatap-02.txt>

An IPv6/IPv4 Multicast Translator based on IGMP/MLD Proxying (mtp), Kazuaki
Tsuchiya 5 mins
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-mtp-00.txt>

Dual Stack Hosts using "Bump-in-the-API" (BIA). Myung-Ki Shin 2 mins
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-bia-01.txt>

Application Aspects of IPv6 Transition, Myung-Ki Shin 5 mins
<http://www.ietf.org/internet-drafts/draft-shin-ngtrans-application-transition-00.txt>

Dual Stack deployment using DSTM and neighbour discovery, Gerard Gastaud 5 mins
<http://www.ietf.org/internet-drafts/draft-bereski-ngtrans-nd-dstm-00.txt>

Multicast extensions to dual stack hosts using the "Bump-In-the-Stack" Technique (mBIS), Kazuaki Tsuchiya 5 mins
<http://www.ietf.org/internet-drafts/draft-tsuchiya-mbis-00.txt>

IPv6 Traffic Engineering Tunnel, Hiroki Ishibashi - 5 mins (if time permits)
<http://www.ietf.org/internet-drafts/draft-ishii-ipv6-te-tunnel-00.txt>

---
Friday, December 14 at 0900-1000
-
Discussion of new ngtrans charter and future ngtrans work - chairs, 1 hour
<no ID, but an email to list was sent 1-week prior to meeting>

================================
Thursday, 13 December, 1530-1730

Agenda bashing

There were no changes to the agenda listed above

===
NGtrans Project Status - Bob Fink

SLIDES:
<http://www.6bone.net/ngtrans/IETF-52-SaltLakeCity/ngtrans-status.ppt>
<http://www.6bone.net/ngtrans/IETF-52-SaltLakeCity/ngtrans-status.pdf>

Bob presented the current status of NGtrans projects (see slides above).
For current status of projects, look at:

<http://www.6bone.net/ngtrans/ngtrans_project-status.html>

Bob noted that there were numerous drafts either expired in the ID directory and/or in an unknown state (i.e., not progressing), and that in the context of reevaluating the directions of ngtrans authors can expect to be contacted by the chairs to determine the future of these projects.

===
Survey of IPv4 Addresses in Currently Deployed IETF Standards, Phil Nesser
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-ipv4survey-01.txt>

SLIDES:
<http://www.6bone.net/ngtrans/IETF-52-SaltLakeCity/ipv4-addresses-ietf-stds.ppt>
<http://www.6bone.net/ngtrans/IETF-52-SaltLakeCity/ipv4-addresses-ietf-stds.pdf>

Phil presented a history and overview of his IPv4survey work

* Work Started in late 1999
First draft (-00) in May 2000
Second (current) draft (-01) in August 2001
* Goal of the project is to review all of the current IETF Standards for IPv4 assumptions to make sure a transition to IPv6 as smooth as possible

There are:

* Full Standards (68 RFCS)
* Draft Standards (65 RFCS)
* Proposed Standards (611 RFCS)
* Experimental (150 RFCS)

* Most of the work has been done as an individual effort
Reading Each of the 894 RFCS
About 25,000 pages of text
* PLEASE LOOK AT THE DRAFT FOR ANY RFCS THAT YOU HAVE KNOWLEDGE OF AND COMMENT

Current Results:

* The 01 draft was concerned with finding RFCS with problems
Full Standards: 26 RFCS (38.25%)
Draft Standards: 19 RFCS (29.23%)
Proposed Standards: 112 RFCS (18.33%)
Experimental: 23 RFCS (15.33%)
Total: 180 RFCS (20.13%)

* Each RFC was examined independently of all others
* Technique purposely chosen to give more false positives rather than accidentally missing something
* Helped reduce the scope of the individual investigation
* In the middle of reviewing the RFCS that came up positive in the first pass to see what problems are already fixed in later RFCS
* It is clear that many issues are already resolved, are in work, or can be fixed by registering a parameter with the IANA

Next Steps:

* Finish review of RFCS identified in the first pass to finalize a list of problem child RFCS that need some updates
* At the request of the IETF chair the project should also include a discussion of protocols that assume the long term stability of addresses
* Produce an 02 draft that summarizes the final results of the review later this month or early next month
* Produce a series of recommendations for any RFCS that still have problems and include a discussion on the long term stability of address in an 03 draft in early 2002
* Go to Last Call after the 03 draft is published

How You Can Help:

* READ THE DRAFT AND COMMENT
* Think about the long term stability of addresses issue and provide input
* READ THE DRAFT AND COMMENT
* … and in case it isn't clear, READ THE DRAFT AND COMMENT
It's 120 pages of gripping narrative, enjoy!

Francis Dupont asked if IPv6 over FDDI was fixed; did Phil get the comment.
Phil did.

Phil has a big problem trying to understand what protocols assume long term address stability.

Keith Moore felt that there is an unreasonable expectation that there is not a long term address stability requirement, thus this should be discussed at another place as a major architectural issue as he believes there is often a requirement for long term address stability. Phil noted this and pointed out that his context is just to note the occurrence of these.

Phil said that by early 2002 he will have a -03 with recommendation for RFCs that have a problem. Then the draft can go to last call.

Brian Carpenter congratulated Phil on his efforts, and noted that this is a real list of changes we need to make to real software. He also asked that everyone read and comment on the draft.

Keith Moore noted that the normal editing cycle may not be best place to handle this process, and that maybe putting up a web page would help. It was also noted that the ID editor might be able to help on this.

===
NGtrans IPv6 DNS operational requirements and roadmap, Alain Durand
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-dns-ops-req-03.txt>

SLIDES:
<http://www.6bone.net/ngtrans/IETF-52-SaltLakeCity/IPv6-DNS-integration.ppt>
<http://www.6bone.net/ngtrans/IETF-52-SaltLakeCity/IPv6-DNS-integration.pdf>

Alain presented the current status of plans to provide for successful operation of the DNS in a mixed environment of IPv4-only, IPv6-only and dual-stacks networks.

* 2 approaches
Let DNS break if it has to break
Make sure DNS works.
* Requirement document made by NGtrans, was presented in DNSext and DNSop.
* If the requirements are accepted, some work needs to be done in DNSext.

Architectural principles:

* The public DNS has a unique root valid for IPv4 & IPv6 (derived from RFC2826).
* DNS is an IP version agnostic application.
Any node (v4, v6, dual stack) should be able to query any record in any zone
Queries should get the same answers regardless of the IP version used during the process. (Note: this does not apply to additional sections)
* The burden has to be placed on new IPv6 systems

Consequences:

* A bridging system is needed
* Bridging does not need to be symmetric
* Any change to the existing IPv4 resolvers is out of scope.
* Bridging v4 to v6 is technically very difficult. However, It can be achieved by administrative procedures:
Mandate at least one v4 server per zone
Can be achieved by contracted 3rd party dual stack servers
* Bridging v6 to v4 requires something new.

Bridging requirements:

(v4 to v6 or v6 to v4)
* Any change to existing IPv4 resolvers is out of scope.
* The bridging system is required to have good scaling properties.
* The bridging system discovery is required to have good scaling properties.
* All zones should be reachable through the bridging system.
* Security is not an option in the IETF, that is it is mandatory.

DNSext comments/questions:

* Designing such a bridging system is not easy, may be a huge kludge.
* Draft-durand-dns-proxy-00.txt is an attempt at a possible solution.
* There might be other solutions.
* DNSext should be the place to design it.

Steve Deering asked if truncation of packets was an issue for getting the same answer in either transport. It was noted that this is not a problem, that just the main answer needs to be the same, not the packet size.

There were concerns expressed of bridging system scalability and complexity.

Steve Deering asked that if DNS was to be IP agnostic, what is an IPv6 zone. Alain noted that this meant a DNS zone available only over IPv6 transport.

Keith Moore asked why not an approach with no scaling problems, like every site having a resolver.

Perry Metzger noted that one could modify BIND to solve this.

Alain will continue with these efforts, with a strong focus on DNS folks who know what the issues are being involved in the solution.

===
Plans for transition from ip6.int to ip6.arpa - Alain Durand 5 mins
<no draft published yet>

SLIDES: none

Alain spoke briefly on planning now underway for a transition from ip6.int to ip6.arpa. He noted that how to make delegations were a registry problem, not ours. The harder problem is that there are lots of existing stub resolvers hardwired to ip6.int.

There are a few folk now working on problem with two solutions under study. Experiments with the approaches, and drafts describing the approaches are soon to come, so stay tuned.

===
IPv6 SMTP operational requirements, Itojun & Alain Durand - 15 mins
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-ipv6-smtp-requirement-04.txt>

SLIDES: full content is included below

Itojun presented the history of development of his ipvt smtp requirements draft:

03 draft completed WG last call for informational
Area director suggested a review by SMTP-related mailing lists
04 draft submitted to reflect comments
another comment received (not sure if it was for 03 or 04)
WG chair (alain) suggested changes in direction so this time slot

Outline of draft:

Operational requirements for IPv6 SMTP, and IPv6 DNS MX records
Goal: stable email transport in IPv6/v4 dual stack world
Similar content presented by Kazu, at IETFxx

Outgoing: be careful looking up all MX/A/AAAAs
Incoming: configure MX right, be sure to keep reachability among servers

Widely practiced by existing IPv6-ready MTAs because it is a natural extension to IPv4 SMTP behavior

IPv6 MX lookup (outgoing)

Same, but a bit more complicated

email to foo@example.org

Lookup example.org
MX - use it, based on preference (then A/AAAA)
A/AAAA - use it
CNAME - resolve till get to MX/A/AAAA

Be sure to try all available As and AAAAs
SMTP failure handling (4xx or 5xx) complicates the story

example.org. IN MX 1 mx1.example.org.
IN MX 10 mx10.example.org.
mx1.example.org. IN A 1.0.0.1 ; IPv4/v6 dual stack
IN AAAA 3ffe:501:ffff::1
mx10.example.org. IN AAAA 3ffe:501:ffff::2 ; IPv6 only

MX for dual stack sites (incoming)

Be sure to allow emails to get delivered to the final email server

If possible, make the most preferred MX a dual stack node

; easy and good config
easy.com. IN MX 1 v4only.easy.com.
easy.com. IN MX 10 dualstack.easy.com.
; good config
good.com. IN MX 1 dualstack.good.com.
good.com. IN MX 10 v4only.good.com.
; bad config
bad.com. IN MX 1 v4only.bad.com.
bad.com. IN MX 10 v6only.bad.com.

Outgoing from IPv6-only site to IPv4-only site?

THIS PART IS NOT IN THE DRAFT.
Just like last-resort relay rule for bitnet in sendmail.cf, this is outside of the protocol document
Make the server dual-stack
Use dualstack SMTP relay server in ISP
Purchase translation service from ISP

# sendmail.cf
# Smart relay host
DSdualstackrelay.isp.com

MX for IPv4/v6-only sites? (incoming)

THIS PART IS NOT IN THE DRAFT.
Not a protocol issue
Make the server dual-stack
Purchase SMTP relaying service from ISP
Purchase translation service from ISP

; rely upon ISP relay
v6only.com. IN MX 1 mail.v6only.com.
v6only.com. IN MX 10 dualstackrelay.isp.com.
%center, newimage -yscrzoom 40 "relayconfig.eps"

Itojun then outlined his discussions issues

How can I go forward with the document?

How far do we want to document? How to document?
updates to RFC2821 only, wrt IPv4/v6 address manipulation
some more details on MX setups <--- current
much more detail in operation
SMTP servers setup, interactions with translators, etc

Alain said that he was concerned about the title which is at odds with a goal of stable transport in dual stack world, thus he suggested to change title to only be specific to Itojun's draft goals, then start work on greater issue of entire transition of SMTP.

Keith Moore recommended that work be done elsewhere, i.e., in mail community, as there is lots of subtlety in correct handling of SMTP *failure* conditions, thus needs to be done by experts (probably in the apps area).

Christian Huitema felt that Keith was right, that the draft is fine but only looks at one problem. He noted that smtp is not the only app that has these problems.

Keith Moore emphasized that he wants to get IETF people outside of ngtrans involved, and this is good motivation for that.

Alain will work with Itojun on the renaming and how to proceed with other work in the SMTP community.

===
Connecting IPv6 Islands across IPv4 Clouds with BGP, Dirk Oooms
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-bgp-tunnel-03.txt>

SLIDES:
<http://www.6bone.net/ngtrans/IETF-52-SaltLakeCity/bgp-tunnel.ppt>
<http://www.6bone.net/ngtrans/IETF-52-SaltLakeCity/bgp-tunnel.pdf>

Dirk noted that there were two interpretations of the previous draft:

* MP-BGP/TCP/IPv4
includes implicit automatic tunnelling method
MP-BGP advertises an IPv4 BGP next hop (encoded as IPv4-mapped IPv6 address)
IPv6 data encapsulated in IPv4, MPLS, ...

* MP-BGP/TCP/IPv6
uses existing ngtrans method
MP-BGP advertises an IPv6 BGP next hop (address matches the used ngtrans mechanism)
IPv6 data encapsulated in IPv4 (and if desired subsequently in e.g. MPLS)

The new draft has been changed to explain the two approaches explicitly.

The applicability is:

* ISP familiar with BGP (and possibly already offering VPN services) that wants to offer native IPv6 services without wanting to upgrade its backbone

* ISP only needs to upgrade (some of) its PE routers

What's next?:

* Applicability statement will be added
* Earlier it was agreed to go for informational:
- Most of it is informational
- But address encoding in "IPv4 BGP next hop" approach needs to be standardized to assure interoperability => move to standards track
* Ready for last call after update?

Tony said we cannot decide here about the possibility of changing to standards track, so this will be taken offline.

===
Dual Stack Transition Mechanism (DSTM), Laurent Toutain
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-dstm-05.txt>

SLIDES:
<http://www.6bone.net/ngtrans/IETF-52-SaltLakeCity/dstm.ppt>
<http://www.6bone.net/ngtrans/IETF-52-SaltLakeCity/dstm.pdf>

Major Change
* Annex lists some ways to configure interfaces:
- Manual, RPCv6, DHCPv6
- Allow 3G to specify its own protocol ?

* Don't mandate an address allocation mechanism
- One document describing DSTM
- Several documents to define address allocation and mapping.
- Common to other ngtrans protocols (SIIT, Tunnel Broker)

* Issue ASAP new drafts and be ready for last call

Alain note that he needs to see how the new separated drafts look to decide how to progress draft, and that he was pleased with this new direction.

===
Intra-Site Automatic Tunnel Addressing Protocol (ISATAP), Fred Templin
<http://www.6bone.net/ngtrans/misc/draft-ietf-ngtrans-isatap-02.txt>

SLIDES:
<http://www.6bone.net/ngtrans/IETF-52-SaltLakeCity/isatap.ppt>
<http://www.6bone.net/ngtrans/IETF-52-SaltLakeCity/isatap.pdf>

Fred reported on ISATAP Status

* draft-ietf-ngtrans-isatap-02.txt published
* "ISATAP Issues" message posted to mailing list
* Linux ISATAP implementation announced. HOWTO at: v6web.litech.org/isatap/

Experimentation encouraged!
(Thanks Nathan Lutchansky and Yoshifuji Hideaki!)

IPv4 anycast vs. DNS w/multiple RR's Author prefers anycast:

* IPv4 anycast is a *configuration option*;
NOT a feature of IPv4 addressing i.e. ANY topologically-correct
IPv4 prefix can be used for IPv4 anycast use within the site:
- allocate IANA prefix/use existing IANA prefix for easy configuration (vote?)
- Site administrators can override with DNS entry (single RR); static config if desired

IPv4 Anycast vs. DNS

* v4anycast allows hosts to operate exactly as RFC 2461, section 6.3:
- Default router *lists* constructed
- Redirects; other ND features work as per 2461

* v4anycast provides easy security check (i.e. only accept RAs from v4anycast)

Router solicitation w/Anycast

* ISATAP host sends RS with:
v6_src=FE80::0:5EFE:V4ADDR_HOST
v6_dst=FF02::2
v4_src=V4ADDR_HOST
v4_dst=V4ANYCAST

* ISATAP Router sends RA with:
v6_src=FE80::0:5EFE:V4ADDR_RTR <= works w/2461
v6_dst=FE80::0:5EFE:V4ADDR_HOST
v4_src=V4ADDR_ISATAP (note: corrected per F. Dupont)
v4_dst=V4ADDR_HOST

Router solicitation interval

* RFC 2461, section 6.3.7 gives list of acceptable reasons for hosts to re-issue RSs.
One says: "- the host re-attaches to a link after being detached for SOME TIME"

Author's recommendation for ISATAP:

* Host deems itself to be detached from the ISATAP interface immediately after receiving solicited RA (i.e. expects to NOT receive unsolicited RA's)
* Host sets "SOME TIME" == Router Lifetime/2, for some Router Lifetime in default router list.
* Is RFC 2461 language needed? Suggestion, "A link should NOT deem itself to be detached arbitrarily; only if it KNOWS it cannot receive unsolicited RAs"

Security

* Source address spoofing for ISATAP peers:
If v4_src != embedded V4ADDR in v6_src …

* Source address spoofing for forwarded messages:
If v4_src != embedded V4ADDR in reverse routing lookup for v6_src …

* Reverse routing lookup trust based on v4_src=v4anycast in RAs

Open Issues Since London

* When to deprecate ISATAP address?
- Old answer: when native IPv6 Rtadv's heard
- New answer: when native Rtadv's heard AND ISATAP interface usage drops below some threshold
- NEWER ANSWER: make it work the same as RFC 2462, section 5.5.4 Address Lifetime Expiry

* Will ISATAP addresses be preferred over native IPv6 addresses by longest prefix-match?
- No destination ordering will fix this (already addressed in source/destination selection draft)

NAT Clarifications:

* Will ISATAP work on the private network side of a NAT?
- Yes!

* Will ISATAP work *across* NAT?
- NO - NON-GOAL!

* Other NGTRANS works address NAT traversal

* ISATAP is complementary to these

Fred wanted a straw vote on use of anycast prefix. Alain wanted to take this issue to the mail list.

Jim Bound wantd to support authors recommendation.

===
An IPv6/IPv4 Multicast Translator based on IGMP/MLD Proxying (mtp), Kazuaki Tsuchiya
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-mtp-00.txt>

SLIDES:
<http://www.6bone.net/ngtrans/IETF-52-SaltLakeCity/mtp.ppt>
<http://www.6bone.net/ngtrans/IETF-52-SaltLakeCity/mtp.pdf>

Kazuaki took a review of MAGMA (multicast specialists) yesterday.

* The effectiveness of MTP was acknowledged by MAGMA.

* MAGMA indicated that a few points remained to make clear.

It was decided to go on with discussion on these on the mail list.

===
Dual Stack Hosts using "Bump-in-the-API" (BIA). Myung-Ki Shin
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-bia-01.txt>

SLIDES:
<http://www.6bone.net/ngtrans/IETF-52-SaltLakeCity/bia.ppt>
<http://www.6bone.net/ngtrans/IETF-52-SaltLakeCity/bia.pdf>

Myung-Ki covered changes since IETF-51:

* Published 01 version <draft-ietf-ngtrans-bia-01.txt>

* Editorial changes
- Applicability statements section
- Disclaimers section

* Added API function list intercepted by BIA module [Appendix]

Open Issue:

* Problem
- A client node running BIA trying to contact a dual stack node on a port number that is only associated to an IPv4 application.

* There are 2 approaches
- 1- the client node should cycle through all the addresses and end up trying the IPv4 one
- 2- BIA should do the work.

* It is not clear at this time which behavior is desirable so we need to get feedback from experimentation.

Next Steps:

* Go to wg last call
- We propose to publish the draft with experimental status to give it wide circulation and ask for implementation feedback.

* Once feedback will have determined which behavior is desirable (it may very well be application dependant), we should republish the draft with Informational status.

===
Application Aspects of IPv6 Transition, Myung-Ki Shin
<http://www.ietf.org/internet-drafts/draft-shin-ngtrans-application-transition-00.txt>

SLIDES:
<http://www.6bone.net/ngtrans/IETF-52-SaltLakeCity/bia.ppt>
<http://www.6bone.net/ngtrans/IETF-52-SaltLakeCity/bia.pdf>

Why this draft?

* As IPv6 is deployed, there are some problems that the application developers and the administrators face.

* This draft clarifies the problems occurred in transition periods between IPv4 applications and IPv6 applications.

What is problem ?

* Dual stack host does not mean having both IPv4 and IPv6 applications.

* We cannot know the version of peer application only by DNS name resolving.

* We have three types of IPv6-enabled applications.
- IPv4+BIA
- IPv6 native
- Both IPv4 and IPv6 support

* Application selection problem
- System administrator can be confused by various combinations of application versions and Ngtrans mechanisms.

Next Steps

* We need consensus on these problem statements.
* Are there any other problems or issues for application transition now, and in the future ?

* Do we need guidelines for application transition ?
- This draft will propose guidelines to implement and choose the suitable application under the various current transition environments.

* Become a ngtrans project.

Brian Zill commented that this needs to be a living document as it could be years before a polished and finished document can be delivered. He felt this is important work, but cannot be done quickly.

Tony and Alain noted that this is a project that at least needs coordination with the Applications area, so the chairs will interact with those area directors to see what works.

===
Dual Stack deployment using DSTM and neighbour discovery, Gerard Gastaud
<http://www.ietf.org/internet-drafts/draft-bereski-ngtrans-nd-dstm-00.txt>

SLIDES:
<http://www.6bone.net/ngtrans/IETF-52-SaltLakeCity/nd-dstm.ppt>
<http://www.6bone.net/ngtrans/IETF-52-SaltLakeCity/nd-dstm.pdf>

Gerard presented ND-DSTM for consideration as an ngtrans project. He noted that DSTM is a powerful and useful element in the NGTRANS tool box for both mobile and enterprise environments.

Though DSTM has been associated with DHCP, which has been delayed, something is needed. ND-DSTM uses IPv6 neighbour discovery [ND] to manage IPv4 address allocation. The draft show how a border gateway using extensions to ND can manage this allocation process.

A Dual Stacked Host (DS-H) starts a communication with a v4 host in a remote domain according to DSTM.

When DS-H needs it, it requests an IPv4 address of the DSTM router by means of an "RS"" message.

The DSTM router assigns an IPv4 address to the DSH by means of an"RA" message.

RA/RS messages are tunnelled into IPv6 to override the local link scope of the ND messages.

To accomplish this, 2 new options are required: an RS DSH mapping request and an RA DSTM reply.

Gerard noted that the authors want ND-DSTM to be one of the implementations of the DSTM architecture.

Alain Durand was concerned that host may require manual configuration. He asked developers if they would accept the tunnel if it is not configured.

Jim Bound said it would be dropped if not configured, but this shouldn't stop use of the idea.

Christian Huitema said that it will be dropped.

Author said they will resubmit a new draft in the context of other DSTM changes. When the new draft is available, it will be evaluated as a project again.

===
Multicast extensions to dual stack hosts using the "Bump-In-the-Stack" Technique (mBIS), Kazuaki Tsuchiya
<http://www.ietf.org/internet-drafts/draft-tsuchiya-mbis-00.txt>

SLIDES:
<http://www.6bone.net/ngtrans/IETF-52-SaltLakeCity/mBIS.ppt>
<http://www.6bone.net/ngtrans/IETF-52-SaltLakeCity/mBIS.pdf>

Kazuaki presented his mBIS draft for consideration as an ngtrans project. This draft describes a mechanism which allows existing hosts to speak in IPv6 multicast using existing IPv4 multicast applications. This is an extension of the original BIS work, now Informational RFC2767.

There was no show of support for mBIS as an ngtrans project among attendees, thus mBIS will be taken to the ngtrans list to confirm this.

===
IPv6 Traffic Engineering Tunnel, Hideo Ishii
<http://www.ietf.org/internet-drafts/draft-ishii-ipv6-te-tunnel-00.txt>

SLIDES:
<http://www.6bone.net/ngtrans/IETF-52-SaltLakeCity/IPv6-TE-tunnel.ppt>
<http://www.6bone.net/ngtrans/IETF-52-SaltLakeCity/IPv6-TE-tunnel.pdf>

This document specifies a method to transmit IPv6 traffic over IPv4 MPLS Label Switched Paths (LSPs) constructed by RSVP-TE. The way to transmit IPv4 and IPv6 traffic over IPv4 MPLS LSPs and the way to exchange routing information are described. This method allows Traffic Engineering for IPv4 and IPv6 separately or both inclusively.

The advantages of this approach are:

* From the IPv6 point of view, these are ordinal logical interfaces (Similar to tunneling interfaces) capable of IPv6.

* Can use any routing protocols among IPv6 PE routers. OSPFv3, RIPng and of course BGP4+.

* Traffic Engineering for IPv4 and IPv6 separately or both inclusively.

Alain Durand noted that a review of rfc/id directory shows several ip over mpls docs, and that he is not sure it fits here in ngtrans. He suggested that the authors should go to talk to Internet area director as it is not applicable here.

============
Friday, December 14 at 0900-1000

===
Discussion of new ngtrans charter and future ngtrans work - chairs
<http://www.6bone.net/ngtrans/IETF-52-SaltLakeCity/ngtrans-charter.txt>

SLIDES:
<http://www.6bone.net/ngtrans/IETF-52-SaltLakeCity/ngtrans-charter-revision.ppt>
<http://www.6bone.net/ngtrans/IETF-52-SaltLakeCity/ngtrans-charter-revision.pdf>

Tony Hain presented the new charter revision goals.

- Document operational requirements and recommended practises for major pieces of the Internet infrastructure in a mixed world of IPv4 only, IPv6 only and dual stack nodes. Those pieces include, but are not limited to: Routing, DNS, Mail, Network monitoring, Web, Multicast, VoIP,...

This work is to be done in cooperation with the relevant experts and/or the relevant working groups when applicable.

- Serve as a review board and body of competence and coordination for IPv6 transition and operational issues that span multiple IETF working groups. This includes providing technical input to the IESG/IAB, IANA, the Internet Address Registries and operational communities, with regard to IPv6 transition and operation related issues, e.g., address allocation policies and procedures and operational management mechanisms.

- Coordinate with the IPv6 6bone testbed, operating under the IPv6 Testing Address Allocation allocated in Experimental RFC 2471, to foster the development, testing, and deployment of IPv6.

- Keep all IPv6 transition tool documents moving along publication / standardization track. Those tools enable transition to a mixed world of IPv4 only, IPv6 only and dual stack nodes. They falls into three categories:
- dual-stack tools which assure that both protocols are supported equally throughout the infrastructure.
- tunneling tools to enable IPv6 island to communicate over an IPv4 infrastructure
- translation tools that enable communication between IP4 and IPv6 nodes. As a large number of tools are already documented, new tools would have to justify the problem space they are solving that is not already addressed by existing tools/mechanisms.

- Document how to use those tools in major transition scenarios and document how those tools interact together.

The non goals of this working group are:

- Define extensions to IPv6. this is done in the ipv6 working group.

- Develop multi-homing solutions. This is done in the multi6 working group.

- Define particular extensions for IPv6 to existing Internet protocols. This is done in the relevant working groups.

- Define or document tools/mechanisms/scenarios that are only applicable to very specific environment and are not representative enough of a wide community.

Brian Carpenter commented that new schemes need be described with scenarios before issue comes up. Also, what about retiring under-utilized tools (e.g., 6over4). Tony felt that missing pieces will pop out of work on transition scenarios, and unused ones will as well.

Francis Dupont noted that 6over4 not on any list in ngtrans. Tony replied that it isn't an ngtrans project. If appropriate to discard 6over4 as ngtrans progresses to a better understanding of what's important and what's not, the IPv6 WG will be asked to reconsider 6over4.

Brian Zill, as one developer, noted that he wouldn't care if 6over4 went away.

Bob Hinden commented that Nokia has an implementation of 6over4.

Tony asked for input on new project criteria. He noted that refused projects will go to the mail list for confirmation. The new rules for new ngtrans project are:

* it fits within the ngtrans charter

* it addresses a relevant issue in a timely fashion must apply to a wide audience

* there is sufficient interest in the wg unsolicited projects must be presented to the list to generate discussion, after a presentation to the group, interest must be shown on the list

* the issue has not been solved previously must show why current mechanisms are insufficient

Perry Metzger said that if someone comes up with a really great idea, overwhelming support should ovedride rules, but in general not; the rules are good.

Christian Huitema commented that we are done making new tools, that we should fix broken stuff, and we shouldn't invent new ones.

Randy Bush, wearing his AD hat, said that as we turn from ngtoys to ngtrans, we may find serious scenarios that reveal gaps that need to be filled.

Itojun noted that transition scenarios may be different for different environments. He is not sure we can agree on single scenario. Tony replied that we need to get lots of ops community feedback from folks who will use these tools.

The meeting adjourned.

end

---

Slides

None received.