(ngtrans) 2nd draft minutes of NGtrans WG meeting, Salt Lake City, IETF-52

[Bob Fink <[e-mail]>]

NGtrans Folk, (apologies for my earlier posting to the 6bone list)

Here is the 2nd version of the draft minutes of the ngtrans meeting in Salt 
Lake City. Please send comments and corrections to me or the list by Friday 
so I can submit the final minutes to the secretariat.

Thanks,

Bob

=============================
Minutes of NGtrans WG Meeting
13-14 December 2001
London IETF-51

=======
Chairs:
Alain Durand <[e-mail]>
Bob Fink <[e-mail]>
Tony Hain <[e-mail]>

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

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

Discussion ngtrans: <mailto: [e-mail]>
Subscribe ngtrans: <mailto: [e-mail]> "subscribe ngtrans"
Archive ngtrans: <http://www.wcug.wwu.edu/lists/ngtrans/>
Web site: <http://www.6bone.net/ngtrans>

Discussion 6bone: <mailto: [e-mail]>
Subscribe 6bone: <mailto: [e-mail]> "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 [e-mail]

     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 not 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

---