(ngtrans) draft ngtrans minutes from IETF-50

[Bob Fink <[e-mail]>]

ngtrans folk,

I'm releasing an early draft of the minutes before all the slide info is 
included.

So, please send your ppt to me if you haven't already. Also, please send 
comments on the minutes to me so I can correct and include for the final 
version.


Thanks,

Bob

-----------------------------
Minutes of NGtrans WG Meeting
19 & 22 March 2001
Minneapolis IETF-50

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

This ngtrans meeting reported by Bob Fink.

Attendance was over 300.

Alain Durand chaired the meeting.

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

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

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

======
Agenda

======================
Monday meeting agenda:
----------------------
Agenda Bashing
NGtrans Project status - Bob Fink
Status of 6to4-Anycast processing - Tony Hain
6to4 scaling issues - Tony Hain
Status of IPv6 DNS Operational Needs sub-wg - Alain Durand
DSTM Update - Jim Bound
Using a Single IPv4 Global Address in DSTM - Myung-Ki Shin
Dual Stack Hosts using "Bump-in-the-API" - Seungyun Lee
IPv6 SMTP operational requirements - Itojun
Connecting IPv6 Nodes within IPv4 Sites - Fred Templin

========================
Thursday meeting agenda:
------------------------

Short term NAT requirements for IPv6 transition - Christian Huitema
MIME TYPE Definition for Tunnels (MIMETYPE) - Alain Durand
Integration of three drafts on IPv6 Mobility for a dual-stack model- Tsao & 
Tsirtsis
Viagenie web I/f to 6bone registry - Florent Parent
An IPv6/IPv4 Multicast Translator based on IGMP/MLD Proxying -   Kazuaki 
Tsuchiya
6to4 Well Known Address & 6to4-DSTM - Alain Durand
<draft-durand-ngtrans-6to4-well-known-address-00.txt>
A Guide to the Introduction of IPv6 in the IPv4 World  - Alain Durand
Connecting IPv6 Domains across IPv4 Clouds with BGP - Dirk Ooms
Transitioning DNS from AAAA to A6 - Rob Austein
Transition mechanism interactions - Alain Baudot
6to4-DNS & 6overNAT issues - Keith Moore

===============
Monday meeting:

=============================================================================
NGtrans Project status - Bob Fink
-----------------------------------------------------------------------------

Bob Fink gave a brief status report of ngtrans projects. Project status is 
always available at:

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

Bob's slides are available at:

<http://6bone.net/ngtrans/IETF-50-Minneapolis/Fink-status.ppt>


===========================================================
Status of 6to4-Anycast processing - Tony Hain
-----------------------------------------------------------

Tony Hain reported that during IESG review of 6to4-anycast there were 
comments fom both the IESG and IANA. They dealt with two basic issues. One, 
cleaning up the text and request for an anycast prefix so it did not 
specify the prefix length and stated what the need was. Two, whether a 
unique ASN was needed.

These issues are currently being addressed by the author, Tony Hain and 
Randy Bush.

===========================================================
6to4 scaling issues - Tony Hain
-----------------------------------------------------------

Tony Hain asked if there was interest in the working group in making the 
draft, available at:

<draft-hain-6to4-scaling-01.txt>

into an ngtrans project. The only response came from Brian Carpenter who 
felt strongly the work was valuable and should continue.

Tony said that he will review the draft to see if it can be kept as 
informational only by stripping out any specific standards type content, 
and report to the list what he will do with the draft.

===========================================================
Status of IPv6 DNS Operational Needs sub-wg - Alain Durand
-----------------------------------------------------------

Alain Durand reported on the status of the IPv6 DNS Operational Needs 
sub-wg, the new work item created at the last ngtrans meeting by Randy Bush 
to address the DNSOPS request to understand DNS transition requirements. 
Basically, there is a need to make the root able to support IPv6-access to 
the DNS to begin the transition of IPv6. Alain will release a draft report 
of the sub-wg in a few weeks.

Alain subsequently presented at DNSOPS and worked out an enhancement of his 
conclusion with Randy Bush, which was then presented at DNSEXT and at the 
Thursday ngtrans session. The slides included here are the updated ones. 
Alain's slides are available at:

<http://6bone.net/ngtrans/IETF-50-Minneapolis/Durand-dns-needs.ppt>

