2.4.9 Next Generation Transition (ngtrans)

NOTE: This charter is a snapshot of the 47th IETF Meeting in Adelaide, Australia. It may now be out-of-date. Last Modified: 11-Feb-00


Bob Fink <rlfink@lbl.gov>
Tony Hain <tonyhain@microsoft.com>
Alain Durand <alain.durand@eng.sun.com>

Operations and Management Area Director(s):

Randy Bush <randy@psg.com>
Bert Wijnen <bwijnen@lucent.com>

Operations and Management Area Advisor:

Randy Bush <randy@psg.com>

Mailing Lists:

General Discussion:ngtrans@sunroof.eng.sun.com
To Subscribe: majordomo@sunroof.eng.sun.com
In Body: subscribe ngtrans
Archive: ftp://ftp.ietf.org/ietf-mail-archive/ngtrans/

Description of Working Group:

1. Specify the tools and mechanisms that might be used for transition to IPv6.

2. Write documents outlining how the various transition tools and mechanisms might apply to various scenarios for a transition to IPv6.

3. Coordinate with the IPv6 6bone testbed, operating under the IPv6 Testing Address Allocation allocated in Experimental RFC 2471, to foster the development, testing, and deployment of IPv6.

4. Coordinate appropriately with other IPv6 related IETF activities and activities in other organizations.

Goals and Milestones:

Dec 94


Submit Internet-Draft on General Overview of Transition.



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



Submit Internet-Draft of Transition Plan for the Internet.



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



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

Apr 95


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

Jul 95


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

Mar 96


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

May 96


Register 6bone.net with InterNIC and establis dns support

Jul 96


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

Aug 96


Establish ftp-based 6bone registry at RIPE-NCC

Nov 96


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

Dec 96


Start restructuring 6bone to a tiered backbone architecture

Mar 97


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



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



Start conversion of 6bone to Aggregatable Unicast Address Format

Nov 97


Testing starts on new Aggregatable Unicast Address Format



RFC 2471 formalizes IPv6 Testing Address Allocation



Hold Interim meeting in Grenoble



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

Jul 99


Submit modified RFC1933 to IESG for consideration as a Draft Standard

Dec 99


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

Dec 99


Submit Roadmap I-Ds for IESG processing as Informational RFCs

Mar 00


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


Request For Comments:







Transition Mechanisms for IPv6 Hosts and Routers



Routing Aspects of IPv6 Transition



Stateless IP/ICMP Translation Algorithm (SIIT)



Network Address Translation - Protocol Translation (NAT-PT]



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



6Bone Backbone Routing Guidelines

Current Meeting Report

Minutes of NGtrans WG Meeting

27/29 March 2000

Adelaide IETF-47



Alain Durand <Alain.Durand@eng.sun.com>

Bob Fink <fink@es.net>

Tony Hain <tonyhain@microsoft.com>

This ngtrans meeting reported by Bob Fink and Tony Hain.

Attendance was ~150.

Alain Durand & Bob Fink chaired the meeting.


Administrative information:

Discussion ngtrans: <mailto: ngtrans@sunroof.eng.sun.com>

Subscribe ngtrans: <mailto: majordomo@sunroof.eng.sun.com> "subscribe ngtrans"

Archive ngtrans: <http://www.wcug.wwu.edu/lists/ngtrans/>

Web site: <http://www.6bone.net/ngtrans>

Discussion 6bone: <mailto: 6bone@isi.edu>

Subscribe 6bone: <mailto: majordomo@isi.edu> "subscribe 6bone"

Archive 6bone: <http://www.wcug.wwu.edu/lists/6bone/>

Web site: <http://www.6bone.net>



Project status report - Bob Fink

BT Patent IPR status - Bob Fink

MECH-04 update status - Erik Nordmark

6to4-04 new draft - Brian Carpenter

DSTM-01 new draft - Laurent Toutain

SOCKS-03 new draft - Hirsohi Kitamura

TRANSLATOR-03 new draft - Kazu Yamamoto

BROKER-02 - Ivano Guardini

Tunnel Discovery - ALain Durand

TCPUDP-RELAY-00 new draft - Jun-ichiro itojun Hagino

TRANSITION-03 new draft - Alain Durand

