2.4.10 Next Generation Transition (ngtrans)

NOTE: This charter is a snapshot of the 49th IETF Meeting in San Diego, California. It may now be out-of-date. Last Modified: 11-Oct-00


Bob Fink <rlfink@lbl.gov>
Tony Hain <tonyhain@microsoft.com>
Alain 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:

Dec 94


Submit Internet-Draft on General Overview of Transition.



Submit Internet-Draft on Specifications of Transition Mechanisms for IPv6 Hosts and Routers.



Submit Internet-Draft of Transition Plan for the Internet.



Submit Internet-Draft on Specification of mechanisms for header translating routers.



Sunbmit Specification of Transition Mechanisms for IPv6 Hosts and Routers to IESG for consideration as a Proposed Standard.

Apr 95


Submit Specifications for Header Translating Routers document to IESG for consideration as a Proposed Standard.

Jul 95


Submit Specification of mechanisms for header translating routers to IESG for consideration as a Draft Standard.

Mar 96


Submit Specifications of Transition Mechanisms for IPv6 Hosts and Routers to IESG for consideration as a Draft Standard.

May 96


Register 6bone.net with InterNIC and establis dns support

Jul 96


6bone startup with UNI-C/DK, G6/FR and WIDE/JP

Aug 96


Establish ftp-based 6bone registry at RIPE-NCC

Nov 96


Submit Internet-Draft on role of IPv4-compatible Addresses in IPv6

Dec 96


Start restructuring 6bone to a tiered backbone architecture

Mar 97


Submit Internet-Draft for an IPv6 registry on site database objects.



Convert 6bone registry from ftp-based to RIPE-based



Start conversion of 6bone to Aggregatable Unicast Address Format

Nov 97


Testing starts on new Aggregatable Unicast Address Format



RFC 2471 formalizes IPv6 Testing Address Allocation



Hold Interim meeting in Grenoble



Submit update to RFC1933 to IESG for consideration as a Proposed Standard

Jul 99


Submit modified RFC1933 to IESG for consideration as a Draft Standard

Dec 99


Submit 6to4/AIIH-DTI/NAT-PT/BIS I-Ds for IESG processing

Dec 99


Submit Roadmap I-Ds for IESG processing as Informational RFCs

Mar 00


Evaluate state of roadmap, tool and mechanism docs for further work


Request For Comments:






Routing Aspects of IPv6 Transition



Stateless IP/ICMP Translation Algorithm (SIIT)



Network Address Translation - Protocol Translation (NAT-PT]



Dual Stack Hosts using the Bump-In-the-Stack Technique (BIS)



6Bone Backbone Routing Guidelines



Transition Mechanisms for IPv6 Hosts and Routers



6BONE pTLA and pNLA Formats (pTLA)

Current Meeting Report

Minutes of NGtrans WG Meeting
11 & 14 December 2000
San Diego IETF-49

Alain Durand <Alain.Durand@eng.sun.com>
Bob Fink <fink@es.net>
Tony Hain <tonyhain@microsoft.com>

This ngtrans meeting reported by Bob Fink.

Attendance was ~200.

Alain Durand chaired the meeting.

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>


Monday meeting agenda:

Agenda Bashing

Resolution of SOCKS last call comments from IESG / 10 mins, Alain Durand

NGtrans Project status / 10 mins, Bob Fink

6to4 Scaling Issues:
Evaluating 6to4 gateway discovery mechanisms / 5 mins, Alain Durand
A 6to4 Relay anycast prefix / 10 mins, Christian Huitema
6to4 scaling issues / 10 mins, Tony Hain
Tunnel end point in DNS / 5 mins, Alain Durand
Open discussion of 6to4 gateway discovery mechanisms / 10 mins

6to4 multicast / 10 mins, Dave Thaler

Inverse lookups for 6to4 addresses / 10 mins, Keith Moore

DSTM related:

DSTM current status / 10 mins, Jim Bound
Dual Stack deployment using DSTM and 6to4 / 10 mins, George Tsirtsis
Extensions to SIIT and DSTM for enhanced routing of inbound packets /
10 mins, Hesham Soliman