===========================================================
DSTM Update - Jim Bound
-----------------------------------------------------------

Jim Bound gave a DSTM update. The current draft is available at:

<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-dstm-04.txt>

Jim's slides are available at:

<http://6bone.net/ngtrans/IETF-50-Minneapolis/Bound-dstm-04.pdf>

Jim still does not want to go to wg last call until dhcpv6 is released for 
its wg last call.

Alain Durand asked if Shin's work be included in dstm base spec. Jim said 
it was good work, but that he would have to review this.

===========================================================
Using a Single IPv4 Global Address in DSTM - Myung-Ki Shin
-----------------------------------------------------------

Myung-Ki Shin presented Using a Single IPv4 Global Address in DSTM, which 
is available at:

<http://www.ietf.org/internet-drafts/draft-shin-dstm-single-ipv4-00.txt>

Myung-Ki's slides are available at:

<http://6bone.net/ngtrans/IETF-50-Minneapolis/Shin-single-ipv4.ppt>

The motivation of this works is:

In order to allow a dual stack host to get an IPv4 global address,  DHCPv6 
is used. If the dual stack hosts which want to get IPv4 addresses increase 
at a time, a lot of IPv4 global address will be needed. When the pool of 
IPv4 addresses is exhausted, newer dual stack hosts cannot establish 
sessions with the outside IPv4 anymore. To increase the efficiency of using 
IPv4 addresses, it is proposed to add a new DHCPv6 option which provides a 
method to assign a single IPv4 global address with TCP/UDP port range to 
all dual stack hosts in a DSTM domain.

Requirements are:

DHCP Server - When a DHCPv6 Server receives an IPv4 Global Address with 
Port Range Option in a DHCPv6 Request message, the server MUST allocate the 
range of port as well as an IPv4 address.

DHCP Client - When the Server supplies an IPv4 Global Address with Port 
Range in the Reply, the Client MUST assign the port range to an interface 
as well as the address.

Border Router - In addition to the address association between IPv4 and 
IPv6, a border router MUST keep the port state.

In summary:

Add new DHCPv6 options to support a Single IPv4 Global Address with Port 
Range. This will allow for a maximum of 63K TCP and 63K UDP sessions. This 
proposed mechanism increases the utilization of IPv4 address when the pool 
of IPv4 addresses assigned in DHCPv6 for the purposes of dynamic allocation 
is exhausted.

Limitations are:

Client applications that do not insist on choosing their own source port.
Inbound traffic (from IPv4 only hosts outside the IPv6 domain) is 
restricted to one server per service.


Myung-Ki then asked if this should become an ngtrans project, and what 
relationship it might have w/DSTM.

Steve Deering noted that this approach was limited to only tcp and udp 
apps, many others exist and won't work.

Erik Nordmark asked how does dhcp server know how many ports to give 
client? Myung-Ki replied that it depends on dhcp server policy.

Jim Bound stated that he likes this idea, but there are technical questions 
to resolve offline, and that it probably should not be put in dstm.

===========================================================
Dual Stack Hosts using "Bump-in-the-API" (BIA) - Yong-Jin Kim
-----------------------------------------------------------

Yong-Jin Kim presented Dual Stack Hosts using "Bump-in-the-API", which is 
available at:

<http://www.ietf.org/internet-drafts/draft-sylee-bia-00.txt>

Yong-Jin's slides are available at:

<http://6bone.net/ngtrans/IETF-50-Minneapolis/Kim-BIA.ppt>

The basic concept was introduced at 45th IETF meeting (Oslo) by Erik 
Nordmark. It allows some unmodified socket apps to work without 
recompiling, and thus allows the dual stack hosts to communicate with other 
IPv6 hosts using existing IPv4 applications. The goal is the same as BIS 
(RFC 2767).

Socket API conversion

IPv4 socket API functions are translated into semantically the same IPv6 
socket API functions and vice versa.
ICMP translation : it is possible to handle by intercepting the ICMP 
message using SOCK_RAW.

Internally assigned IPv4 addresses

The address spool consists of the unassigned IPv4 addresses (e.g., 0.0.0.0 
~ 0.0.0.255).
No potential collision with another use of the private address space

Implementation Specifics

How to intercept socket API functions?
Dynamic linkable libraries
Support the PRELOAD library functions (UNIX System V, e.g., Solaris, Linux, 
etc)
Support the User-Defined layered protocol (SPI from Windows 2000)