6PAPA-01 new draft - Bob Fink

pTLA-00 new draft - Bob Fink

ABUSE-00 new draft - Jun-ichiro itojun Hagino

Interim NGtrans meeting planning - Alain Durand & Bob Fink

PingERv6 Report - Les Cottrell

Relocated 6bone registry - David Kessens

6tap report - Florent Parent

pTLA reliability report - Ivano Guardini

Root name server issues - Akira Kato

Project status report - Bob Fink

Bob presented the status of all ngtrans projects from the ngtrans web site's project status pages:


Let Bob know of any errors.

BT Patent IPR status - Bob Fink


Bob Fink related the background and current status of the BT patent issue.

1. BT notified the IETF Secretariat on Nov 5, 1999 that:

"In accordance with the IETF Rules, BT would like to disclose that we have recently applied for patents in the IPv6 space relating to:

- the establishment of tunnels using DNS as the tunnel endpoint discovery mechanism and

- a mechanism that enables translation and tunneling to be combined into a single device.

BT does so in the belief that these recent patent application are relevant to present discussions within the IETF."

2. After the IETF Secretariat queried BT, a reply was received on Nov 12, 1999, saying:

"Also in accordance with IETF Rules, BT hereby gives the assurance that, following approval by the IESG of the relevant Internet standards specification, BT will grant licences under these patent applications and under any resultant patents, on openly specified, reasonable and non-discriminatory terms, to implement the Internet standards specification, provided the licensee similarly grants licences under its necessary applications/patents."

3. BT is under no responsibility to say more about their possible patents than they already have.

4. From the information on hand, or likely to become available, there is no clear way of telling if any work now underway in ngtrans is possibly affected by BT patents.

5. If any ngtrans work eventually is covered by BT patents, BT's assurance to grant licenses is minimally acceptable according to Steve Coya, IETF Secretariat:

"Note that during the Stockholm meeting, the concept of determining whether the licensing was openly specified, reasonable and non-discriminatory terms would be based on implementor feedback (i.e. if enough folks entered into an agreement, that would be sufficient to "prove" or demonstrate that the licensing arrangements were palatable. This will be treated like an option when/if the protocol is submitted for consideration as a Draft Standard."

6. Thus there is no reason to do other than proceed with all work now underway in ngtrans.

Not hearing anything to the contrary, Bob declared the BT issue closed for now.


ABUSE-00 new draft - Jun-ichiro itojun Hagino

Itojun gave a report of potential abuses to IPv6 transition mechanisms that is available at:


The document talks about possible abuse of IPv6 transition technologies, which may lead to denial-of-service (DoS) attacks and other problems. IPv6 transition technologies, namely IPv6 over IPv4 tunnelling specifications and some others, have room for abuse by malicious parties. Detailed descriptions and possible workarounds are supplied. The specific areas of problems noted were:

- Abuse of IPv4 compatible address

- Abuse of 6to4 address

- Abuse of IPv4 mapped address

For which he gave possible solutions (see the paper).

His recommendations to future proposals were:

- If you use tunnels, require explicit configuration

- Manual configuration

- Authenticated automatic configuration

- Don't put IPv4 address into IPv6 address, for purpose of relays

- Do not define IPv6 addresses that are not used on the wire

- Makes it much harder to check

...and his summary:

- Bad guys can abuse some of transition techniques

- Don't run 6to4/auto tunnel relay, if you don't need one

- Be careful about v4 mapped address

- What to do next?

- Incorporate checks presented here, into original proposals

- Publish it as separate document (informational?)

- Let us check other proposals as well

- Let us deploy native IPv6 network sooner, so that we no longer need tunnels


MECH-04 update status - Erik Nordmark

Erik noted changes he has made to MECH-04 in preparation for MECH-05.

- Specified when to put IPv6 addresses in the DNS.

- Added reference to the tunnel mib for TTL specification for the tunnels.

- Added recommendations for use of source and target link layer address options for the tunnel links.

- Added checks in the decapsulation checking both an IPv4-compatible IPv6 source address and the outer IPv4 source addresses for multicast, broadcast, all-zeros etc.

Erik will issue MECH-05 as soon as he can (already done on April 6 and a wg last call issued).


6to4-04 new draft - Brian Carpenter