Thursday meeting agenda:

Testing the new DNS stuff without risk to the production root / 5 mins, Tony Hain
On overview of the introduction of IPv6 in the Internet / 5 mins, Alain Durand
Hometun / 10 mins, Francis Dupont
Mime type / 5 mins, Alain Durand
Introducing Mobile IP in IPv4/IPv6 Interconnected networks / 10 mins, Charles Tsao
IPv4 over Mobile IPv6 for Dual Stack nodes / 10 mins, George Tsirtsis
Guidelines for IPv6 local experiments / 5 mins, Itojun
Connecting IPv6 Domains across IPv4 Clouds with BGP / 10 mins, Dirk Ooms
Multicast translator efforts, do we proceed / Alain Durand/K. Tsuchiya
<draft-tsuchiya-mtp-00.txt>v6v4compat / 10 mins, Fred Templin
Discussion of possible new tools/mechanisms to assist transition / all

Monday meeting:

Resolution of SOCKS last call comments from IESG / Alain Durand

Marcus Leech discussed his comments, noting he felt that the draft was too vague on what is and is not possible using SOCKS.

Hiroshi Kitamura noted there is no clear idea how to meet the comments beacuse the comments are specific clarification of weak points of the native SOCKS mechanism.

There are already sentences to warn of the restrictions of SOCKS usage in the current I-D.

See Hiroshi's slides at:

Alain noted that something needs to be added. For example, taking some of Marcus' text and modifying Hiroshi's words and put it into section 5, applicability.

Kitamura agreed to do this and will produce a -06 draft soon.

Project status report / Bob Fink

Bob presented ngtrans projects status, which can be viewed anytime from the ngtrans web site's project status pages noted above.

Project status:

MECH - at PS waiting on more experience to move to DS
SIIT - at PS waiting on more experience to move to DS
NAT-PT - at PS waiting on more experience to move to DS

6TO4-07 - approved by IESG for PS

BROKER-06 - approved by IESG for info RFC

SOCKS-GATEWAY-05 - last phase of resolving IESG comments for info rfc
TRANSLATOR-03 - last phase of resolving IESG comments for info rfc
TRANSITION-05 - working on next draft
DSTM-03 - soon to go to wg last call for PS forwarding
6PAPA-01 - waiting on more RIR action on sub-TLA policy
TCPUDP-RELAY-01 - resolving IESG comments for info rfc
IPv4SURVEY-00 - waiting for next draft
HOMETUN-01 - waiting for wg comments on new draft

6BONE- continuing to operate, continued efforts to harden backbone routing, continuing to assign pTLA's (48 countries now participating, Turkey next!, 75 networks acting as pTLA backbones)

Specific personal drafts or general topics accepted as ngtrans projects

6to4 relay discovery and related scaling issues - Huitema, Hain, Durand
6to4 multicast - Dave Thaler
6to4 reverse DNS - Keith Moore
MIME type for tunnel end points - Alain Durand

Personal drafts not yet accepted as ngtrans projects

Dual Stack deployment using DSTM and 6to4 - George Tsirtsis
(accepted as a project later at this meeting)

Extensions to SIIT and DSTM for enhanced routing of inbound packets - Soliman
(accepted as a project later at this meeting)

IPv4 initiated connections to IPv6-only node (applies to DSTM & NAT-PT) - no author identified yet

Introducing Mobile IP in IPv4/IPv6 Interconnected networks - Charles Tsao

IPv4 over Mobile IPv6 for Dual Stack nodes - George Tsirtsis
(accepted as a project later at this meeting)

Connecting IPv6 Domains across IPv4 Clouds with BGP - Dirk Ooms

Multicast translator efforts - K. Tsuchiya

v6v4compat - Fred Templin

Bob noted that this latter category is a responsibility for ngtrans, i.e., that we must decide for each draft whether it will be accepted as a work-item/project.

6to4 Scaling Issues

Evaluating 6to4 gateway discovery mechanisms / Alain Durand

