Subject: (ngtrans) minutes of IETF-49 ngtrans meeting

From: Bob Fink <[email-masked]>
Date: Mon, 15 Jan 2001 11:30:07 -0800

NGtrans folk,

Here are the minutes of the San Diego ngtrans meeting.

Thanks,

Bob

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

=======
Chairs:
Alain Durand <[email-masked]>
Bob Fink <[email-masked]>
Tony Hain <[email-masked]>

This ngtrans meeting reported by Bob Fink.

Attendance was ~200.

Alain Durand chaired the meeting.

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

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

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

======
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
<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
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-socks-gateway-05.txt>
-----------------------------------------------------------------------------

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:
<http://6bone.net/ngtrans/IETF49-SanDiego/Kitamura-socks-gateway.pdf>

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
<http://www.6bone.net/ngtrans/ngtrans_project-status.html>
----------------------------------------------------------

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:
<http://6bone.net/ngtrans/IETF49-SanDiego/Durand-eval-6to4-gway-disc-mech.ppt>

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
<http://www.ietf.org/internet-drafts/draft-huitema-6to4anycast-00.txt>
----------------------------------------------------------------------

See Christian's slides at:
<http://6bone.net/ngtrans/IETF49-SanDiego/Huitema-6to4-anycast.ppt>

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
<http://www.ietf.org/internet-drafts/draft-hain-6to4-scaling-01.txt>
--------------------------------------------------------------------

See Tony's slides at:
<http://6bone.net/ngtrans/IETF49-SanDiego/Hain-6to4-relay-discovery-and-scaling.ppt>

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
<http://www.ietf.org/internet-drafts/draft-durand-ngtrans-tunnel-endpoint-01.txt>
---------------------------------------------------------------------------------

See Alain's slides at:
<http://6bone.net/ngtrans/IETF49-SanDiego/Durand-dnstep.ppt>

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
<http://www.ietf.org/internet-drafts/draft-thaler-ngtrans-6to4-multicast-01.txt>
-------------------------------------------------------------------------------- 

See Dave's slides at:
<http://6bone.net/ngtrans/IETF49-SanDiego/Thaler-m6to4.ppt>

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
<http://www.ietf.org/internet-drafts/draft-moore-6to4-dns-01.txt>
-----------------------------------------------------------------

See Keith's slides at:
<http://6bone.net/ngtrans/IETF49-SanDiego/Moore-6to4dns.ppt>

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
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-dstm-03.txt>
--------------------------------------------------------------------

See Jim's slides at:

<http://6bone.net/ngtrans/IETF49-SanDiego/Bound-dstm.ppt>

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
<http://www.ietf.org/internet-drafts/draft-tsirtsis-6to4-and-dstm-01.txt>
-------------------------------------------------------------------------

See George's slides at:
<http://6bone.net/ngtrans/IETF49-SanDiego/Tsirtsis-dstm-6to4.ppt>

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
<http://www.ietf.org/internet-drafts/draft-soliman-siit-dstm-01.txt>
---------------------------------------------------------------------

See Hesham's slides at:
<http://6bone.net/ngtrans/IETF49-SanDiego/Soliman-siit-dstm-routing.ppt>

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
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-introduction-to-ipv6-transition-05.txt>
-----------------------------------------------------------------------------------------------

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
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-hometun-01.txt>
-----------------------------------------------------------------------

See Francis' slides at:
<http://6bone.net/ngtrans/IETF49-SanDiego/Dupont-hometun.ppt>

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
<http://www.ietf.org/internet-drafts/draft-durand-ngtrans-tunnel-mime-type-01.txt>
----------------------------------------------------------------------------------

See Alain's slides at:
<http://6bone.net/ngtrans/IETF49-SanDiego/Durand-mime-type.ppt>

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
<http://www.ietf.org/internet-drafts/draft-tsao-mobileip-dualstack-model-01.txt>
<http://www.ietf.org/internet-drafts/draft-tsao-mobileip-00.txt>
--------------------------------------------------------------------------------

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
<http://www.ietf.org/internet-drafts/draft-tsirtsis-v4-over-mipv6-00.txt>
-------------------------------------------------------------------------

See George's slides at:
<http://6bone.net/ngtrans/IETF49-SanDiego/Tsirtsis-mipv6-dstm.ppt>

 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
<http://www.ietf.org/internet-drafts/draft-itojun-ipv6-local-experiment-01.txt>
-------------------------------------------------------------------------------

See Itojun's slides at:
<http://6bone.net/ngtrans/IETF49-SanDiego/Itojun-xpmt-guidelines.ppt>

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
<http://www.ietf.org/internet-drafts/draft-nguyen-ngtrans-bgp-tunnel-00.txt>
----------------------------------------------------------------------------

See Dirk's slides at:
<http://6bone.net/ngtrans/IETF49-SanDiego/Ooms-bgp-tunnel.ppt>

 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
<http://www.ietf.org/internet-drafts/draft-tsuchiya-mtp-00.txt>
----------------------------------------------------------------------

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

=============================================================================
v6v4compat / Fred Templin
<http://www.ietf.org/internet-drafts/draft-templin-ngtrans-v6v4compat-01.txt>
-----------------------------------------------------------------------------

See Fred's slides at:
<http://6bone.net/ngtrans/IETF49-SanDiego/Templin-ipv6-ipv4-comp-addr.ppt>

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:
<http://6bone.net/ngtrans/IETF49-SanDiego/Durand-NGtrans-future.ppt>

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.
==================
-end