Limitations

does not support the IPv4 packets with option fields and IPv6 packets with 
option headers.
does not support the multicast functions.

ETRI Implementation

Platform: Windows 2000 with Microsoft IPv6 Technology Preview
The API translator was implemented by the SPI (Service Provider Interface)
which allows user to make user-defined layered protocol as a dynamic link 
library.
Experimental Results:
Currently it works well with Internet Explorer for IPv4.
URL : <http://www.krv6.net/bia/> (will be available on April 2001)


Brian Carpenter asked if Yong-Jin thinks the set of problems are different 
than the nat approach.

Erik Nordmark noted that the only place where this is better than nat is 
ipsec, and that he implemented it several years ago and there is a set of 
problems associated with design choices on multi-user systems, e.g., how 
many private ipv4 number spaces, is it done in user or system space...

Brian Carpenter asked how big the code is and if it is open source. 
Yong-Jin replied about 3000 lines of code, and that it is not yet open source.

Erik Nordmark noted that he didn't pursue a BIA draft as he wanted app 
writers to convert to the ipv6 api, and as BIA could fool people into 
thinking it might not be necessary, so he decided not to document it. The 
real message should be if you can't convert code (no source) then this may 
be ok, but all others should convert code, not use BIA.

Itojun agreed with Erik's point on message it gives to apps writers.

Alain Durand noted that the problem is that it is known to exist, and thus 
should be documented with appropriate disclaimers.

Jim Bound commented that if you do this, you are stuck with it forever.

Steve Deering made the meta comment that different platforms and different 
transition solutions, means diagnosing what is happening. That he is really 
concerned and wants to publish this with a "don't do this" disclaimer.

Alain noted that there is a new draft discussing interactions between 
transition mechanisms.

Consensus was to publish as a possible approach.

Christian Huitema commented that he thinks Steve is right, publish it as a 
don't do, but if we do too many info rfcs, an implementor may have to 
support this stuff forever.

Jim Bound wanted to publish it as something to be done when an app source 
code is unavailable, that it is a useful tool.

Erik Nordmark wanted to put a stong applicability statement in it.

It was agreed to accept BIA as a wg project, but have it include disclaimers.

===========================================================
IPv6 SMTP operational requirements - Itojun
-----------------------------------------------------------

Itojun presented IPv6 SMTP operational requirements, recently accepted as 
an ngtrans project, which is available at:

<http://www.ietf.org/internet-drafts/draft-motonori-ipv6-smtp-requirement-00.txt> 


Itojun's slides are available at:

<http://6bone.net/ngtrans/IETF-50-Minneapolis/Itojun-ipv6-smtp.htm>

This draft give operational requirements for IPv6 SMTP, and IPv6 DNS MX 
records. The goal being a stable IPv6 email transport. Similar content was 
presented by Kazu, at a previous IETF, but not documented at that time.

Brian Carpenter noted that some types of numeric addressses could be a 
problem, but can't exclude them as you might want to send email when dns is 
down. He asked if local and site scope should be documented as meaningless.

Erik Nordmark asked if Itojun had looked for similarity in his approach to 
existing implementations. Itojun responded yes.

===========================================================
Connecting IPv6 Nodes within IPv4 Sites - Fred Templin
-----------------------------------------------------------

Fred Templin presented Connecting IPv6 Nodes within IPv4 Sites, which will 
soon be available at:

<http://www.ietf.org/internet-drafts/draft-templin-ngtrans-v6v4compat-02.txt>

Fred's slides are available at:

<http://6bone.net/ngtrans/IETF-50-Minneapolis/Templin-v6v4compat.ppt>