See Alain's slides at:

Alain presented ideas on what criterria to use to evaluate 6to4 relay gateway discovery mechanisms, of which there are currently 3. We should ask:

does it scale
how much config does it require
ease of deploymenet
transitioning away from the mechanism when we go native
can we customize a gateway to only serve a restricted ipv6 or v4 population
does the deployment require cooperation from all/some isps
security issues
IPv4 & IPv6 coupling
what happens if the ipv6 side of the 6to4 gateway dies but the v4 side keeps advertising it
how to deal with rogue gateways

Keith Moore asked how a relay advertizing its address then stopping is any different from any router that stops bgp advertizing. Also, is a rogue any different here.

Alain stated that we need to be aware of the limitations, even if they are similar.

A 6to4 Relay anycast prefix / Christian Huitema

See Christian's slides at:

Problem is that relays are needed to enhance 6to4 to reach pure IPv6 domains.

Christian proposes to use an IPv4 anycast address:

reserve an AS number for IPv6
reserve an IPv4 /16 prefix (or whatever IANA chooses) for IPv6 (x.y.0.0/16)
derive anycast address x.y.0.1
routing by 6to4 routers:
if know-better, do it
else if 6to4 packet, send it to 6to4 address
else send to anycast address

the 6to4 relay routers must publish 6to4 prefix in IGP (IS-IS, OSPF, RIP,...) domains publish BGP path, AS+prefix


does it scale? yes, add more routers
discovery and failover? routing
access control? BGP peering process
why do we need a large prefix? because of filtering in bgp
why do we need a specific AS no.? for clean BGP handling
will this slow down the move to v6? in fact, it allows easier reach of core!

the size is only needing to be big enough to route, but will ask for a large and settle for a small concern over actions of unfriendly ISP's

Brian feels isps will block what they want regardless.

Randy: ISP's aren't interested in stopping v6.

Alain: is there a business incentive?

Next steps:

submit to IANA for a prefix and AS no.
publish as an info rfc

Keith asked if initailly an isp is reluctant to advertize a relay to not draw all the traffic.

Thaler: make each side of the relay dependant on the other being up.

It was noted by the chairs that this should be standards track, not informational. It was also agreed to query the list for support of this as the preferred discovery mechanism, then go immediately to a wg last call to speed up the process of acquiring the anycast address allocation and AS no.

6to4 scaling issues - 10 mins, Tony Hain

See Tony's slides at:

The problem is simple discovery of the path from 6to4 routers to native-IPv6 routing domain.

The proposed solution is:

Treat IPv4 fabric as a logical NBMA link, since the IPv4 network appears as a link layer, all existing link layer rules apply including redirect.

For the purposes of 6to4, there is a defined mapping to the IPv4 anycast for 6to4-relay routers to solve the ND problem without multi-cast

Open Issues:

Relays don't know IPv4 address of the 'redirect-to' relay; they do know the ipv6 one so they send a source routed packet to their 6to4 address via the native IPv6 of the prospective target relay.

Tony noted that he liked Christians anycast mechanism.

Brian Carpenter noted his concern over the redirect mechanism as we are losing the virtues of simplicity.

Someone else noted that routers could redirect traffic from one to the other? could be avoided if host.

Steve Deering: redirects are used for routers to hosts, not routers to routers as routing protocols are normally used. This may be a more generic problem that should be solved elsewhere.

Keith Moore: complexity? isn't it just a redefinition of mechanisms we have? Steve responded, don't muddy terminology by redefining what a router is.

Erik Nordmark: are redirects for single network? Tony responded it is for a prefix.

Tunnels end point in DNS - 5 mins, Alain Durand

See Alain's slides at:

Alain described his tunnel endpoint discovery using DNS proposal, as he had done in Pittsburgh.

Steve Deering asked why Alain said the TEP info may be cached in the 6to4 router, as it must be cached.

Dave Thaler asked what the convergence is to get connectivity again? Long time? Also, bursty source problem.

