(ngtrans) NGtrans rough 1st draft minutes, IETF-51, London

[Bob Fink <[e-mail]>]

NGtrans folk,

Here are the rough 1st draft minutes for the ngtrans meeting in London this 
week. I am still missing presentation slides from Jeremy De Clercq on his 
BGP Tunnel presentation.

Please send corrections/comments/additions to me directly ([e-mail]).


Thanks,

Bob

===
Minutes of NGtrans WG Meeting
7 August 2001
London IETF-51

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

Tony Hain chaired the meeting.

Bob Fink took the minutes.

Attendance was over 200.


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

---
Agenda bashing

NGtrans Project Status - Fink, 5 mins

DNS OPS Requirements - Alain Durand, 10-20 mins
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-dns-ops-req-01.txt>

Bump In the API (BIA) - Myung-Ki Shin, 10 mins
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-bia-00.txt>

ISATAP Issues - Fred Templin, 5-10 mins
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-isatap-01.txt>

ISATAP Router Discovery - Dave Thaler, 10-15 mins
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-isatap-01.txt>

NAT traversal discussion - Durand/Huitema, 10 mins
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-natreq4ipv6-00.txt>
<http://www.ietf.org/internet-drafts/draft-huitema-shipworm-00.txt>

Denial of Service by 6to4 anonymisation - Alain Durand, 5-10 mins

Moving MECH (RFC2893) forward to DS discussion - Erik/Alain, 10-20 mins
<http://www.ietf.org/rfc/rfc2893.txt>

DSTM & friends update - Jim Bound, 5-10 mins
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-dstm-04.txt>
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-dstmext1-aiih-00.txt>
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-6to4-dstm-00.txt>
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-siit-dstm-00.txt>
<http://www.ietf.org/internet-drafts/draft-shin-dstm-single-ipv4-00.txt>

BGP Tunnel remaining issue discussion - Jeremy De Clercq, 5-10 mins
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-isatap-01.txt>
Tunnel Servers/Brokers - Marc Blanchet, 5-10 mins
<http://www.ietf.org/internet-drafts/draft-vg-ngtrans-tsp-00.txt>

MIME-TYPE - Alain, Durand, 3-5 mins
<http://www.ietf.org/internet-drafts/draft-durand-ngtrans-tunnel-mime-type-02.txt>

Example Addressing draft - Marc Blanchet, 3-5 mins
<http://www.ietf.org/internet-drafts/draft-blanchet-ngtrans-exampleaddr-01.txt>

IPv6-SMTP-REQUIREMENTS - Itojun, 3-5 mins
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-ipv6-smtp-requirement-02.txt>

An IPv6/IPv4 Multicast Translator based on IGMP/MLD Proxying (MTP) - 
Kazuaki Tsuchiya, 5 mins
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-mtp-00.txt>

Connecting IPV6 islands within a same IPV4 AS - Damien Galand, 5 mins
<http://search.ietf.org/internet-drafts/draft-many-ngtrans-connect-ipv6-igp-00.txt>

=================================
NGtrans Project Status - Bob Fink

SLIDES:
<http://www.6bone.net/ngtrans/IETF-51-London/ngtrans-status.ppt>

Bob presented the current status of NGtrans projects (see slides above). 
For current status of projects, look at:

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

===
DNS OPS Requirements - Alain Durand
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-dns-ops-req-01.txt>

SLIDES:
<http://www.6bone.net/ngtrans/IETF-51-London/DNS-OPS-REQ.ppt>

Alain noted that a -02 version will be released soon.

Given a requirement for transparent DNS lookups regardless of IP version, 
there is a need for some sort of bridging solution.

Why is bridging important? While processing the NS chain, a resolver will 
follow a chain of referrals. In that chain, it may happen that one of them 
is not directly reachable with the resolver IP stack.

IPv4 bridging vs IPv6 bridging
•	Both are necessary
•	Although desirable, both solutions do not need to be the same.
•	Constraints are different