Fred noted that there had been a change in title and in the sending rule 
since the last draft.

 From the Abstract of the draft:

    This document specifies a method for connecting IPv6 hosts and
    routers (nodes) within predominantly IPv4-based sites. This method is
    based on an IPv6-IPv4 compatibility aggregatable global unicast
    address format (described herein) that embeds the IPv4 address of a
    node within the EUI-64 format interface identifier of an IPv6
    address. This document assumes that, during the IPv4 to IPv6 co-
    existence and transition phase, many sites will deploy IPv6
    incrementally within their IPv4 interior routing domains; especially
    those sites which have large and complex pre-existing IPv4
    infrastructures. Within such sites, the address format and methods
    described in this document will enable IPv6 deployment for nodes that
    do not share a common multiple access datalink with an IPv6 gateway
    within their site.

    While other works in progress in the NGTRANS working group propose
    mechanisms for assigning globally-unique IPv6 address prefixes to
    sites and methods for inter-domain routing between such sites, the
    approach outlined in this memo enables large-scale incremental
    deployment of IPv6 for nodes within a site's pre-existing IPv4
    infrastructure without incurring aggregation scaling issues at the
    border gateways nor requiring site-wide deployment of special IPv4
    services such as multicast. The approach proposed by this document
    supports IPv6 routing within both the site-local and global IPv6
    routing domains as well as automatic IPv6 in IPv4 tunneling across
    portions of a site's IPv4 infrastructure which have no native IPv6
    support. Moreover, this approach supports automatic tunneling within
    sites which use non globally-unique IPv4 address assignments, such as
    when Network Address Translation [NAT] is used.

Steve Deering asked if, when there are lots of hosts, and the router is 
down, will there be a storm of state creation? Fred felt that it would only 
be router solicitations.

Steve Deering noted that if a site doesn't do this, but if you don't hear a 
router advert from a neighbor, and then  you start doing this it could be a 
problem. Fred replied that possible it could be handled by a counter of 
some sort.

Steve noted that this draft was modeling v4 site topology as nbma, as 
opposed to what 6over4 assumes, i.e., site-wide multicast.

Rich Draves stated there is danger discovery might extend beyond site 
boudary. Fred noted that borders might need to filter to handle this.

Rich noted that when he implemented this, normal routing code had no need 
of specific sending rules.

Steve thinks it is too complex.

Margaret Wasserman asked if the  ipv4-address need be globally unique?

Jim Bound stated that he thinks this should be a project.

Dave Thaler thinks it could be useful, wants a good name for it other than 
"templin" addressing.

Tony Hain noted he had no problem with this draft being a wg project, but 
there were scaling and leaking issues that need to be addressed. He felt 
that it should be an experimental draft.

Steve Deering asked if Fred had thought about mcast. Fred replied that he 
had not gotten to it.

Steve noted that he was torn over this. He felt that it is useful to 
document, but if we do this, should deprecate 6over4. He would like ngtrans 
to make a choice between the two.

Christian Huuitema commented that this does solve a problem for sites that 
can't support native v6 or mcast.

Jim Bound thought that 6over4 was an orthogonal issue. if we supercede 
something, fine, but don't prejudge what a user can absorb. Different users 
want, and have, different problem solutions.  This is a good draft, thus 
allow it.

Brian Carpenter agreed with Jim. However, he noted that more solutions add 
stack complexity. He also noted that the new draft on transition mechanism 
interactions is very important given the number of mechanisms ngtrans now has.

Randy Bush commented that the Internet puts the smarts at the edge and dumb 
in center. That this draft puts load on router, not on edge. Fredeplied 
that he had tabled router interception, as it's not a good way to go. Randy 
replied that this was good, don't put complexity in router.

Alain Durand asked if this should become a wg project. Consensus to do so. 
It will be decided later what track, and what the name should be changed to.

==================
Meeting adjourned
for Wednesday
==================

==================
Thursday meeting

===========================================================
Short term NAT requirements for IPv6 transition - Christian Huitema
-----------------------------------------------------------

Christian Huitema presented Short term NAT requirements for IPv6 
transition, which is available at:

<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-natreq4ipv6-00.txt>

Christian's slides are avaialble at:

<http://6bone.net/ngtrans/IETF-50-Minneapolis/Huitema-NAT-6to4.ppt>

 From the draft Abstract:

During the next few years, as the Ipv4 address space moves toward
exhaustion, it is likely that the deployment of NAT will accelerate.
By 2005, millions of NAT devices will likely be deployed on the
Internet, both within enterprises and consumer households. Should
those NAT devices not support either native Ipv6, or IPv6 transition
mechanisms such as 6 to 4, the result would be significant delays in
the deployment of IPv6.

This draft presents the requirements that NAT devices must meet in
order to enable a future transition to IPv6. Rather than specifying
every aspect of a NAT's operation in detail, our focus is solely on
identifying those requirements that are absolutely essential to
ensure compatibility with what we believe will be the most popular
IPv6 transition mechanisms.
---