Other question: Does the Hain and Durand proposals assume v4 is faster than v6. Is this a long term problem as v4 gets slow? Well, 6to4 itself is based on this. Real issue is how easy to move away from 6to4.

Open discussion of 6to4 gateway discovery mechanisms / Durand

Perry Metzger: doesn't think it will be hard to transition away from 6to4.

Keith Moore: thinks renumbering is same for 6to4 as for native prefix.

Ross Callon: as relays added, dns refreshes required...daily.

Jim Bound: need a place to store TEPs. Supports Alain's idea.

Keith Moore: may need special dns to be responsive to changes in relay routers.

Christian Huitema: dns is struggling already, do we want to add to this?

Steve Deering: likes anycast approach, but what is difficulty in getting a prefix?

Perry Metzger: prefers anycast, but not concerned that dns can survive the scaling.

Ross Callon: prefers anycast, simpler more straighforward, rarity of situation warrants a prefix.

Consensus of room? seems to be infavor of the anycast.

Steve Deering asked what the process should be? Tony Hain relied that it should be taken to the list for validation of consensus on anycast approach, then it could be last called if draft is ready (whch Christian tought it was).

Scott Marcus of ARIN, stated that he believes the anycast approach and necessary prefix are not onerous, and RIR's would be happy to go along, pending review of course.

Chairs agreed to take the anycast question to the list and process Christian's draft for last call if there continued to be consensus from the list.

END 6to4 Scaling Issues

6to4 multicast / Dave Thaler

See Dave's slides at:

Chairs noted that this draft was accepted as an ngtrans project and will be published.

Dave stated that the final open issue is which choice to take for site-site mcast, so he requested a last call for forwarding after he issued the next draft to resolve this issue.

This will be a Standards Track project.

Inverse lookups for 6to4 addresses / Keith Moore

See Keith's slides at:

Keith, noting that inverse lookups really matter, stated his goals:

Minimize impact on software and operations
Reasonable efficiency
Minimize deployment effort
Costs borne by those who benefit
No adverse effect on security
Explicit referrals take precedence

Keith noted the choices:

(A) Authoritative servers generate new static records (based on existing records)
(B) Pseudo-records generated by DNS zone servers
(C) Pseudo-records generated by DNS resolvers
(D) Pseudo-records inferred by client query libraries

Perry Metzger: a & b easy, c & d not. Keith thinks c & d is preferrable.

Matt Crawford noted that Keith overlooked the exit strategy, i.e., what to do as 6to4 goes away.

client changes required

Keith wants feedback on list for next draft for what has he missed, and is one of the approaches viable and/or worth pursuing (burden of deployment).

DSTM related

DSTM current status / Jim Bound

See Jim's slides at:


Jim outlined his next proposed steps for DSTM:

Align DHCPv6 IPv4 Global Address Request with new DHCPv6 options
Do last call for DSTM
Urge DHCPv6 WG to complete DHCPv6 Last Call
Move DSTM to Proposed Standard
Publish Draft January 2001 with DSTM Extensions

At this point ngtrans is in a wait mode for DHCPv6 last call processing before going to last call for PS for DSTM.

Dual Stack deployment using DSTM and 6to4 / George Tsirtsis

See George's slides at:

George noted that it is desirable that most of IPv6 deployment is based on Dual Stack IPv4 and IPv6 nodes so that interoperability with the current IPv4 based Internet be seamless. The [6to4] transition mechanism offers automated mechanisms for addressing an IPv6 site as well as interconnectivity with other IPv6 sites when no native IPv6 connectivity is available. DSTM provides a mechanism for dynamic IPv4 address allocation to Dual Stack nodes and a mechanism to send packets over a network that only supports IPv6 routing. By combining the two mechanisms we show how Dual Stack Intranets may be deployed with minimum need for IPv4 address space and no native IPv6 connectivity.

George also noted that no new protocol is defined in his draft.

George asked how to process this work; should it be added to 6to4? No, as 6to4 is being published now.

Brian Zill suggested adding to dstm. It was decided to take this issue offline with chairs and other authors.

George requested that this become a wg project. There was consensus to do this.

