============================= Minutes of NGtrans WG Meeting 11 & 14 December 2000 San Diego IETF-49 ======= Chairs: Alain Durand Bob Fink Tony Hain This ngtrans meeting reported by Bob Fink. Attendance was ~200. Alain Durand chaired the meeting. =========================== Administrative information: Discussion ngtrans: Subscribe ngtrans: "subscribe ngtrans" Archive ngtrans: Web site: Discussion 6bone: Subscribe 6bone: "subscribe 6bone" Archive 6bone: Web site: ====== Agenda ====================== 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 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 Issues 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: MOVE TO NGTRANS I-D 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: http://6bone.net/ngtrans/IETF49-SanDiego/Tsao-mobileip.ppt> 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 IETF-48: 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? -IPv6/UDP/IPv4? -Other? How to reach a 6to4 domain? -Use a tunnel broker collocated with the 6to4 router? -Other? No IPv6/IPv6 NAT !!! --- 6to4 reserved address: Idea: reserved SLA = 0x0000 for well known anycast addresses Router itself -2002:xxxx:xxxx:0000::0 subnet router anycast address (RFC2373) -2002:xxxx:xxxx:0000::1 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 -NAT-PT 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. ==================