Alain Durand asked what happens when there are multiple layer of NATS. 
Christian said that it doesn't work.

Keith Moore said he liked the idea.  One issue is if the NAT receives 
packet of type 41, translates address, relays to internal host, that it 
won't work for large environments. Christian said that's ok.

Keith noted that this should also sell this as less growth in ALGs.

Question from the floor: can this be applied to configured tunnel, and if 
so please change the draft to reflect this? Christian responded yes to 
this, and he will change the draft.

===========================================================
MIME TYPE Definition for Tunnels - Alain Durand
-----------------------------------------------------------

Alain presented the newest draft of MIME TYPE Definition for Tunnels, which 
is available at:

<http://www.ietf.org/internet-drafts/draft-durand-ngtrans-tunnel-mime-type-02.txt>

He noted that there is a new co-author, a new draft, and new syntax of mime 
type. It is now easier to parse.

ALain also noted that he will respond to the need for an example with a new 
draft, then last call it.

===========================================================
Integration of three drafts on IPv6 Mobility for a dual-stack model- Tsao & 
Tsirtsis
-----------------------------------------------------------

Charles Tsao and George Tsirtsis presented the integration of three drafts 
on IPv6 Mobility for a dual-stack model into one draft. This takes Charles' 
two personal drafts (1. and 2. below) and merges them into the existing 
ngtrans draft v4-over-mipv6 (3. below).

1. Mobility Support for IPv4 and IPv6 Interconnected Networks based on 
Dual-Stack Model
<http://www.ietf.org/internet-drafts/draft-tsao-mobileip-dualstack-model-02.txt>

2. Routing Optimization for Mobile IPv4/Mobile IPv6 Interworking
<http://www.ietf.org/internet-drafts/draft-tsao-mobileip-00.txt>

3. IPv4 over Mobile IPv6 for Dual Stack nodes
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-v4-over-mipv6-00.txt>

The slides of this presentation are available at:

<xxxxxxxxxxxx>

Jim Bound said that this was good work and it should proceed.

Alain asked, and received consensus, that this integration should proceed. 
A new draft will follow.

===========================================================
Viagenie web I/f to 6bone registry - Florent Parent, 10 mins
-----------------------------------------------------------

Florent Parent presented the Viagenie web I/f to the 6bone registry, a now 
well developed wbe-based interface to the production 6bone registry that 
allows an easier way to add, delete and change entries in the registry. 
This tool can be seen at:

<http://www.viagenie.qc.ca/en/ipv6/registry/index.shtml>

Florent's slides are available at:

<xxxxxxxxx>

===========================================================
An IPv6/IPv4 Multicast Translator based on IGMP/MLD Proxying - Kazuaki Tsuchiya
-----------------------------------------------------------

Kazuaki Tsuchiya presented An IPv6/IPv4 Multicast Translator based on 
IGMP/MLD Proxying (MTP), available at:

<http://www.ietf.org/internet-drafts/draft-tsuchiya-mtp-00.txt>

Kasuaki's slides are available at:

<http://6bone.net/ngtrans/IETF-50-Minneapolis/Tsuchiya-mtp.ppt>

This new draft attempts to answer concerns, from a previous MTP 
presentation in Pittsburgh, that the solution would not scale.

Dave Thaler thought this is possibly a good idea, and alright to be at 
ngtrans. He was not sure specific mechanisms are correct. He thought the 
proxy approach ok, but authentication stuff may not be ok unless way to 
know address.

Jim Bound asked if BIS part of this? Kazuaki replied no it is not.

Alain asked if this ok to be an ngtrans item, and then to take to the list 
for further discussion. There was no objection. MTP will become an ngtrans 
project.

===========================================================
6to4 Well Known Address & 6to4-DSTM - Alain Durand
-----------------------------------------------------------

Alain Durand presented his new draft 6to4 Well Known Address, available at:

<http://www.ietf.org/internet-drafts/draft-durand-ngtrans-6to4-well-known-address-00.txt>

and how George Tsirtsis would use the idea in the 6to4-DSTM draft, 
available at:

<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-6to4-dstm-00.txt>

Their slides are available at:

<http://6bone.net/ngtrans/IETF-50-Minneapolis/Durand-6to4-well-known-address.ppt> 
and