Extensions to SIIT and DSTM for enhanced routing of inbound packets / Hesham Soliman

See Hesham's slides at:

Quoting from the draft's abstract: "This document specifies a transition mechanism that combines both [SIIT] and DSTM mechanisms by adding some extensions to allow fast routing of inbound packets. This will result in a more decentralised and flexible tool to allow V6 only hosts to communicate with V4 only hosts. The proposed extensions will provide a way that allows SIIT routers to route packets addressed to a host running a single IPv6 stack with minimum delay which is suited to real time services."

Hesham requested that this now become a wg item. Consensus was to do this.

This will be Standards Track, but could be Informational pending further discussion between the chairs.

END DSTM related

adjourn for the day

Thursday meeting:

DNSop concerns about IPv6 DNS root / Tony Hain

Tony talked about the concerns of proposed experiments for dns root to test ipv6 new stuff that occurred at this weeks dnsops mtg.

Randy Bush noted that anyone trying to do such as this should create a proposal on what they are trying to do this for, and what the problems might be.

Tony noted that this was not meant to be negative of v6 efforts. There was no documentation and no plan of what was being done, but what was understood was that damage to the running dns might happen.

Jim Bound wanted to make a recommendation to the IPv6 Forum that folks only use AAAA records for now as there is no problem using them.

Randy and Tony noted this is not a v6 (A6) prob, just that testing might damage the production root, and that production plans are needed for testing. Even trying to keep the test v6 roots to pure v6 could still leak if some client was dual stack and polute the production root.

A chair of dnsops stated that he wanted ngtrans opinion on what is needed here.

Perry Metger noted that he wants a production v6 dns.

Ran Atkinson wants a draft on what people want for deployment.

Randy Bush was not sure cache pollution is a problem, and this didn't involve root servers.

Tony said running one root w/v6 might work.

There was no specific action for ngtrans taken as this is in general not considered an ngtrans problem. The v6 root testing efforts referred to at dnsops were not output of ngtrans, nor sanctioned by them.

On overview of the introduction of IPv6 in the Internet / Alain Durand

Alain noted there was a meeting this week that resulted in a new timeframe for the next draft of the document:

Jan 15th: new text from action items
Feb 1st: -06 revision
Feb 1st to Feb-15th: discussion on the mailling list
Feb 15: deadline for new text submission
March 1st : -07 revision
IETF 50, March 28th: presentation to the WG

Upon releasing this next draft, Alain expects to go wg last call.

There were no comments on this.

Hometun / Francis Dupont

See Francis' slides at:

Francis noted that he tried to implement HOMETUN, and had problems with security. Many implementations check ipv4 addresses when they are not supposed to.

IPsec tunnel mode or IPsec transport mode applied to a tunnel have exactly the same layout but different security properties:
- tunnel mode mandates only the check of the inner/IPv6 source address
- transport mode will know and check only the address it knows, the outer/IPv4 address

We want the first (ie. no check of the outer/IPv4 address) but some incorrect (in fact compliant but not interoperable) implementations check both source addresses in tunnel mode.

Other issue noted at the meeting:

Erik Nordmark asked which Francis preferred, tunnel or transport mode; packets look the same. Francis prferred tunnel mode best.

Erik then asked when using IKE to setup, do you say tunnel or transport.
Francis said what is supported by the two peers (ie. common denominator).

Ran Atkinson said that it seems by definition to be tunnel mode, why think it can be either?

Erik note that to get up and running best to use transport mode. Ran objected on grounds of specifying around a bug.

Chair's note: Francis later commented (via email to the chairs) that he has written a draft about IPsec tunnel mode and address-based mobility. This should solve the home tunnel issue and better should give a very nice (one overhead for both security and mobility) mobile secure tunnel framework. Francis will wait for new comments from Richard Draves, his coauthor (as he wants to see IPsec ESP usable with mobility ASAP).

Mime type / Alain Durand

See Alain's slides at:

wants to know if should specify a mime parameter in some specific way.

Introducing Mobile IP in IPv4/IPv6 Interconnected networks / Charles Tsao