Bridging IPv6 only resolver to IPv4 only server
• Constraints due to installed base
   ­ Can  modify IPv6 resolver code
   ­ Can modify IPv6 resolver configuration
• Fall back, last resort forwarder
   ­ "Forward Last"
   ­ Recursive
• DNS lookup proxy
   ­ Non recursive

Bridging IPv4 only resolver to IPv6 only server
• Constraints due to installed base
   ­ Can not change IPv4 resolver code
   ­ Can not change IPv4 resolver configuration
• Why?
   ­ An unmodified IPv4 only MTA may want to check validity of any email 
address in the DNS,
     even if this address belongs to an IPv6 only domain.
• Solutions
   ­ all zones MUST have at least an IPv4 NS
   ­ …?

There was no discussion.

Tony noted that we will put a short timer on the -02 review given there 
were no comments here.

Alain and Tony commented on the joint DNS-EXT/NGTRANS meeting on IPv6 
addresses in the DNS that was held yesterday, noting that a draft of the 
outcome is coming soon for comment.

===
Bump In the API (BIA) - Myung-Ki Shin
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-bia-00.txt>

SLIDES:
<http://www.6bone.net/ngtrans/IETF-51-London/bia.ppt>

BIA History and Status
* IETF-45, July 1999
   ­ Basic idea was presented. (there was no doc.)
* IETF-50, March 2001
   - BIA draft was presented.
   - Accepted as working group project with strong guidance to include 
applicability and disclaimer to prevent misuse
* IETF-51, August 2001
   - First wg draft was published, <draft-ietf-ngtrans-bia-00.txt>
* IETF-52, December 2001
   - Hopefully finished soon after

A picture comparing BIS (Bump In the Stack) and BIA was shown.

While BIS is for systems with no IPv6 stack, BIA is for systems with an 
IPv6 stack, but on which some applications are either not yet available on 
IPv6 or application for which source code is not available or lost.

Required Changes
* Editorial Comments
   ­ Applicability Statement
   ­ Disclaimers
   ­ API functions list intercepted by BIA module [Appendix ?]

* Technical Comments
   ­ Additional Considerations

Applicability and Disclaimer
* Applicability Statement
   ­ It's good for early adopters who do not have all applications handy,
     but not for mainstream production usage.
* Disclaimer
   ­ We strongly recommend that application programmers SHOULD use this 