Brian presented the changes from -03 to -04 and highlighted issues remaining.


- added terminology section

- another revision of address selection text

- described link local address formation

- changed sending rule to refer to next hop

- removed confusing text on IPv4 header padding

- clarification/corrections to exterior routing discussion (scenarios with & without BGP)

- clarified MTU text again

- added section on routing loops

- added and removed text on multicast

- added text on RSIP

- reformulated section on Intranet usage (use of Net 10 addresses now forbidden)

- clarifications/response to detail comments


- text on PIM-SM needs checking by a PIM-SM expert

- Is link-local address really needed?

- host-only draft: volunteer needed

- Is this ready for PS?

Brian thanked Jim Bound's group for their comments.

Regarding link local there was a debate about its need. Itojun argued that it wasn't necessary, and it was agreed to pursue this discussion on the list.

There was discussion of the need to rewrite the multicast section.

Steve Deering was asked to comment on PIM-SM usage in 6to4. He felt that the problem generalized to the NBMA network case, noting that MARS was the state-of-the-art in this regard.

There was concern about the applicability of IPv4 tools in the IPv6 space

There was a call for review of the multicast section by experts.

Brian noted that the security section already talks about ingress filtering in regards to Itojun's abuse concerns (covered earlier in these minutes).

Brian stated that he would like to try to move 6to4 to PS before Pittsburgh.


DSTM-01 new draft - Laurent Toutain

Laurent made a few comments on the new DSTM-01 draft and DSTM status in general:

- cleaned up text

- 6->4 is mandatory

- 4->6 is optional

- 4->4 is optional

- implementation in bsd (inria)

- dhcpv6 concurrent work : only 4 messages needed

- modify dns when v4 query fails

- question about timeouts : timer in dstm based on pool

- will use implementations to adjust timers : new text next time


SOCKS-03 new draft - Hirsohi Kitamura

Hiroshi gave a status report on the new -03 draft:

- IESG comments were incorporated into -03

- there are two available independent implementations

- NEC: http://www.socks.nec.com

- KAME: ftp://kame.net/pub/kame/misc/socks64-...

- there are about 5000 downloads/year of the SOCKS code from 80 different countries

- a -04 will be out soon to answer other comments


TRANSLATOR-03 new draft - Kazu Yamamoto

Kazu gave a status report on the new -03 draft called Overview of Transition Techniques for IPv6-only to Talk to IPv4-only Communication, which was previously called Categorizing Translators between IPv4 and IPv6


- The previous version "02" was published in Oct 1999

- Comments from IESG in Dec 1999

- Wording

- Bilingual -> dual-stack

- Proxy -> application level gateway

- Definition of "translator" is unclear

- Weakness

- Some explanations in this memo are not applicable to SIIT (FTP, IPsec, ...)

- SOCKS5 is not TCP-relay

- Situation is changing

- This draft was based on a paper of INET 1998 (written in 1997)

- It is getting harder to modify IPv6 hosts

Version "03" was published in Mar 2000

Differences between -02 and -03

- Title

- OLD: Categorizing Translators between IPv4 and IPv6

- NEW: Overview of Transition Techniques for IPv6-only to Talk to IPv4-only Communication

- Wording

Defined "translator" in this memo an intermediate component between an IPv4 host and an IPv6 host to enable direct communication between them, without requiring any modifications to them.

Accepted IESG's comments

- Assumption

- OLD: We can change IPv6 hosts as we like

- NEW: It is difficult to change IPv6 hosts

- Outside the scope




Mechanisms requiring specific functionality for IPv6 hosts

- Address mapping:

- OLD: Suggested to use both DNS hack and resolver hack

- NEW: Suggest to use DNS hack only

- Resolver hack means changing IPv6 hosts

Next step

- Authors hope:

- to publish it as Informational RFC

- then to help the ROADMAP document project

Kazu asked the chairs to please return -03 to the IESG to continue processing there towards Informational RFC.


BROKER-02 - Ivano Guardini

Ivano gave a status report of the older -02 draft:

- WG last call after Washington IETF

- One comment about MIME type

- -02 draft not updated yet

- Plan A:

- Include MIME media-type definition in the document?

- Other WG may benefit from the MIME-type