See Charle's slides at:

Charles' talk addressed two I-Ds relating to Mobile IPv6: the first (above) addressing a dual-stack model and the second (above) a mobile IP application level gateway. The two drafts which deal with two different problems are independent. The first draft still has some unclear points about whether translators are necessary in some scenarios, but the first draft does not introduce any new security concerns.

The second draft has security problems which should be figured out before consideration as an ngtrans wg item.

The first draft does not extend or modify MobileIP but does give some informative explanation about how IPv4/IPv6 interworking is implemented.

There were questions on why a translator is neeeded as it is dual stack.

Erik Nordmark asked that if translating v4 to v6 was a binding relationship, how was security handled.

Geroge Tsirtsis asked that if Charles had thought about tunnelling?

Tony Hain noted that Charles must solve security before a proposal can be considered as an ngtrans project.

Charles would like to refine the first proposal (which has not new security concerns) and then re-sumbit it to ngtrans for review and possible acceptance as an ngtrans project.

As for the second proposal, Charles will work with George Tsirtsis (who is also interested in this topic) to generate more detail and to solve the security issues.

IPv4 over Mobile IPv6 for Dual Stack nodes / George Tsirtsis

See George's slides at:

From the introduction to this new draft:

Mobile IP is capable of offering mobile services to terminals. Faced with IPv4 address shortage and other shortcomings of Mobile IPv4, a lot of work is now focused on the more functional Mobile IPv6. This, however, creates a number of problems for migration and interoperability, potentially forcing IPv6 Only deployment and consequently, heavy use of either Tunneling or Protocol Translation, e.g., SIIT, NAT-PT.

The Hesham Soliman "Extensions to SIIT and DSTM for enhanced routing of inbound packets" draft combines DSTM and SIIT to allow IPv6 only nodes to communicate with IPv4 only nodes and provides some support for Mobile Nodes in the same domain.

In this document we present mechanisms to be used for support of IPv4 based communication with a dual stack mobile node that only supports Mobile IPv6, rather than both MIPv4 and MIPv6. The aim is to use MIPv6 for mobility services whilst allowing the Mobile node to use its dual stack capabilities for legacy IPv4 communications without requiring translation or MIPv4 deployment.

Alain Durand noted it is not dealing with roaming aspect of moving from v4 to v6, but this is not mentioned.

Tony Hain proposed accepting this as an ngtrans project for Informational RFC. There was no comments against this.

Guidelines for IPv6 local experiments / Itojun

See Itojun's slides at:

Itojun presented the issues surrounding addressing for localized experimental IPv6 networks, coming to the final conclusion that a specially reserved block could be used:

3ffe:0501:ffff::/48 - carved out of WIDE pTLA address

He was not sure if it is the best idea, and was definitely a last resort solution.

There were questions as to whether a document is really needed for this.

Steve Deering thinks we shouldn't be telling folks that this is a problem.

Alain Durand asked why not use site local. Itojun felt that this would be confusing.

Brian Zill commented that site local is etter than some special prefix.

Steve Deering said that this only makes sense if a mulit-location site causes site local issues.

Itojun wants comments from others on this issue. It was agreed that this needed to be discussed on the list, but also noted that there was considerable disagreement with the approach. Itojun will release a draft -02 soon, trying to describe better the problem he sees, and will circulate to the list.

Connecting IPv6 Domains across IPv4 Clouds with BGP / Dirk Ooms

See Dirk's slides at:

From the draft's abstract:

This document specifies a mechanism for IPv6 islands to communicate with each other over an IPv4 core network without explicit tunnel setup, requiring only one IPv4 address (and a derived IPv4-compatible IPv6 address) per IPv6 island or per set of IPv6 islands connected to the same edge router. The hosts in the IPv6 islands can use native IPv6 addresses. The method uses MP-BGP in the edge routers to exchange IPv6 reachability information between the IPv6 islands.

Erik Nordmark asked what are mcast implications for bgp. Dirk said they are not known.