mechanism
     only when an application source code is not available.
   ­ Do not take it as an excuse not to port software. (Don't delay porting)

Considerations
* Socket API conversion
   ­ IPv4 socket API functions are translated into semantically the same
     IPv6 socket API functions and vice versa.
   ­ Which Functions are intercepted ?
     =>	They will be listed up in the second draft - Appendix

Additional Considerations
* Mis-match between DNS value (AAAA) and Application version (v4)

A diagram of this was shown.

* Solution ?
   ­ Try all the addresses listed in the DNS and
     just not fail after the first attempt
     => BIA can support this solution by extensions to name resolver
        and API translator in BIA module

ETRI & i2soft - Implementation
* bia-20010726-beta (second beta release)
* Windows 2000 + MS IPv6 Technology Preview
* Implemented using Windows2000 SPI(Service Provider Interface)
* Available at <http://www.krv6.net/bia/>

Implementation Status
* Currently it works well with
   ­ HTTP : IE and Netscape
   - Telnet : NetTerm and CRT telnet client
   ­ POP3 : Outlook Express and Netscape Mailer
* It does not work YET with
   ­ Server program
   ­ Application with IP addresses embedded in application layer protocols 
(FTP, etc.)
   - Multicast, QoS, etc.

Alain asked what BIA can do help failing after first attempt.

Myung-Ki responded we assume current host has both addresses. Alain said he 
would take this offline.

===
ISATAP Issues - Fred Templin
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-isatap-01.txt>

SLIDES:
<http://www.6bone.net/ngtrans/IETF-51-London/isatap.ppt>

Fred gave a brief overview of ISATAP, then listed the changes in ISATAP 
since IETF-50 (that were reported at the Interim in Seattle).

• Name changed to ISATAP
• Added "Terminology" section
• Require ISATAP/non-ISATAP addresses use different /64 prefixes ­ 
simplifies sending rules
• Changed u/l bit in EUI-64 interface ID to indicate LOCAL scope

He then describe developments since the interim meeting:

• Linux implementation by Nathan Lutchansky:
   ­ works with all kernel versions 2.2.16 ­ 2.4.6 (with/without USAGI)
   ­ testing with stateful configuration complete
   ­ multiple interface support (anticipated configuration scenario for NAT)
   ­ code for stateless auto-configuration complete; testing begins after 
IETF51
   ­ Stay tuned for code release announcements (TBD with Nathan)

Fred concluded with open issues since the interim meeting:

• When to deprecate ISATAP address?
   ­ Old answer: when native IPv6 Rtadv's heard
   ­ New answer: when native Rtadv's heard AND ISATAP interface usage drops 
below some threshold
   ­ Not conclusive; more study needed

• Will ISATAP addresses be preferred over native IPv6 addresses by longest 
prefix-match?
   ­ No ­ destination ordering will fix this (already addressed in 
source/destination selection draft)

• Will ISATAP present any new security issues? (question from private e-mail)
   ­ IPv6 source address spoofing seems like biggest issue
   ­ Nearly finished enumerating cases; spoofing easy to detect in all 
cases examined thus far
   ­ Claim: ISATAP secure IFF site's IPv4 network secure
   ­ Will send analysis to mailing list when complete

• Current draft expires 17 November 2001; new draft coming soon

Steve D asked what supporting multiple i/f means. Fred said two virtual i/f 
might be used, i.e., two locales in one site.

Alain asked why use it across two domains. Fred said you don't use on 
public address side, rather when NATs involved.

Christian noted that it is used for partially converted sites where you 
don't use 6to4.

Brian Zill asked if Nathan's Linux version inter-operates w/Windows yet. 
Fred said he had not tried that yet.

===
ISATAP Router Discovery - Dave Thaler
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-isatap-01.txt>

SLIDES:
<http://www.6bone.net/ngtrans/IETF-51-London/isatap-rtrdisc.ppt>

Problem Summary
• ISATAP makes IPv4 site look like one NBMA link
• Normal router discovery relies on multicast
• Observation:
   ­ Once you know the address of a router, you can unicast an RS and get a 
unicast RA
• So how do you discover the address of a router?

Robustness of RA's
• Normally RAs are periodically multicast
• If no RAs known (e.g., routers down)
   ­ Send RSs at low frequency, say 15 mins
   ­ Tradeoff between overhead and timeliness
   ­ Should be a temporary condition
• If RA known
   ­ Send RS after half of lowest lifetime in RA, to a minimum of the low 
frequency value above
   ­ Minimum intended to prevent overhead during renumbering

Several choices were briefly covered with pros and cons: SLP, DHCPv4, 
well-known host name, SRV record lookup, well-known IPv4 anycast address, 
and hybrid approaches.

Steve Deering queried that if RA is just one example of mcast, and given 
that we need to support NBMA links, why is RA specially handled? Dave 
responded that we need to know router ahead of time.
Steve asked again, but why special case RA? Dave noted that it is stateless.

Someone asked if he had onsidered using MARS. Dave replied yes, but that it 
is too complex and we only need something until native v6 connectivity 
occurs, not another special (and costly) service

Alain asked about the randomization time choice? Dave replied he needs to 
add it (and it will be 15 mins).

Alain stated that if using well known router name, he doesn't like 
unqualified (short) names as going thru resolver it might end up outside of 
domain, and is vulnerable to DoS attacks.

Fred noted that one could use different DNS responses to establish locality.

Someone asked if anycast is in use. Dave noted it is widely used in v4 
today. It's just a host route Tony Hain noted.

Dave asked if there is a preference for a given solution:

Jim B, liked anycast but disagreed that v4 anycast is in wide use, and 
needs to be tested very thoroughly for v6 before it is specified/used.

Alain noted that as ISATAP is a transition mechanism, it is temporary, thus 
easy to do is best, and not a hybrid; he wants to choose just one simple to 
implement approach.

Dave thinks the well known host name is easiest. Alain thinks anycast is as 
easy. Dave agreed.

Erik Nordmark asked if we want to discover one or more routers. Dave 
replied that this is something to think about.

Tony cutoff the question queue due to time. He noted that the topic should 
be taken to the list. He encouraged everyone to actively participate in 
this discussion online.

===
NAT traversal discussion - Alain Durand/Christian Huitema
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-natreq4ipv6-00.txt>
<http://www.ietf.org/internet-drafts/draft-huitema-shipworm-00.txt>

SLIDES:
<http://www.6bone.net/ngtrans/IETF-51-London/shipworm.ppt>

Alain first presented two scenarios for a lead in to Christian's topic. 
They are both home networking behind a NAT scenarios:

Case 1: NAT box that cannot be upgraded to IPv6
    Your ISP gives you just one global IPv4 address

Case 2: double NAT
    Your ISP gives you one private IPv4 address

These cause a problem for a 6to4 router placed in the home.

Christian then presented shipworm-00. A shipworm is one that bores holes in 
a ship's hull (read NAT ;-).

Repeating from the introduction to the draft:

"Classic tunneling methods envisaged for IPv6 transition operate by sending 
IPv6 packets as payload of IPv4 packets; the 6to4 proposal proposes 
automatic discovery in this context. A problem with these methods is that 
they don't work when the IPv6 candidate node is isolated behind a Network 
Address Translation device: NAT are typically not programmed to allow the 
transmission of arbitrary payload types; even when they are, the local 
address cannot be used in a 6to4 scheme. 6to4 will work with NAT if the NAT 
and 6to4 router functions are in the same box; we want to cover the 
relatively frequent case when the NAT cannot be readily upgraded to provide 
a 6to4 router function.

A possible way to solve the problem is to rely on a set of "tunnel 
brokers." There are however limits to any solution that is based on such 
brokers: the quality of service is not very good, since the traffic follows 
a "dog leg" route from the source to the broker and then the destination; 
the broker has to provide sufficient transmission capacity to relay all 
packets and thus suffers a high cost. For these two reasons, we tend to 
prefer solutions that allow for "automatic tunneling", i.e. let the packets 
follow a direct path to the destination.

The automatic tunneling requirement is indeed at odds with some of the 
specificities of NATs. Establishing a direct path supposes that the IPv6 
Candidate can retrieve a "globally routable" address that results from the 
translation of its local address by one or several NATs; it also supposes 
that we can find a way to bypass the various "per destination protections" 
that many NATs implement. In this memo, we will explain how IPv6 candidates 
located behind NATs can enlist the help of "v6 UDP routers" to learn their 
"global address" and to obtain connectivity."

Christian then described the principal design choices:

• Automatic discovery or explicit configuration?
• Stateless or stateful tunnel ? /64 or /128 ?
• Direct transmission or tunneling?
• Optimizing UDP-UDP or not ?

Automatic discovery or explicit configuration?
• Explicit configuration:
   ­ Tunnel as a "VPN" service
   ­ Almost never on "direct path"
   ­ Hard "for the masses"
• Automatic discovery
   ­ Requires "anycast address"
   ­ No clear business model => requires low cost service.

Steve Deering noted that if existing tunnel brokers use explicit 
configuration, doesn't prove that non-automatic explicit configuration is 
acceptable? Christian disagreed, saying that this does not constitute use 
by the masses.

Randy asked how congestion control works given it is required that this is 
addressed by Christian's proposal.
Christian said there are several examples of how it might work, but agreed 
to include consideration of this in the draft.

Steve Deering asked if you want stability for addresses across days. 
Christian said that if you have a contract between client and server 
(statefull) then it is a long term assignment, but he likes stateless 
systems better.
Steve replied yes, stateless preferred other things being equal, but isn't 
stability a goal. Christian noted that his specific goal is to be able to 
run peer-peer apps, thus need a globally reachable address, thus it needs 
to be known. Need to have a name service.

Steve again stated that we need stability.

Erik Nordmark commented that NATs often release port assignments in varying 
interval, thus you might get a different port. Christian noted that this is 
explained in his draft. What differs is interval, it is between 45 secs and 
15 minutes, so as long as stream shows activity more often that 45 secs, 
mapping is maintained.

Steve asked what gives Christian confidence in NAT characteristics. 
Christian replied market studies.

Tony noted that this is a side issue, and he wanted a hum shipworm becoming 
a project. There was hum consensus.

Christian will issue new draft, and make it a wg item. The shipworm name 
will still be used (we all like it).

Steve asked if there were any consequence of this solution for routing. 
Christian replied no.

===
Denial of Service by 6to4 anonymisation - Alain

SLIDES:
<http://www.6bone.net/ngtrans/IETF-51-London/6to4-dos.ppt>

Alain showed a diagram of a possible denial of service attack via a 6to4 
router.

His proposed solution is to do ingress filtering in the 6to4 router, where 
the IPv4 src address MUST match the IPv4 address embedded in the 6to4 src 
address.

Christian noted that this situation is covered in the 6to4 RFC already.

Steve Deering asked what if the ipv4 source address is a legitimate 6to4 
gateway and thus a test can't be used for filter.

Francis Dupont noted that this is a generic problem when you have two sources.

Alain had asked implementors if they do any source address filter checks, 
and they said no, in spite of the RFC. Thus Alain believes the text should 
be stronger.

Erik Nordmark noted that the IETF community needs to understand these type 
of DoS attacks better, and noted Vern Paxson recent paper on the topic.

Christian commented on how to differentiate a legit and illegit router. One 
possibility is to use a 6to4 anycast address as source for differentiation. 
If we don't use ingress source filtering, then attacker can do more than 
just this DoS attack. Thus don't bother.

Steve said that backinstalling the v4 internet with ingress source 
filtering not realistic.

Erik agreed the v4 Internet is not up to 100% ingress filtering, but it is 
good to do and minimize places where attacks can come from.

===
Moving MECH (RFC2893) forward to DS discussion - Erik Normark
<http://www.ietf.org/rfc/rfc2893.txt>

SLIDES:
<http://www.6bone.net/ngtrans/IETF-51-London/MECH-DS.ppt>

Erik presented his set of things to do to take MECH to DS.

   Update, simplify, remove redudancy
   Keep dual stack and configured tunneling

Remove from current RFC?

   Automatic tunneling (section 5)
    ­ 6to4 and ISATAP are more powerful
   IPv4-compatible addresses
    ­ Only used with automatic tunneling
   Description of address selection and IPv6/IPv4 selection (much of 
section 2.2)
   ­ Superceded by -ipngwg-default-addr-select-
   Default configured tunnel (section 4.1, 4.2)
   ­ Not used??

Next steps:
   Issue I-D with edits
   Comments are welcome!!
   WG chairs to put together implementation report
   ­ Needed for Draft Standard
   ­ Will have list of sections in draft with the features/options to be 
implemented

There was no discussion. A draft will soon be generated to implement these 
ideas.

===
DSTM & friends update - Jim Bound
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-dstm-04.txt>
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-dstmext1-aiih-00.txt>
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-6to4-dstm-00.txt>
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-siit-dstm-00.txt>
<http://www.ietf.org/internet-drafts/draft-shin-dstm-single-ipv4-00.txt>

SLIDES:
<http://www.6bone.net/ngtrans/IETF-51-London/DSTM-update.ppt>

Jim presented an overview of the relationship and status of the various 
DSTM related drafts.

He noted that as DHCPv6 will soon go to wg last call thus he will soon want 
to release a new version of DSTM and do a last call for forwarding to the 
IESG for PS on it.

There was no discussion.

===
BGP Tunnel remaining issue discussion - Jeremy De Clercq
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-isatap-01.txt>

SLIDES:
<xxxxxxxxxxxxxxxx>

Jeremy presented the status of recent changes made to the BGP Tunnel draft.

Erik Nordmark asked is v4 address a regular address or? Jeremy replied that 
yes it was. Erik then why not used a v4 mapped address. Jeremy replied that 
this may be work and will take it offline. Alain noted that he wants to 
converge on this on mail list so we can advance this draft as soon as possible.

===
Tunnel Servers/Brokers - Marc Blanchet
<http://www.ietf.org/internet-drafts/draft-vg-ngtrans-tsp-00.txt>

SLIDES:
<http://www.6bone.net/ngtrans/IETF-51-London/tsp.ppt>

Marc presented his idea for a protocol between clients and brokers:

For negotiation of parameters:
• Servers Capabilities
• Authentication method
• Client wants a /48, server don't want.

For Keepalive (detection of ipv4 network problems)

For Server policies:
• Lifetime of the tunnel

For Generalization and extensions
• DNS information
• Whois-type information

For Error conditions and protocol feedback (error numbers)

For Easy renegociation of parameters:
• change of ipv4 address
• Can be included in boot sequence (or dhcp lease,…)

He described possible protocol choices:
• Control protocol for tunnel setup
• Uses TCP
• Uses SASL (RFC2222) for:
   authentication negociation
   and transport encryption negociation
• XML messaging:
   easy to describe data, extend, optional parameters, …
• Protocol version numbering

There would be two documents:

• One framework
    generic for any kind of tunnels
    Supports both tunnel broker and server models
• One specific for ipv6 in ipv4 profile
• Others to come:
    IPv4 in IPv6 profile
•	Currently implemented in freenet6.net service.
•	More work on the detailed specification to be done.
•	Ngtrans wg work item?

Dave Thaler asked why not some existing protocol. Mark agreed.

Tony asked for hums on making this a wg item. There was little support for 
this becoming a wg project, thus it will not be accepted as one.

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

NO SLIDES

Alain noted that he is asking an expert on mime types if the draft is ready 
for last call. If so, then he will last call it.

There was no discussion.

===
Example Addressing draft - Marc Blanchet
<http://www.ietf.org/internet-drafts/draft-blanchet-ngtrans-exampleaddr-01.txt>

SLIDES:
<http://www.6bone.net/ngtrans/IETF-51-London/exampleaddr.ppt>

Marc noted the need to reserve some address space for documentation:
   RFCs, drafts, vendor doc, books, examples, …

He Proposed:
­ Inside the 3ffe: space
­ At the end of the space (3ffe:ff…
­	Length: 24, 28, 32

  3ffe:ff00::/24
     equiv of the ptla past policy
     Enables examples with multiple current tlas (/29)
  3ffe:fff0::/28
     follows the current ptla policy (anything >28 would consume anyway a ptla
     Enables two tlas
  3ffe:ffff::/32
     Smaller, less space wasted.


Steve Deering asked if we also then need a similar thing in mcast, site 
local...

Alain noted a site local only conflicts with yourself. Steve replied, yes, 
but within same site conflict is possible.

Dave Thaler noted that mcast already handled by this draft.

Itojun delt that with enough warnings as to usage, it is not required to 
reserve space for examples. Francis Dupont disagreed and believed it useful 
to reserve space.

Tony asked for a hum on making this a working group item, but there was no 
agreement.

Bob Hinden and Steve Deering stated that they felt this work item belonged 
in ipngwg, as it reserves address space, so it was agreed to move this to ipng.

===
IPv6-SMTP-REQUIREMENTS - Itojun
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-ipv6-smtp-requirement-02.txt>

SLIDES:

Outline

	
  Operational requirements for IPv6 SMTP, and IPv6 DNS MX records
  Goal: stable email transport in IPv6/v4 dual stack world

  Similar content presented by Kazu, at IETFxx

  Outgoing: be careful looking up all MX/A/AAAAs
  Incoming: configure MX right, be sure to keep reachability among servers

IPv6 MX lookup (outgoing)

   Same, but a bit more complicated

   email to [e-mail]

   Lookup example.org
     MX - use it, based on preference (then A/AAAA)
     A/AAAA - use it
     CNAME - resolve till get to MX/A/AAAA

    Be sure to try all available As and AAAAs
    SMTP failure handling (4xx or 5xx) complicates the story

    example.org.            IN MX   1  mx1.example.org.
                            IN MX   10 mx10.example.org.
    mx1.example.org.        IN A    1.0.0.1          ; IPv4/v6 dual stack
                            IN AAAA 3ffe:501:ffff::1
    mx10.example.org.       IN AAAA 3ffe:501:ffff::2 ; IPv6 only

MX for dual stack sites (incoming)

   Be sure to allow emails to get delivered to the final email server

   If possible, make the most preferred MX a dual stack node

; easy and good config
   easy.com.	IN MX 1  v4only.easy.com.
   easy.com.	IN MX 10 dualstack.easy.com.
; good config
   good.com.	IN MX 1  dualstack.good.com.
   good.com.	IN MX 10 v4only.good.com.
; bad config
   bad.com.	IN MX 1  v4only.bad.com.
   bad.com.	IN MX 10 v6only.bad.com.

Misc comment/changes

   Interpretation of scoped address in MTAs
       itojun@[fec0::1]@[3ffe::1]@[fec0::1]
        Forbid numerics?  Can be a security issue...
		
The syntax has obsoleted in RFC2822

   Deployment/tests
     Mononori have made experiments to check readiness of MTAs, regarding 
to A/AAAA MX records
       No implementation (we have seen) choked - it seems safe to declare 
IPv6 MX records
       Sendmail 8.10/11, as well as other IPv6-ready MTAs, work as 
documented in this draft (outgoing)

Summary

   Operational requirements for IPv6 SMTP, and IPv6 DNS MX records
   Goal: stable IPv6 email transport

   Similar content presented by Kazu, at IETFxx

   Outgoing: be careful looking up all MX/A/AAAAs
   Incoming: configure MX right, be sure to keep reachability among servers

   Would like a last call for informational.

There was no discussion.

===
An IPv6/IPv4 Multicast Translator based on IGMP/MLD Proxying (MTP) - 
Kazuaki Tsuchiya
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-mtp-00.txt>

SLIDES:
<http://www.6bone.net/ngtrans/IETF-51-London/mtp.ppt>

Kazuaki presented the new MTP project (recently accepted as an ngtrans 
project). See the slides above for pictorial contect.

- Document status
   > Accepted as the Ngtrans working group document at the last meeting

- Changes from the previous draft
   > Extended applicability to large-scale network systems

- Need to define a specific setup protocol for the interaction
   between the IPv6 clients and the IPv4 multicast proxy?

   > This is outside the scope of the document?

   > Nevertheless, for helping implementation efforts,
     an example should be described in the document?

There was no discussion.

===
Connecting IPV6 islands within a same IPV4 AS - Damien Galand
<http://search.ietf.org/internet-drafts/draft-many-ngtrans-connect-ipv6-igp-00.txt>

SLIDES:
<http://www.6bone.net/ngtrans/IETF-51-London/IGP-tunnel.ppt>

There was no time for the presentation so it was agreed to take the 
presentation and discussion to the list. Please see the slides listed above.

There was no discussion.

===
Multicast extensions to BIS (mBIS) - Kazuaki Tsuchiya
<no paper submitted by cutoff>

SLIDES:
<http://www.6bone.net/ngtrans/IETF-51-London/mbis.ppt>

There was no time for the presentation.

===
Adjourn
-end