- Plan B:

- Publish framework as Informational

- Publish MIME-type as separate,informational RFC

- Actions for Plan B

- Remove implementation section (appendix)

- Add short discussion as MIME-type as implementation option

- Open door for the use of Tunnel Broker concept in other areas

- Publish framework as Informational RFC

- Publish MIME-type description in a separate document

- Proposed MIME type

- application/tunnel

- parameters: ipv6/ipv4

- src,dst v4 & v6 address

- Tunnel management procedure

- TTL with sub-parameter TTL value

- something smarter?

- Textual description

a -03 draft will be published soon


Tunnel Discovery - ALain Durand

Alain presented his ideas on Tunnel Endpoint Discovery, exploring new directions:


Granularity of tunnel end point discovery mechanism

- Automatic tunnels: 1 host (/128)

- 6over4: 1 host (/128)

- Tunnel broker: typically 1 host (/128)

- 6to4: 1 site (/48)

- Might be a need for other granularity:

- /64, /56, /49 intra-site

- /35, /29, /24 wan

Potential candidate: DNS...

- DNS is a natural distributed model

- network administrators know DNS

- DNS can handle different levels of granularity

- But:



Tunnel End Point Discovery Process Steps

1. Source S sends a packet to D1, packet goes to exit router R, but R has no route for D1...

2. Router R uses DNS to discover Tunnel End Point (TEP) IPv4 address. It also discovers that TEP is responsible for P/24. There is a TTL associated to the DNS response.

3. Router R create a uni-directional tunnel to TEP and add a route for P/24 through that tunnel. Packets are routed to D1 using P/24 IPv6 infrastructure

4. Source S2 now sends a packet to D2. As D2 is part of P/24, router R already has a route for it. It does not need to do another DNS query. It routes the packet through the existing tunnel.

5. After TTL expires, router R delete the tunnel and the route for P/24

DNS mechanism

- Dedicated reverse tree tunnel6.ip6.int

- DNAME for delegation

- Wildcard entries for PTR

- Reserved label "tunnel6" tag prefix len

Configuration example

- Tunnel end point for 3ffe:0300::/24 is

\[x3ffe/16].tunnel6.ip6.int IN DNAME 16.tunnel6.6bone.net.

\[x03/8].16.tunnel6.6bone.net. IN DNAME 24.tunnel6.imag.fr.

*.24.tunnel6.imag.fr. IN PTR basta.imag.fr.

basta.imag.fr IN A

Query example

- Query:

PTR for 1.0.0....

- Response:

1.0.0.... IN PTR basta.imag.fr.

basta.imag.fr. IN A

At the end of Alain's presentation there were various comments:

- that iesg needs to decide about ipv6.int

- that using dns to do routing is a bad idea

- that using dns for real-time services will fail

- that using dns will be more painful than the account can absorb

- that this needs service location & routing to make it work

- question about what is better about this than 6to4

No conclusion was reached about the pursuit of this effort, stay tuned.


TCPUDP-RELAY-00 new draft - Jun-ichiro itojun Hagino

Itojun gave a presentation of his new draft called An IPv6-to-IPv4

transport relay translator:

- Transparent TCP relay

- Has been used in firewall-oriented products like TIS gauntret

- We can use it for IPv6-to-IPv4 translation

- No extra configuration/code on end node

- No tricky MTU issues

- Stateful TCP relay box

- A TCP connection goes through single TCP relay box

- Can place multiple boxes against multiple clients

- We have been using it for more than 3 years, working just great...we thought we'd better document it

- The talk will focus on:

- IPv6-to-IPv4 translation (IPv4-to-IPv6 is possible)

- TCP relay (UDP is also possible)

Transparent TCP relays (IPv4-to-IPv4)

- A originates TCP to X (A -> X)

- TCP relay box hijacks the connection and terminate it at B (A -> B)

- TCP relay box originates TCP to X (Y -> X)

- TCP relay box relays content across two TCP connections

- originating node (A) --> TCP relay box (as X, interface is B)

- address on IP header: A -> X

- TCP relay box (Y) --> destination node (X)

- address on IP header: Y -> X

Transparent TCP relays (IPv6-to-IPv4)

- Reserve an IPv6 /64 prefix R6::/64, announce routes