Christian Huitema asked what do you gain over other methods. Dirk replied simplicity.

Brian Zill noted that the advantage over 6to4 was not obvious, so why do it.

Tony Hain said don't worry if it is as good as 6to4, if it solve a problem document it.

Erik Nordmark asked if it useful to connect ISPs over another ISPs vs sites.

Consensus to accept as a project, but Standards Track, Experimental or Informational destination to be determined.

Multicast translator efforts, do we proceed / A. Durand/K. Tsuchiya

As Kazuaki Tsuchiya was not present, the topic was rolled over the next IETF.

v6v4compat / Fred Templin

See Fred's slides at:

Fred presented his -01 version, which was revised from conversations at

Limited automatic tunneling scope to site-level. Reasons:
-unambiguous sending rule: "If destination's 64-bit prefix matches my prefix, tunnel through IPv4. Else, route through IPv6."
-enables operation in Intranets with private address allocations (e.g. When NAT is used)
-complements 6to4; other NGTRANS mech's

Automatic deprecation:
-mechanism "turns itself off" when no longer needed (e.g. when native IPv6 RTAdv's begin)

Simple configuration:
-Need 64-bit prefix and IPv4 address of router for site only
-no prearrangements with "tunnel endpoint" necessary

Steve Deering asked if the first sending rule is necessary, and how does it deal with mcast.

Alain Durand asked if it works with nat. Fred's response to this was that it does work with nat. Alain then further asked how multiple levels of nat within a site were supported. Fred responded that the SLA in the routing prefix is used to assign multiple nat domains.

George Tsirtsis asked where the prefix comes from. Fred respodned that it is statically assigned.

Someone asked how does it deal with multi-link subnet. Fred responded that it doesn'f ro now.

Steve noted that it doesn't need to.

Alain Durand asked what does it solve that 6to4 doesn't. Fred responded that, e.g., no v6 at site.

Erik Nordmark asked if it requires manual config which has the same problems as normal manual tunnels.

George Tsirtsis thought that 6over4 might work bettt. Fred responded that thus requires site mcast infrastructure.

Christian Huitema, emphasizing Erik's point, has to see if it is connectd to v6 router, has to discover v4 address type, have to discover prefix in site but nat might confuse this - main point, this is not very practical.

Steve Deering noted that this is a reasonable thing in some context, that since v4 is being treated as a link layer, the interface identifier seemed like a natural place to embed the v4 address, i.e., that this is yet another way for embedding v4 addresses in v6 addresses. He noted that it is at least another way that we need to explain.

Dave Thaler said that v6-only in the middle can't be solved by 6to4.

Tony Hain asked if there is really interest in this.

Christian Huitema said that it seems 6over4 and this cover similar space, except for mcast need, soo can Fred do automatic discovery.

Brian Zill said he gave up on the NBMAproblem (no mcast) as it is too hard, so agrees further work ok.

Steve Deering wants more work to understand issues with it before discarding. That without knowing eventual outcome, it is worth further discussion even if only to document the issues it addresses.

Discussion of possible new tools/mechanisms to assist transition - Alain Durand

See Alain's slides at:

Alain presented ideas on future ngtrans projects.

Backbone transition scenarios:

How to transition backbones?
How do transitioned backbones interconnect?
Dependencies between site/backbone scenarios

Tunnels & NAT:

All a user has is ONE PRIVATE IPv4 address
How to build the tunnel?
How to reach a 6to4 domain?
-Use a tunnel broker collocated with the 6to4 router?
No IPv6/IPv6 NAT !!!
6to4 reserved address:

Idea: reserved SLA = 0x0000 for well known anycast addresses
Router itself
subnet router anycast address (RFC2373)
Well known address
We can make one with any global IPv4 address
That address is reachable from an IPv6 only node
It could "replace" IPv4 compatible addresses!
IPv4 initiated connection to IPv6

Difficult part of the transition
Solution developed in:
-DSTM, part II
Do we need a more generic solution?

Steve Deering asked if the 2002 anycast was really that, or only used as a source anycast.

Meeting adjourned.


None received.