<xxxxxxxxxxxxxxxxx>

This proposes using SLAid-0 as an 6to4router subnet.

SLAid = 0x0000 MUST be reserved as a virtual subnet for all 6to4 routers 
within a 6to4 domain.

EUI64 = 0000:0000:0000:0000 - all 6to4 routers ANYCAST address.

EUI64 = 0000:0000:0000:0001 - designated 6to4 router UNICAST address.


Erik Nordmark asked what these addresses will be used for.

Matt Crawford noted that when there are multiple prefixes for a site and 
the site wants to keep the subnet (SLA id's) the same, this approach would 
preclude that (at least for SLA id = 0).

Dave Thaler stated that we assume only one exit router has a prefix, but 
each could have a separate prefix. So why do we need this.

Geroge then presented the need.

Dave commented that he still doesn't understand why.

Erik noted that higher robustness is why multiple gateways, but does it 
work if a gateway goes down.

Dave said scenario not needed, but Alain thinks then 6to4 shuld say only 
one exit router.

This discussion will be taken to the list.

===========================================================
A Guide to the Introduction of IPv6 in the IPv4 World - Alain Durand
-----------------------------------------------------------

Alain Durand gave the status of the current version of A Guide to the 
Introduction of IPv6 in the IPv4 World, available at:

<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-introduction-to-ipv6-transition-06.txt>

A few more small changes are coming, but it is getting close to done. Still 
need to verify scope descriptions for each mechanism. Alain expects to go 
to last call in May.

===========================================================
Connecting IPv6 Domains across IPv4 Clouds with BGP - Dirk Ooms
-----------------------------------------------------------

Dirk Oom presneted Connecting IPv6 Domains across IPv4 Clouds with BGP, 
available at:

<http://www.ietf.org/internet-drafts/draft-nguyen-ngtrans-bgp-tunnel-00.txt>

Dirk's slides are available at:

<http://6bone.net/ngtrans/IETF-50-Minneapolis/Ooms-bgp-tunnel.ppt>

Dirk asked if anything missing, and what next.

Dave Thaler asked if the wording can be changed so it doesn't have to be 
v4compatable address, but any type. Dirk will do this.

===========================================================
Transitioning DNS from AAAA to A6 - Rob Austein
-----------------------------------------------------------

Rob Austein presented Transitioning DNS from AAAA to A6. His slides are 
reproduced in entirety below.

He had given this same presentation in DNSEXT the day before.

---
The problems

	We have two complete IPv6 DNS solutions
		One is standard, the other is deprecated
		Known implementations use the deprecated one
		This is becoming a real issue for IPv6 deployment

	Much concern about complexity of newer stuff and whether we really need it

	Some of the new stuff requires extensive infrastructure upgrades

	Strong case for the advanced features of the new stuff has not been made

---
Overview of proposed approach for A6

	Write AAAA -> A6 transition spec
		Almost certainly requires protocol fiddling, hence DNSEXT work
		Almost certainly will require updating or augmenting A6 spec

	Write "Case For A6" or admit that we can't make one
		Recruiting security folks to help with time-to-resign issues
		Need to identify and address any other issues

	Goal is to have both docs ready by IETF 51 in London
		Yes, this is aggressive

---
Why A6 is worth talking about

	A6 does provide features that AAAA can not provide

	"Degenerate" case of A6 semantically identical to AAAA

	We do not yet know whether we need A6's extra features and may not until 
it's too late

	Paranoia therefore suggests that:
		We should deploy A6 in case we need it
		We should only use it in the degenerate case for now

	None of the above to be construed as lessening our need for a "Case For 
A6" doc

---
Overview of A6 transition plan

	NB: This is still wet, and smells faintly of beer

	"Real" data will be A6, degenerate case only for now

	Stub clients wanting AAAA to be supported by synthesis from A6 data
		Synthesis to be performed by entity providing recursive service
		Synthesized data probably will not be signed

	If a query does not contain EDNS indicator, additional section IPv6 
addresses to be AAAA

	Root and TLD zones contain only (degenerate) A6, not AAAA

---
Binary labels

	Proposal: punt 'em

	Binary labels do not provide any features that can't be provided by "nibbles"

	Both are ugly.  Both need better user interfaces.

	Binary labels are painful to deploy, because of the new label type

	DNAME can ease some of the pain of the "nibble" solution

---
DNAME

	Very dangerous, but also potentially useful

	DNAME does provide new functionality that it would be difficult to provide 
any other way
		Not quite impossible (forests of CNAMEs), just prohibitively painful

	Deployment problem not as bad as binary labels

	Can make "nibble mode" reverse tree less painful

	Recommendation: keep DNAME, but discourage gratuitous use
		Easy to say, much harder to do
---

Itojun asked where is the appropriate place to discuss this, Rob replied 
dnsext.

Rob noted that after evaluation, transition will be uglier than just 
deploying A6, but case for A6 needed anyway.

Keith Moore commented that there is reason to fear not depolying A6 as 
well. That we need a real comparison of doing or not doing A6. Rob said 
that he agreed in theory, but implementing the A6 degenerate feature like 
aaaa is the same.

Keith said that if this A6 degenerate feature is to be put in in case of 
future use, it needs interoperability deployment testing.

Brian Zill asked how this was received in dnsext. Rob deferred to Olafur 
Gudmundsson (co-chair of DNSEXT)

Olafur commented that this is a hi-priority item for DNSEXT, that arose as 
we want to deploy v6 now and converting in future will be difficult. He is 
working with DNS vendors to look at doing A6 degenerate hack.

Christian Huitmena commented that going for short term approach is fine, 
but is a bit of a contradiction.

Keith said it would make a more complelling case if there is sensible case 
for renumbering, which we don't have yet.

Randy Bush (co-chair of DNSEXT and ngtrans AD)commented that until v6 folk 
do plan well for renumbering, you can't expect DNS to cope with it if not 
defined. DNS groups are trying to do the right thing with A6 and it is a 
productive process. Join them.

===========================================================
Transition mechanism interactions - Alain Baudot
-----------------------------------------------------------

Alain Baudot presented Transition mechanism interactions, available at:

<http://search.ietf.org/internet-drafts/draft-krampell-v6transition-interaction-00.txt>

Alain's slides are available at:

<http://6bone.net/ngtrans/IETF-50-Minneapolis/Baudot-transition-interaction.ppt>

Only deals with two mechanism interactions.

Alain Durand said good work, and made several comments:

1)  I agree with the first goal: study the effects of combining 2 mechanisms.
      This is something that is very useful for the wg.
      However, I disagree with the 2nd goal "recommending which mechanism 