- A6 originates TCP to C6::X4 (A6 -> R6::X4)

- TCP relay box hijacks the connection and terminate it at B6 (A6 -> B6)

- TCP relay box originates TCP to X4 (Y4 -> X4)

- TCP relay box relays content across two TCP connections

- IPv6 TCP: originating node (A6) --> TCP relay box (as R6::X4, interface is B6)

- address on IPv6 header: A6 -> R6::X4

- IPv4 TCP: TCP relay box (Y4) --> destination node (X4)

- address on IPv4 header: Y4 -> X4

Address mapping

- Similar to other translation techniques

- Modified DNS server

- For installation to large site

- Special entries in /etc/hosts

- For small installation

- Modified resolver on the originating node

- Not recommended, modifying originating node makes it hard to deploy

Multiple servers, for scalability/availability

- Setup multiple TCP relay boxes

- Assign different reserved prefix, advertise all of them

- Present different fake address by DNS round-robin or alike

- Once TCP is established we don't change address pair

- When B6/Y4 goes down, connections through D6/Z4 will be okay


- No need to care about path MTU/fragmentation issues

- Per-packet translation needs a great care

- Need to care about urgent data

- Can relay UDP

- Recognize UDP "connection" like NAT does

- Can relay IPv4-to-IPv6

- Address mapping issue

- To relay FTP need to rewrite payload data

- Access control is mandatory

- Malicious party can take advantage of it to anonymize connection

- KAME has been using this for 3 years, works quite well

- Served 100+ nodes at ipngwg Tokyo interim meeting

- We have been using it in many occasions

- Two "tricky" name server implementations exist

- totd/newbie

- {Free,Net,Open}BSD includes this FreeBSD 4.0: IPv6 enabled by default!


- IPv6-to-IPv4 translation using TCP relays

- Simple implementation, works very well

- No change in end node - can serve any of existing IPv6 nodes

- Would like to issue it as an informational RFC, to help future implementers

- Not a new protocol, fits best to informational

- ngtrans project, or individual submission?

- To try it out from terminal room: to your IPv4,

- telnet 3ffe:501:4819:ffff::

- ssh -v 3ffe:501:4819:ffff::

Travels Adelaide -- Tokyo -- your place, may add delay

Noted that it should refer to existing list of applications affected by nat

It was agreed that ngtrans would take on this as a project. Tthere was some minor debate about whether it should be Informational or Standards track, which resulted in the chairs determining (for now) that Informational RFC was most consistent with other ongoing and past projects.


TRANSITION-03 new draft - Alain Durand

Alain gave a status report on the "roadmap" transition document effort:


- New scenarii

- large new IPv6 network


- Update of all references

- Clarification text on

- Tunnel Broker, Bis, BiAPI, 6to4, DSTM, OSPF, 6PAPA

- Remove all mention to particular implementation

New Structure

1. Introduction

2. General deployment issues

3. Basic transition mechanisms (RFC1933 & update)

4. The tools

4.1.1 connecting IPv6 islands

4.1.2 communication between IPv4 & IPv6

5 & 6. Scenarii

Work continues!


6PAPA-01 new draft - Bob Fink

Bob noted that he had not issued a new draft for balloting, nor the 6bone steering committee, as the RIRs were now reviewing their IPv6 address allocation policies which could affect 6PAPA. Thus he will wait until it is clear that the 6bone prequalification for sub-TLA allocation will stay in place.


pTLA-00 new draft - Bob Fink

Bob reported that he had written the pTLA draft for the purpose of documenting existing pTLA/pNLA 6bone prefix formats, and would soon do a wg last call for Informational.


Interim NGtrans meeting plannng - Alain Durand & Bob Fink

Alain & Bob expressed the need to have an interim ngtrans meeting to:

- review state of the tools for

- security issues & corner cases

- recent proposals

- explore new directions

- industry evaluation

It was proposed to hold it in the San Francisco area, probably hosted by Sun. Some possible dates were balloted for interest:

~4 for May 23-25

~6 for May 30-31, June 1 (just after US memorial day)

~8 for June 6-8 (conflict in Japan)

Sentiments seemed low on the need for an interim. The chairs agreed to continue looking into the viability of a meeting as well as when it might be, if one was held. Stay tuned.


PingERv6 Report - Les Cottrell

Bob Fink introduced Les Cottrell (of the US SLAC accelerator laboratory) noting that his group's efforts to use inexpensive and easily deployable methods to measure the quality of Internet paths had been highly successful for IPv4, and that Les' group at SLAC had extended them to IPv6.

Les presented their work:


PingER (for IPv4)

- Simple active end-to-end ping monitoring

- Main community is HENP & ESnet sites

- 30 monitoring sites in 15 countries

- 593 nodes at 424 sites in 72 countries

- ~ 2200 pairs

PingER6 (for IPv6)

- A small amount of bandwidth is carved off ESnet connection to provide native IPv6 service to SLAC

- Recompiled Linux 2.2.5-15 (Red Hat 6.0) kernel with IPv6 support

- Downloaded & installed inet-apps (including ping) from inner.net and patch for glibc-2.1 systems

- Wrote Perl module to provide IPv6 DNS lookup

- Currently one monitoring site at SLAC

- PingER6 has been an international effort

- 6Bone and 6REN sites participating in 10 countries, 40 sites

- Currently little knowledge of networks and connections.

- Not surprisingly, same issues as the ipv4 Internet.

- Not enough bandwidth

- but it is only experimental

- How to persuade users to try it out ?

- Bob Fink big help in signing people up

- Contact warrenm@slac.stanford.edu to join PingER6

- Next steps

- Address concerns over security

- More Monitoring Sites

- 6-Tap a good place for a PingER

- China ?

Les thanked all the sites who have participated.

More Information requested from all possible participants

- IEPM/PingER home site


- Very interesting Polish 6BONE ping site


Les was asked to discuss relationship to similar tools, and Les responded that PingER results were well aligned to special hardware solution, like Internet Surveyor, for a cheap solution.

Les noted that icmp is treated differently, but that practice shows there is little affect in most places due to rate limiting. When this is observed to be a problem new target sites are chosen.

He closed noting that the PingER6 efforts will continue and encourage all interested to participate.


Relocated 6bone registry - David Kessens


6tap report - Florent Parent

Florent reproted on the current status of the 6tap, which is jointly managed by Canarie/Viagenie and ESnet at the Chicago StarTAP.

- a tunnel server will be installed next week as an extension of native IPv6 service to provide site-level tunnel support (as opposed to the tunnel brokers individual host tunnel support).

- in addition, a route server & registry service will be developed

- solaris 8 server w/ATM to Esnet

- MRTd (Merit)

- IPv6 registry (Kessens)

- next: 6to4 relay service & stats



pTLA reliability report - Ivano Guardini

Ivano gave a report on the reliability of routing in the 6bone:


- bgp4+ monitoring effort

- ~50% more prefixes announced than the pTLA list would suggest

- unaggregated prefixes are the bulk: multi-homed leaking

- filtering out nosiest sites: 80% of sites are almost always reachable

- most stable plotted against most unstable: instability growing

- upper bound of route instability for 80% of sites is less than 5%

- stability is good for 80%: multihoming is a problem


- The results of the CSELT's 6bone monitoring effort confirm that BGP4+ routing within the 6bone backbone has become highly reliable both with respect to stability and route availability

- this in turn highlights the good level of maturity reached by the currently available IPv6 technology some other issues still need to be solved

- multihoming is still a problem

A subset of these results is regularly updated at:



Root name server issues - Akira Kato

Akiro gave a brief report on upcoming experimentation plans for the new BIND release in the root name servers

- experimental operation is planned with a few servers which will be operational soon

- separate box for v6

- 3ffe:000[1-d]::/32 for each server or

- use /24 or/28 to each server

- advertise /32 : may violate 6bone routing

- need to modify bgp pathlen filters

Various comments and questions were made:

- why special addresses?

- are these unicast or anycast?

- routing propagation is the issue: special addr not necessary

- no room to add aaaa/a6 in 512 byte

- is edns0 mandatory for ipv6 queries

- ip6.int may be server as well

- one or two servers operational soon

- 512 mtu is bogus in v6

- deployment requires careful thought

- don't worry about edns0 because it covers IPv4 requirements

- separate roots proposed


Meeting adjourned.


None received.