to use".
      Those are two different and probably conflicting goals.

2) There are several errors in the analysis. Example the draft says:
     DSTM and 6to4 can not be combined. This is not true, we had
     a presentation on this topic earlier

3) The matrix is big, too big. I suggest to split it into smaller matrixes,
     using the scope of each mechanism as described in
     introduction to-transition-06

4) This will help to isolate the pathological cases that we should
      recommend not to use, examples:
	- IPv6 - NAT/PT - IPv4 - NAT-PT - IPv6
	- DSTM over 6over4
	- 6over4 over DSTM

Jim Bound stated that usefullness statements need to come from customers 
not engineers. Thus state it is a limited study.

Brian Carpenter agreed with what Jim said. Doing it as a BCP isn't possible 
now. There are missing items: doesn't have a basic dual stack host mech. 
listed, BIA, Templin. Alain Baudot agreed.

Keith Moore stated that this is good work to be done. It is valuable if 
work does expose undesirable interactions. The group does need to evaluate 
conflicts that are possible. More than pair-wise are possible.

Erik Nordmark stated that this is good work. It shouldn't make new mech. 
describe interactions with old. Yes, people developing new mech. should 
evaluate, but don't make them decribe it.

Jim Bound noted that SIIT needs to be there as well.

Alain Durand said that Alain Baudot (and other authors) should incorporate 
comments, publish a new draft, then ngtrans will decide what to do with it 
next.

===========================================================
6to4-DNS and 6overNAT - Keith Moore
-----------------------------------------------------------

Keith Moore asked to give status of 6to4-DNS. The last feedback was that it 
was not possible to insist be in client libs., so the current draft 
comments on this. DNS group should look at DNS-related issues of this 
draft. No disagreement on this.

Keith also asked folks to read 6overNAT and bring up issues and comments by 
email or to see him offline.

==================
Meeting adjourned.
==================
-end