2.3.6 IPNG (ipngwg)

NOTE: This charter is a snapshot of the 45th IETF Meeting in Oslo, Norway. It may now be out-of-date. Last Modified: 27-May-99


Bob Hinden <hinden@iprg.nokia.com>
Steve Deering <deering@cisco.com>

Internet Area Director(s):

Thomas Narten <narten@raleigh.ibm.com>
Erik Nordmark <nordmark@eng.sun.com>

Internet Area Advisor:

Thomas Narten <narten@raleigh.ibm.com>

Mailing Lists:

General Discussion:ipng@sunroof.eng.sun.com
To Subscribe: majordomo@sunroof.eng.sun.com
In Body: in body: subscribe ipng
Archive: ftp://playground.sun.com/pub/ipng/mail-archive

Description of Working Group:

Editor: Bob Hinden (hinden@eng.sun.com)

The next generation of the Internet Protocol (IPv6) is intended to support Internet traffic for many years into the future by providing enhancements over the capabilities of the existing IPv4 service. This working group will produce specifications for the core functionality of that service. The working group shall carry out the recommendations of the IPng Area Directors as outlined at the July 1994 IETF and in ``The Recommendation for the IP Next Generation Protocol,'' Internet-Draft, (draft-ipng-recommendation-00.txt), September 1994.

The working group shall use the following documents as the basis of its work:

- Simple Internet Protocol Plus (SIPP) Specification (128 bit version)

- SIPP Addressing Architecture

- An Architecture for IPv6 Unicast Address Allocation

- Simple SIPP Transition (SST) Overview

- SIPP Program Interfaces for BSD Systems

- SIPP Security Architecture

- SIPP Authentication Header

- SDRP Routing Header for SIPP-16

- IP Next Generation Overview

- ICMP and IGMP extensions for SIPP

- FTP Operation Over Big Address Records (FOOBAR)

- DNS Extensions to support SIPP

Enhancements to be considered:

- Large Packets: Consider extensions for support of datagrams which are larger than 64K.

- Source Routing: The working group shall consider enhanced source routing capabilities for IPng.

- Tunneling: Complete specification of IPng in IPng tunneling.

- Address format and assignment plan: The working group shall review the details of address structure as specified in [SIPP-16] and shall repair any deficiencies with respect to current or near-term addressing requirements, assuming a fixed, 16-byte size. The specification shall provide a mechanism for supporting multiple additional formats, for possible enhancement to incorporate other popular addressing schemes.

- Routing Structure: In completing the addressing details, the working group shall ensure that routing according to current, CIDR-like schemes can be supported comfortably.

- Autoconfiguration: Coordinate with the IPng Address Autoconfiguration Working Group.

- Transition: The working group shall coordinate with the related transition and conversion efforts (ngtrans, tacit, nosi, etc.) to ensure that the base specification provides the facilities required for the transition from IPv4.

- Security: A set of base documents for IPng security shall be completed. This shall include algorithms for authentication and privacy carried as IPng extension headers and include an initial selection of required encryption and key management algorithms and a facility to support other optional algorithms. The working group should also examine IPng firewall issues and if necessary develop specific firewall frameworks.

- Minimum MTU: Consider a larger minimum MTU.

- Header Compression: Consider ways to abbreviate the IPng header in the contexts of native IPng, multiple IPng packets in a flow, and encapsulated IPng.

- TCP/UDP: The IPng Working Group will specify the procedures for hosts to compute and verify TCP/UDP pseudo-headers. Any other changes to TCP beyond making TCP work with IPng are out of scope of the working group and should be dealt with by a TCPng Working Group.

The IPng Working Group will coordinate with other groups, including Mobile IP, IPng Address Autoconfiguration, OSPF, IS-IS, RIPv2, IDR, Security, Applications, Network Management, IP over ATM, etc.

Goals and Milestones:



Submit preliminary IPng core specifications, with required enhancements, as Internet-Drafts.



Submit revised core IPng specifications as Internet-Drafts.



Submit core IPng specifications to IESG for consideration as Proposed Standards.



Submit extended IPng specifications as Internet-Drafts.



Submit extended IPng specifications to IESG for consideration as Proposed Standards.



Submit revised specifications to IESG based on implementation experience for consideration as Draft Standards.



Submit revised IPng specifications as Internet-Drafts.



Submit final IPng specifications to IESG for consideration as Standards.

Aug 97


Submit revised specifications to IESG for Proposed Standard. Includes Aggregatable Unicast Formats, IPv6 over Ethernet, IPv6 over FDDI, IPv6 over Token Ring, IPv6 over PPP, Header Compression, etc.

Aug 97


Submit updated core IPng Specifications to IESG for Draft Standard. Includes: Protocol, Addressing Architecture, Addressing Documents, ICMP, Neighbor Discovery, Address Auto Configuration, DNS, etc.

Jan 98


Submit IPng specifications at Proposed Standard to IESG for advancement to Draft Standard.

Jun 98


Submit IPng specifications at Draft Standard to IESG for advancement to Standard.


Request For Comments:







DNS Extensions to support IP version 6



An Architecture for IPv6 Unicast Address Allocation



Path MTU Discovery for IP version 6



OSI NSAPs and IPv6



TCP and UDP over IPv6 Jumbograms



Advanced Sockets API for IPv6



IPv6 Multicast Address Assignments



IP Version 6 Addressing Architecture



An IPv6 Aggregatable Global Unicast Address Format



Neighbor Discovery for IP Version 6 (IPv6)



IPv6 Stateless Address Autoconfiguration



Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification



Transmission of IPv6 Packets over Ethernet Networks



Internet Protocol, Version 6 (IPv6) Specification



IP Version 6 Management Information Base for the Transmission Control Protocol



IP Version 6 Management Information Base for the User Datagram Protocol



Management Information Base for IP Version 6: Textual Conventions and General Group



Management Information Base for IP Version 6: ICMPv6 Group



Proposed TLA and NLA Assignment Rules



Transmission of IPv6 Packets over FDDI Networks



Transmission of IPv6 Packets over Token Ring Networks



IPv6 Testing Address Allocation



IP Version 6 over PPP



Generic Packet Tunneling in IPv6 Specification



Transmission of IPv6 Packets over ARCnet Networks



IP Header Compression



Reserved IPv6 Subnet Anycast Addresses



Transmission of IPv6 over IPv4 Domains without Explicit Tunnels



Basic Socket Interface Extensions for IPv6

Current Meeting Report

Minutes of the meetings of the IPng Working Group in Oslo, July 1999

Meetings chaired by Bob Hinden / Nokia
Minutes recorded by Allison Mankin / ISI

Wednesday, July 14

I. Agenda Bashing

It was reiterated that Steve Deering was unable to attend Oslo because of a family emergency.

Dave Johnson announced that the mobile-ipv6 draft was resubmitted just before meeting, and it is very close to final, but still needs to have added clarification about IPSEC. No major agenda item about it in this IETF's meetings, but attendees invited to comment on IPSEC there if needed, or else via the email list.

II. Document Status - Bob Hinden,

- Basic API published as RFC2553.
- Approved for PS by IESG:


IETF Last Call completed for DS:

Addressing Architecture and Aggregatable Global Unicast - the IESG needs reports of experience with scoped multicast forwarding and there is IESG concern about how to standardize architecture docs. Does DS need to wait until a large enough deployment has occurred to indicate how scalable the addresses are? During IETF week, there are some offline discussions related to the 8+8 decision; the IAB workshop on the Network Layer recommended talking about it.

IETF Last Call completed for PS:

Router Renumbering is back at IESG, and they are not waiting for a revision.

DNS extensions - dependent docs have been approved, but the draft is waiting for revisions covering how to handle resolver behavior during the AAAA/A6 transition - an update is on today's agenda.

Multicast Listener Discovery is ready for IESG ballot.

Submitted to IESG for PS:

Router Alert - WG last call finished without comments today, so it will be sent to IESG now.

Submitted to IESG for Informational:

The GSE analysis was at the IESG for a long time. About two weeks ago, the authors received a security review from Steve Bellovin, requested by the IESG. Steve, the authors, some ADs, and Bob Hinden were to meet during Oslo to discuss the review, and there will probably be a document revision.

WG Last Call completed for Informational:

The initial sub-TLA assignments draft was never submitted to IESG because preliminary discussions with the IANA and registry people suggested we wait for action by them. Their action has happened: there will be an announcement at the plenary tonight that the IANA has delegated the first allotments of sub-TLA space to the three registries.

A Method for Flexible Assignment - This draft is close to be ready for submission, but the author has been asked to revise it some to provide more context.

The Case for IPv6 - Some comments are being forwarded to the authors. Note that this document will be sent to IESG as an IAB doc, not IPNGWG.

III. Updates - Matt Crawford, FNAL

DNS Lookups:
IETF Last Call was issued 14 June. Remaining issue is specification of resolver behavior during the aaaa to a6 transition - the straw man proposal for this had very light discussion on the mailing list.

ICMP Name Lookups:

Near ready for WG Last Call - one known issue is that the lookup request hashes the name using a CRC32, noting that this should be fine because it is not a hash for security purposes. Some people have asked that it use an IPSEC hash instead, simply because IPSEC hashes already have been implemented in stack and will not entail extra code. Matt noted finally that there has been no complaint about the draft's specified multicast address.


There are potential interactions between Router Renumbering and mobility: for instance, if you set or clear the R flag in the router advertisement. Question is how to minimize the coupling of the two documents so as not to delay the standards track progress of either one. Hinden commented that RR was further along than IPv6 Mobility, so perhaps the right thing would be for the latter to reference the former. Hinden took an action to ask Thomas Narten for an AD opinion on this, since Thomas was not in the room at that point.

There are similar interactions between RR and the site-prefixes draft.


Itojun asked when A6 will be implemented. Answer: Bind 9 will have it. The last word Matt had was that its ETA is the coming fall, but Matt got that update 3 months ago.

IV. CSI - Hiroshi Kitamura, NEC

The Secretariat republished the original draft as 01 instead of using the updated text. This presentation is an update from his presentation at last IETF.

Connection/Link Status Investigation (CSI) is a traceroute or pathchar type mechanism using one new HBH option and three new ICMPv6 messages -
- CSI HBH option
- ICMPv6 Status Request/Status Reply/Status Report

The basic mechanism is to send a message with a pre-allocated space for each hop to record the requested information in. Scalability of this space is handled by having a node which fills the remaining space send a Status Report back and forward on the Request with the original space now cleared for new information. The CSI option may be disabled by nodes and then they mark a bitmap with 0 in the position of the skipped node. This mechanism is limited to 24 hops. A change between the 00 and 01drafts was to eliminate the version field, and plan on using a new investigation type code when going to a new version of a particular investigation type.

Issues include: which address to record from among all assigned to an interface. The proposal would be to use rules like those for source address selection, keyed to the destination address in the ICMPv6 header.

To economize on the space, there is a mechanism for IP address compression - in a large scale net: record upper part, small scale net: lower part. The speaker did not address how you would determine and specify which compression mode to use.

The speaker stated why CSI can be said to be simple to implement: none of the envisioned investigation type responses have to be rapidly processed in the routers and they do not require intelligence or complexity there - the model is that the data is collected by the requester and analyzed offline.

The speaker has implemented a tool called tracestatus, and suggests it can replace ping and traceroute. The code may be released soon.

Comments -

Comment: It's less simple than traceroute, which requires nothing on routers. It is also not true that you can simplify by saying no security considerations enter into it.

Answer: there are security considerations in draft 01. Answering about traceroute: if the function had been seen as necessary early on in the IPv4 development, then maybe the IPv4 designers would have chosen to create something like CSI, but IPv4 option problems ruled out that thinking later.

Crawford: Note that timestamp definitions within the draft areinconsistent. Asks if it is necessary that this be ICMP? Suggests that the option field might also need to include a Router Alert. Can routers disable some types of data but allow others?

Answer - that can be set as a policy but as currently specified, the replies cannot tell the requester about the specifics.

Durand asks if this is a working group item - Hinden says not sure if WG supports. Similar 1997 proposal by Durand and others did not have working group support. Preference by Hinden now is keep as individual submission until work is more mature. If people disagree with that, say something now. Author is asked to label next draft as individual submission, not draft-ipngwg-hbh-etc..

Haskins - this might belong in operations area.

V. UDP-Lite - Lars-Ake Larzon , Lulea University

The presentation proposed a small change to UDP aimed at realtime applications in error-prone environments. IP in cellular nets experiences errors and delay, and there is an increasing interest in the use of error-tolerant codecs to get tolerable performance for realtime flows. For this, the IP/UDP checksumming is not optimal - UDP will drop damaged packets which the error-tolerant codecs delivered as damaged but usable. And, of course, disabling the UDP checksum with a zero value as in IPv4 is not permitted for IPv6. Transport layer properties wanted for the realtime applications over cell - low complexity for low protocol overhead, checksum coverage of just the protocol headers, allowance of delivery of damaged frames. Proposed solution: UDP's packet length field is redundant because the IP header has it too - so replace it with a field called Checksum Coverage that specifies how much of packet beginning of the UDP header should be covered by the checksum. If checksum coverage is less than packet length then that remaining part of packet will not be checksummed. Examples:

- Voice over IP (VoIP) using IP/UDP/RTP - cover only headers
- VoIP with compressed RTP - with checksum covering only the headers, they have measured that there are 40% fewer context synchronization losses and TWICE will succeed more often. More details on this will be presented to the AVT WG on Thursday.
- 64 kbps PCM audio over cellular - normally cellular would not be used for this voice encoding because of its too limited bandwidth. However, there are tests of using it and recovering from the extensive packet losses. More packets get through when UDP-Lite is used; a clicking sound occurs from data corruption in the packet, which the application can filter out.

One of the arguments for standardizing on UDP-Lite is low deployment cost, because it can look exactly like regular UDP by simply having the full length in the Coverage Field. It could be deployed as a separate protocol parallel to UDP, but the speaker asks consideration for replacing UDP in IPv6 with UDP-Lite, since there has been limited deployment to date.


Hinden: First thought is that UDP is usually considered in transport area. On the other hand, IPNGWG has changed the checksum of TCP/UDP so it's probably OK to consider UDP-Lite here.

Comment: Doesn't this conflict with having underlying protocols that are checksummed themselves, like PPP radio?

Answer: link protocols for IP over cellular are not settled yet, and there is ongoing work on link layers that deliver the damaged frames.

Draves: how does an application ask for less coverage?

Answer: the default behavior is to look like ordinary UDP, and in their implementation, the application uses a socket option to set lesser

Comment: this WG made UDP unsafe for the applications described by requiring the checksum, unlike IPv4, so it is our responsibility to fix the problem. The commenter also agrees that the data link layers haven't been fully defined for newer digital cellular such as UMTS.

Crawford: Though new transport doesn't necessarily belong here, this WG also has worked on jumbograms, and note this would interact with jumbograms.

Hinden: note a new comment on checksum limitations for very large datagrams that the IESG had the authors to that draft.

Speaker: we think being able to specify coverage only as far as 64K would be OK, but also, the semantic of zero in the Coverage field, meaning the entire packet is covered, means you can request coverage of the whole jumbogram.

Hinden took an action to talk to the ADs. He'd lean to making a separate UDP because there have already been investments in UDP as is. Another of the authors of UDP-Lite added as a last word that the changes to UDP are 2 lines of code.

VI. TAHI Project: IPv6 Code Verification - Nobuo Okaba, Yokagawa Electric Corp.

The TAHI project was started in 1998, funded by the Japanese government. Its objectives are conformance and interoperability tests for IPv6, to be made publicly available.

The current coverage is 106 tests for hosts, taking about 6 hours to complete, and 56 for routers taking about 3.5 hours. Unattended operation works fine. Among tests of basic function still to be done are: RS/RA functions of the router and Redirect. The implementations that have been tested so far are Hitachi NR60, various versions of KAME, and some NEC prototype host code. The development plan is to complete the basic spec by 8/99, ICMPv6 by 10/99, IPSEC by 12/99, v6/v4 Tunnel by 12/99, Address Architecture by 12/99.

Testing on the ipv6-unified kernel will be started next month. Test package releases are planned every two months. Results for both KAME and ipv6-unified will be published. Both the test spec and testing code will be published. Plan an interop event in October in Japan. Begin checking the TAHI web site for these various developments in August 1999 - www.tahi.org

Itojun: Can you describe how TAHI is distinguished from UNH.

Answer: a major difference is that all the test programs will be openly available, as will test results such as the ipv6-unified.

Dave Johnson: When will TAHI make tests for mobile IPv6.

Answer: sometime in 2000.

Dave: January looks open.

A demo in the IETF laptop room was available by arrangement. Code to be tested is welcome. One can get in touch using contact@tahi.org or nobuo_okabe@yokogawa.co.jp.

Question: are the tests hand-coded in C or using a specification language? Answer: in C.

VII. IPv6 in GSM-like Infrastructure - Hossam Afifi, INRIA Sophia

The hypothesis of this presentation was that the IP over cell phone standards currently being developed for GSM and its successors could fail to be deployed because of complexity, and, in that circumstance, an IPv6 stack for current GSM could become a viable standard. IPv6 can provide improvement and simplification of GSM networking . Draft-afifi-sixtel-00.txt, by the speaker, Jim Bound and Laurent Toutain is the basis of the talk.

GSM has a few 100 million users today - both voice and data modems. It is a success story like the Internet. There is a standard for data transfer over wireless, GPRS, which is viewed as an extension to GSM. Hypothesis is that it is not successful like GSM. It is currently standardized but not widely deployed. UMTS (3GPP) and IMT2000, representing the next generation, are not yet standardized.

There are two kinds of mobility in GSM, from cell to cell within one switch (MSC) and between MSCs. The Home Database is with your home MSC, and the Visitor Database is updated when you change MSC. The GSM functions are in a Call Management layer, Mobility Management layer, and Radio Resource layer. GPRS does not use this architecture, but has a different fixed database structure. You can have equipment that is GSM only, GPRS only, or both. GPRS has many complex services, including a reliable multicast. Frame Relay is used between base stations and the databases. A slide showed GPRS as having complex protocol stacks in the database (SGSN) and base stations.

A simple way to add IPv6 to cell telephony is just to use Francis Dupont's IPv6-supporting device driver for GSM modems. The accepted view is that IPv6 should be added to the GPRS protocol architecture, but since GPRS is not deployed and is such a mess, the suggestion is to bypass it and architect just for GSM.

The draft covers what was proposed in more detail. Highlights:
- Place an IPv6 Router over an adaptation layer over the stack in the MSC.
- Design the needed adaptation layer in IETF, and go to ETSI to suggest changes as needed to Call Management and Mobility Management.
- The architecture would be one MSC/subnet.
- Some needed additions are header compression and mux/demux.
- Use IPv6 mobility for the inter-MSC mobility.
- Have DHCPv6 give the address to a phone on turn-on and add IPSEC to the Call Management layer.
- Have DHCPv6 and IPv6 interact on the move to a new MSC, with support for this in Mobility Management

The speaker concluded suggesting a poll of whether this proposal is useful, whether to work on it in the WG, and if there would be concurrence about the work suggested to be done in ETSI.

Comments -

Eklund: Much of what they would do is already part of GPRS. For instance, it already includes the ability to choose IPv6 instead of IPv4. The suggestions represent misunderstanding of GPRS. Eklund's opinion is that no operator would adopt this scheme.

Answer: an operator Afifi is working with is unhappy with the prospective performance of GPRS and its complex stack and has expressed interest in bypassing GPRS. Eklund - the cost of building an alternative means that all operators are going to use GPRS. I

Hakkunen: Also thinks the authors misunderstand what is happening in GPRS. GPRS is complex because it needs to be. The end result of the suggested use of GSM would be as complex as GPRS because it would have to be.

Answer: GSM is deployed today. What is the guarantee that GPRS will be deployed? Hakkunen: Cannot speak officially, but there is very high pressure for GPRS deployment, and thinks it will be deployed.

Tsirtsis: This is for a good cause, but you could spend a lot of time trying to get ETSI to change existing standards, or work in the early days of something that isn't hard and fast yet, and the latter would be more effective. So IETF should even go beyond GPRS and be longer term. Suggestion is to go to UMTS instead.

Comment: About the poor performance of GPRS, in normal GSM traffic, the occasional free slots in the TDM timeslotting scheme are retrofitted for GPRS. It performs so badly, because there is little allocation for it yet.

Answer: Another reason why GPRS isn't attractive for the IPv6 over cell.

Hakkunen: Some people are proposing the GPRS stack for UMTS. If IETF could convince UMTS people to use this solution instead, this would be most effective.

Hinden: When I first saw the GPRS stack, I saw it as too complex too. However, it is not certain that this WG can have this work in its charter. Rather, it seems appropriate to ask the Internet ADs about looking at the whole IP over cellular media topic. Hinden took an action to bring it up to the Internet ADs.

Perkins: Timing matters. Make a working group item related to this now would make it more real. Hinden: It's too late to affect GPRS.

Hinden: Suggests this draft remain an individual submission.

VIII. Preferred Format for Literal IPv6 Addresses in URLs - Hinden

The major goal of the format is to make cut and paste of IPv6 literal addresses into browsers easy. The draft is browser focused - there are URLs in a lot of places and it is hard to fix parsing software everywhere. In the draft in its 01 version, the format is to enclose the literal address in square brackets. There have been implementations demonstrating feasibility in MS IE, Mozilla, and Lynx - these are not production implementations, but their coverage is good. Hinden would like to start WG Last Call for this to go to PS, continuing to omit the issue of literal support for non-browser uses of URL. But it is noted that the IPv6 service location protocol drafters may be able to use this too.

Itojun: Is it legal to have a square bracket around a regular URL with FQDN? His implementation accepts finding square brackets there.

Answer: We shouldn't require that it do. Draves: MSRIPv6 IE also accepts square brackets around the FQDN as an implementation byproduct.

Comment: Every example has an explicit :80, why?

Answer: This was just to show there would be no problem between the address use of ':' and the port use of ':'. Examples without the port will be included too. Itojun: please show examples with 3ffe in lower case, not only upper.

Perkins: Service location protocol for IPv6 is done and is just waiting for this format to get settled. They will reference the draft. Narten: SLPv6 is not quite ready, because they need to include rules about server source address use when multihomed - these should be reviewed by IPNGWG. In fact, SLPv6 should become an IPNGWG document, because the SLP working group is trying to shut down.

IX. Privacy Extensions for Stateless Address Autoconfiguration - Narten, IBM

The constancy of the Interface ID could (in some cases) be used for tracking individuals, for instance when the device stays with the user, like a PDA. A server could tell when you were at home, office, travelling, based on the changing prefixes. The proposed extension for privacy is optional because it is not a concern for everyone. In particular, servers already have a permanent DNS name, so that is already an identifier for them. Also, many are used to having a stable IPv4 address, for instance because the DHCP spec encourages giving the same address. Finally, sites may want to be able to track use easily, and having nodes be able to become anonymous would be viewed as a cost to them. Solution requirements:

- Interface identifier must change over time.
- It does not need to be cryptographically random, just unpredictable to an outside observer. If there is stable storage, the draft provides an algorithm for creating a new IID, otherwise it is to be pseudo-randomly generated. The algorithm briefly is to append the IID to a 64-bit history value, compute the MD5 message digest, take the first 64 bits for the temporary IID, use the temporary as the next history value.

Issues -

How frequently to recommend changing? The initial approach is at each restart (system reboot).

An assumption is that this is a client-only solution. A device that's both a server and a client may want to use the constant IID for server use and this stuff for its client communications. Then one has to get into source address selection issues.

Should this be specified as for use in global addresses?

Collision avoidance - in autoconfiguration now, DAD halts the process when a duplicate is discovered. But for privacy IID selection purposes, there should be a retry mechanism.

Is it reasonable to assume that the IEEE identifier will remain private to node? If it is known already, the generation algorithm may be predictable. An observer on the same link will certainly know it. (Comment by someone: this is not for privacy on the same link). The alternative is not to use the constant IID as a seed. Avoiding using it is easy, assuming that systems can be expected to generate a pseudo-random number reasonably well.

Comments -

Crawford: Let people choose their own threat model and decide for themselves how often to take a dose of this privacy drug. On the other hand, when restart-based model is not used, some more problems arise: on changing IID without a restart, the system has to track addresses in use already, in open connections, and unlike prefix-changing, it does not get external cues (router advertisements) to start doing so.

Perkins: Wonders why it is believed that the history list is simpler than trying to do a new random number each time. No need to overspecify: a default method for generating the privacy IID is not needed for interoperation. Also, with respect to the analogy to prefix-changing, note that address lifetimes are upper bounds - the system is free to stop using some prefix when it wants to. Answer: It may be hard to track upper layer users of addresses with the defunct IID, especially UDP.

Afifi: For this to work, DHCP servers would need modifications, because clients are identified by their MAC addresses. Answer: If you are using DHCP, you have to generate a normal link-layer address, not use an anonymized one.

Nordmark: Is it a privacy concern that DHCP servers know the constant IIDs of systems? Answer: DHCP is supposed to be trusted. Hinden: You may not trust a DHCP server you are visiting.

Hinden: The draft will need revision.

Narten: Could the WG comment on whether the simple first cut in the draft is enough.

Draves: Would like to see it include reboot-less change that can be done more frequently. Others nod.

Ahltorp: Who will get to use the IID when a duplicate is found?

Answer: The original owner. Unlike with ARP, there is no problem that the cache could be corrupted.

Question: But if it's a duplicate of a system that is temporarily down, especially of a server that cannot change?

Answer: This case is okay, because the server should using an IID with the global-bit. Still, partition could cause problems for the DAD/retry.

Comment: Make the random generation a good function, likelihood of collision low.

Itojun: Definitely agrees that the frequency of change should be a choice of user. It's fine to change at reboot time, but give warnings about issues in reboot-less change.

Comment: There is another case for needing to use both modes of address simultaneously. Many client-only systems will have to keep a stable address for the backward translation of name required by some servers (some telnetd's, smtpd's) and choose to use the private address only for applications without this constraint.

Answer: The draft doesn't go into this case, because it is a bit of a rathole. For instance, how will applications decide?

Draves: Have stable address be deprecated and private preferred?

Answer: That doesn't help for the client-only two-mode case.

Draves: It does help for server/client on one system case.

Comment: It may be that DHCP must give out the private addresses because people are manually configuring addresses with the low-numbered IIDs such as ::1. It would be bad if there are collisions for those. They have local-bit set to true, so they are in same space as the generated private IIDs.

Narten: Note that in the draft, the last thing that is done is to set the bit to local.

Nordmark: DHCP also sets the bit to local, so there is the prospect of collision with DHCP-assigned addresses. Given the amount of space, it is not such a big collision risk, but maybe further structuring of the addresses could be considered.

Answer: could consider getting an EUI prefix for these...

X. Update to Advanced API - Erik Nordmark, Sun

Since the time of the LA IETF, implementors have found it too complex, so the update simplifies it by providing less flexibility. A goal is to allow implementations to support both the old API (RFC2292) and this new API. The high order bits of changes between the RFC and this draft are summarized here:

- Biggest change was to remove IPV6_PKTOPTIONS feature that set many options by recursion - it was not possible to know the behavior if one of many being set failed - did the others take effect anyway? Sticky options can now be set with individual setsockopt calls.
- Added IPV6_RTHDRDSTOPTS to control DSTOPTS that show up before routing header, since can no longer control that with omnibus of IPV6_PKTOPTIONS.
- Removed the ability to be able to specify HBH and DSTOPTS with multiple ancillary data items. Now application is responsible for formatting the whole extension header, so protocol stack does not have to guess the alignment restrictions etc.
- Added separate IPV6_RECVxxx options to enable the receipt of the corresponding ancillary data items. Now the applications uses getsockopt to retrieve any sticky options it has set with setsockopt.
- Clarified how and when TCP returns ancillary data items - it must when the content changes from one segment to another, but not necessarily on each data receive when the content does not change.

These are not all the changes - see list in draft. Some TODO items are still extant:

- Add mechanism to avoid fragmentation by sending at the minimum IPv6 MTU, for instance, this would be useful for a DNS server that does not want to do Path MTU discovery for a single reply.
- Add MTU notification so that UDP apps can participate in PMTU discovery. This could be an ancillary data items received without any data, IPV6_PATHMTU, enabled with IPV6_RECV_PATHMTU.
- Add reachability confirmation for UDP and raw socket apps to allow them to talk to Neighbor Discovery to defer NUD probes. This could be an ancillary data item for sendmsg with zero length called IPV6_REACHCONF.

Due to shortage of time, the meeting was advised to look in the draft for the list of open issues. Implementors need to inspect this draft carefully. Is anything missing? The authors wants to do one more crank on it and then be done.

Itojun: It is actually desirable that 2292 and 2292bis both be supported? If so, 2292bis should have words saying it is an addition.

Answer: Do people need backward compatibility? Please speak up. The actual preference is that 2292bis should obsolete 2292, but it depends on the state of implementations.

XI. Site Prefixes in Neighbor Discovery - Erik Nordmark, Sun

Brief summary of the spec -

Store site-local address in the DNS
- RRset contains just site-locals if not connected, site-locals and globals if connected.

Routers advertise the global prefixes for the site, typically as a/48 in the RA prefix options

The resolver/getipnodebyname() filters the RRset
- Test: one or more global addresses falls in site prefix
- Exclude site-locals if not true

The draft is 03. Changes since previous draft include: format change in option to make better fit with Router Renumbering; change the rules about suppressing global addresses returned from DNS to suppress only those that match the global prefixes received from the RAs; refine the text to handle case when DNS has only site-local addresses in it (in a non-connected site). Defined multi-sited nodes (with a single domain name) and tried to flesh out options in this case; specified that multi-sited nodes can use the site-local listings of only one site - a multihomed node must have a different domain name for each site if it wants to use site-local addresses in all its sites. For more additions and details, see the draft. There was a shortage of time for the presentation.

The text was changed to reference AAAA/A6 instead of AAAA. But should it refer just to A6?

Open issue - should the protocol advertise a human-readable name for each site? Deering has suggested this for multicast scopes in the past, as something useful for application user interfaces. (For instance, a user could be asked whether she wanted campus or office). It would be possible to add an ND option for the human-readable site name.

Next steps: Get the basic rule (that all implementations, including those that do not implement ND site-local extensions, ignore site-locals received in the DNS RRset) into the implementations. The presentation ran out of time as the meeting time ended, so the request was made that discussion start on the mailing list about what the progress should be for this draft.

Thursday, July 15

Hinden announced (following from an announcement by Mike Roberts, temporary president of ICANN, at the IETF plenary the night before) that IANA has officially made the first delegation of IPv6 sub-TLAs to the Regional Internet Registries - we're not done, but this is another important step.

The second session of IPNGWG was dedicated to multihoming. There was one item left over from the first session agenda, to be covered very quickly:

XII. IPv6 Inverse Neighbor Discovery - Thomas Narten, IBM

This is a document by Alex Conta that started in the ION WG. The IESG thought it needed more work after ION sent it to them following their WG last call. It was specified as a Frame Relay-related standard , but Narten pointed out that the Inverse ND is more general than its FR application, so Alex moved the FR-specific stuff into an Appendix, leaving the generic ND material in the main text The WG is requested to comments on it to Alex as soon as possible and an IPNGWG Last Call is requested to take place a few weeks following Oslo.

Multihoming Agenda

XIII. Overview of IP(v6) Multihoming Issues- Deering, presented by Rich Draves, Microsoft Research

The agenda and starting points for this WG discussion were developed by a small design team put together by the WG chairs, which met or teleconferenced several times in June. It was emphasized that the design team results have no special status, but just were to serve as starting point for WG discussion

Multihoming issues arise:
- Node
- Site

There are pretty close analogies between the node and site cases.

Note multihoming is dynamic - hosts, sites can acquire or lose addresses - can be multihomed for an interval.

Multihoming issues are not new with IPv6, but the host ones are more prevalent or maybe more of an issue with IPv6 because of its support for multiple addresses per interface, for multiple scopes, for renumbering, and for transition scenarios introducing new interfaces, such as 6to4. Sites are equally likely to be multihomed in IPv4 or v6, but IPv6 may introduce the situation that sites are to get/use a different prefix with each ISP, rather than punching holes.

Issues of -

- Multiple Addresses for a Node: choice of source address, apps that use addresses as peer identifiers.
- Multiple Interfaces for a Node: same issues, plus others such as that redirect only works if the sender uses the addresses of the outgoing and not those of other interfaces. Load-sharing across interfaces becomes possible, may or may not be desired.
- Multiple Prefixes for a Site: policy-based preferences for using one prefix or not.
- Multiple Attachment Points for a Site: will need to use right attachment - some of this is the domain of routing protocols, but not entirely. Load-sharing may be desired. How to receive packets for prefix of one attachment when it is down, but another is up. If ISP is doing ingress filtering, definitely need to choose prefix for source address that matches attachment being used.

This is an incomplete list of the many issues. Not all of these need to be resolved by the WG now, as we have lived with them in IPv4 for a long time. Figure out the key ones.

Generalized Host Multihoming -

Hosts may have multiple local addresses (LA) and local interfaces (LI), and hosts may peer with multiple remote addresses (RA).

For each triple <LA, LI, RA> chooses a particular path. There's a range of possible capabilities:
- At session initiation time, for instance, TCP connect, choose the triple most likely to work (e.g. longest prefix match)
- Try multiple triples/paths till one works
- Iterate them over multiple sessions
- Try them all and measure somehow which one is best
- Keep history/experience
- For an ongoing session, detect failure of current path and move
- For an ongoing session, detect availability of a better path and move
- Spread session traffic across multiple paths

Later presentations will go into detail of proposed solutions chosen from above space.

Different Models for Multiple Interface

These were discussed as outgoing, but each has a version for incoming too:
- Strong: the source address MUST belong to the originating interface
- Semi-strong: the source address SHOULD belong to the originating interface
- Weak: the source address MAY belong to any interface of the originating host

Another take on these models is to consider whether the stack can choose the interface to use freely or not, when the application has picked the interface it wants to use.

Advantages of Different Models

The weak model has is simpler to implement because you go into the routing table and just get whatever match to the destination address is found. The strong model requires constraining what you can take from routing table. In IPv6, implementations already have this problem/ feature of routing-table lookup to some extent because of the presence of scoped addresses, so the semi-strong model looks promising intrinsically.

Additional Near-Term Point
- Consider using RFC 2260 - see Itojun's presentation to follow this.

IPv6 Features for (Future) Use in Resolving Multihoming Issues
- Globally-unique Node ID - e.g. when the interface ID is autoconfigured using an Ethernet MAC address, with bit indicating it is globally unique. The bit was added to the IID field to give potential for future transports to use the IID alone for transport control block lookup.
- Router Renumbering - border routers can feed prefixes to the routers within the site, and it could be used to control what prefixes are used.
- Use of Site-Local Addresses - to give intra-site communications immunity from external multihoming effects.
- Exchange-based Addressing - assign a single TLA to a set of interconnected ISPs, and do flat routing among customers of exchange. Pros: multihomed sites can have a single prefix across their multiple attachments; also, sites avoid renumbering when they change ISPs. The standard IPv6 address architecture has the capability of doing this.


Do a few simple things now. Keep the WG focus on:
- Heuristics for source and destination address selection
- Some aspects of trying multiple paths
- RFC 2260

And provide a host architecture that can evolve to support better multihoming support in the future.

Multihoming will continue to be a rich source of problems. This presentation and the next two presentations are meant to be one group's contribution to the WG discussion.

Comments -

Perkins: Multihoming issues have come up in mobility. IPv6 must decide whether use careof or home address. Some Stanford University work developed the concept of a mobility address policy table, which seems as if it would be generalizable. How the table was populated was for future study. A pointer was sent to the mailing list.

Hinden: From some points of view, mobility is another class of solutions for multihoming. Perkins: People should consider Erik Nordmark's presentation to mobility WG with implicit tunnels.

Narten: But note the main focus of the ideas from our design team is not what happens when connection is already up and something happens, but rather what happens at the outset of connections.

XIV. Multihoming: RFC2260 Approach - Jun-ichiro Hagino (Itojun), Research Laboratory, Internet Initiative Japan

Focus is on multihoming support that is possible now. This talk covers the router stuff: Goal is to try to deliver packets of any (source, destination) during failure of one or more of the site exit links

IPv4 uses portable addresses so that prefixes of one provider can be advertised out of another provider's attachment point. In IPv6, the portable address concept is not there, and advertisements should be more restricted.

The next talk by Rich Draves will be about end2end stuff: Goal is to try to find the best (source, destination) on connection establishment, and perhaps in more advanced phases, to switch to a better (source, destination) during the course of a connection.


One of the approaches in RFC2260 guarantees no extra routing announcement to outside and is friendly with IPv6 aggregation policy. Sites get ISP-provided addresses from multiple ISPs and are assumed to route them locally. For IPv4, the assumption is that a site has a region for each ISP's addresses, and routing exchange within the site for communication without going outside. IPv6 is different in making it easy for every end host to get addresses from each of the ISPs if that is desired.

Let there be a site with a blue ISP and a red ISP, with the red site border router advertising the red prefix into the red ISP and the blue site border router advertising blue prefix into the blue ISP. and the internal routing stated above. Next: establish an IP in IP tunnel from the blue site border router to the red ISP border router and vice versa. In the stable state: announce the blue prefix from the red-to-blue tunnel endpoint in the blue ISP router. When the blue-blue link fails, so that the stronger route advertising the blue prefix into the blue ISP has failed, only then will the tunnel backup route be used and the blue prefix traffic will tunnel to and from the red site border router. There will be no advertisement of the blue prefix by the red ISP, so aggregation is not broken.

IPv6 Extensions of RFC 2260 -
- Address assignment: the two (or more) ISP prefixes could be assigned in separate regions of the site, as in IPv4, or throughout the site, or a combination of some mixed regions and other distinct regions.
- Packets can survives ISP filters - use RFC2260 in reverse direction and site router tunnels the packet (source routing might be needed?).

Scalability in a Very Large Site -

Do not try to make a full-mesh configuration of tunnels, because it's too much mess. In an example where it's easy to see the suitable partial mesh: the two ISPs of the site portion located in Japan back each other up, the two ISPs of the site portion located in the US back each other up, but there is no backup between the countries.

Conclusions -

RFC 2260 is a good base for IPv6 multihoming - it is aggregation-friendly and does not encourage use of portable addresses.

It is an operational solution - no change to protocol code.

Will ISPs be able to do 2260? Some BGP gurus in Japan have said they find it feasible.

Scalability - guideline document needed.

Note - Dupont draft talking about RFC 2260 should be reviewed.

Comments -

Dupont: About 2260 in general, it is complex to set it up, and it is hard to find the expertise for running it. Many ISP policies are prohibitive of it. Finally, it does not help at all if the provider border router goes down, only if the link goes down. So 2260 is more than nothing, but not very capable.

Itojun will try in his home. Mankin: we should set up some trials on the 6bone.

Hinden: This is one tool for multihoming, but not a complete handling of the issues. Note that link failures are more common that router failures. Dupont: in the context where the exit router on the site is the ISP border router (belongs to the ISP), then a link failure amounts to an ISP router failure and is not cured by 2260.

Nordmark: What about the potential for distributing the injected route with IBGP as in 2260?

Comment: One could have a concern with AS number space consumption being increased by multihoming and 2260 does not help with that.

Itojun: It would be possible to do something with another routing protocol than BGP.

Tsirtsis: It sounds good to combine 2260 with router renumbering as the earlier presentation said, so that when the link fails (or the router fails), nodes are told to change prefix.

Itojun: Still RFC 2260 is a good starting point

XV. Design Team's Proposal for IPv6 Multihoming - Rich Draves, Microsoft Research

Goals -
Support multihomed sites
- Remove temptation to break the provider addressing plan and aggregation - more scalable routing is something IPv6 has to come through with.
- Site availability is a key requirement.
- Maintaining existing connections is a bonus, but not crucial - making sure new connections can be established goes very far. Business-critical apps are designed to be able to restart after a broken connection and otherwise recover if TCP breaks.
- Helping multihomed hosts deal is also a bonus, but is not as critical an issue as making multihomed sites work properly.

Changes should be kept minimal changes - not rock boat
- No protocol changes
- No TCP/UDP implementation changes
- No API changes
- No application changes.

Ideally nobody would have to do anything and we'll fix these issues :) Finally an evolvable solution is needed.

Grand Outline

Phase 1 - required work for WG
- RFC2260 approach
- Source address selection
- Destination address ordering

Phase 1.5 - is this required?
- TCP tries multiple source addresses

Phase 2 - future work?
- Additional APIs, e.g. connect to a DNS name
- Centralize destination/source address selection (DNS...)

Phase 3 - definitely in future
- Adjusting paths after probing

Phase 1 - Required Work on Source Address Selection
Using longest-matching prefix.
Getipnodebyname - ordering of destination addresses returned by DNS leads to source address selection in IPv6 stack.

Pluses, Minuses, Questions:
- Minimal changes
- Scope/prefix matching - local, site, both of you have addresses from ISP A.

? Incorporate TCP feedback - to influence future decisions.

- Does not try all pairs - for each destination, will only choose one column
- Apps are responsible for any probing of the multiple destination addresses - some already do, but most don't
- Another drawback is the need for feedback from the application to know when communication is successful, so a UDP without feedback can't tell you an address is ok

? Big timeouts during trying list
? Because of having decentralized the source/address selection, it is harder for administrators to insert their own controls

Why Not Just Use RFC2260?
- It doesn't help you find common scope/prefix
- It doesn't help multihomed hosts, whereas the above architecture does help some
- It doesn't deal with ISP/router failures, just ISP/link failure
- Using a tunnel is inefficient
- ISPs are willing? As far the design team could find out (admittedly not having searched exhaustively), none have implemented or tried using RFC2260. It is an extra burden. And why should an ISP help you to use another ISP?

Why Not Use Address Selection/Ordering Only and Not RFC2260? Consider:
- Site 1 connected to ISP A and ISP B, Site 2 only connected to ISP A
- Site 1 has node with address 1a, 1b, Site 2 has node with address 2a
- Site 1 will want to use 1a to talk to Site 2. If the link between
- Site 1 and ISP A fails, then when it uses ISP B to initiate a TCP connection to Site 2, it fails.

Question -
Zill: Why not use routing headers? Answer: The team thought about doing so and it has possibilities. The use of router renumbering cited by Dupont and others also has possibilities.

Phase 1.5 - is it required?
TCP tries multiple source addresses - it would be necessary to work out the details.
It would be an implementation change, not a change to the protocol.
RFC2260 would not be needed for basic availability.
All destination/source address pairs would get tried, but there would be a tendency for them to be tried in the wrong order because connect would choose one at a time of one's own interface prefixes at a time - trying <1a-2a> <1a-2b> instead of <1a-2a> <1b-2b>.

Comments -
Dupont: You could fix this with a new ICMP message to say change source address. Answer: This would require more work from the router, having to look at the source addresses being used - team talked about it, but...
Crawford: It wouldn't work for this case anyway.

Phase 2 - Future Work?
Stack maintains host cache database
DNS-based API
- TCP: connect (DNS-name)
- UDP: connect (DNS-name) - this would return to the applications a sorted list of destination/source pairs
- UDP/etc: Would need an API addition to do update-database. This is because the stack can't tell if communications are working (even the app may not know). This is why the UDP:connect gives the application back a list of address pairs.

Phase 3 - Definitely Future Work
- Builds on the host cache database
- Modify TCP for survivability, renumbering - security?
- NUD-like probing for best destination/source pair - would have to control the overhead and load on this? An application could be willing to pay with some extra packets for large gain of a better path.

Phase 1 Detailing: Source Address Selection
Draft - 01
- Only applies when application has not specified source address
- Define candidate set of source addresses, define pair-wise source address comparison
- Always attempts communication using some source address - an alternative philosophy would be to fail in some cases, e.g. your peer has a global address but you have no global source address available. Philosophy in draft is to try anyway, because it might work and if so, it's better than nothing. Cases when you don't have appropriate scope address are probably due to misconfiguration. To fix the problem, administrator may need to be able use the communication.

Nordmark: You can make the case especially in multicast, because peers may actually be on your link, and you have no way to know.
Answer: This can be true in unicast too, for instance, you may have only a global for someone on your link. Nordmark: unlike in the multicast case, that can only be due to misconfiguration.

Candidate Source Address Set
- Do routing lookup, take all addresses of interface - RECOMMEND just using addresses assigned to outgoing interface, but permit use of addresses assigned to other interfaces (depending on the kind of peer
- when talking to a routing peer, you MUST use an address belonging to the interface).

Question to WG - Under what circumstances (if any) should we allow use of addresses not assigned to the sending interface? Maybe if all prefixes on the sending interface are deprecated?

Source Address Comparison
- Series of tie-breakers: scope, preferred/deprecated, longest-matching-prefix
- Scenario A. Global destination address - pick from 1. link-local source address or 2. deprecated global source address...
- Scenario B. Site-local destination address - pick from 1. deprecated site-local source address or 2. preferred global source address.
- Answers in draft now A.2, B.2
- Deering and Hinden school of thought is never to use a deprecated source address if you have any alternative. A answer would be 1. Hinden: Rationale is that site-local meant you were not supposed to communicate outside your site or else there was an error so that you didn't get your new global prefix. If you start the connection with the deprecated address, the site administrators won't find out about the mistake quickly. Draves: That's one school of thought. The alternative view is that the administrator who made the mistake may need ability to use the deprecated to be able to fix the screw-up.
- Hinden: let those administrators use a telnet that allows you to pick your choice of source address including breaking these rules.
- Elz: Don't forget these rules are only deals for when the application doesn't choose its own source address. You need some apps to be able to do this.

Destination Address Ordering

No draft yet
- Try address with smallest scope first.
- Try addresses that have longest possible match with a potential source address, if there is a choice within scope.
- Don't unnecessarily perturb the DNS order. If you imagine this as a sort, you want it to be like a stable sort, so if you have a tie, you don't change the order.
- Avoid extra system calls in the common case, cache in system library, so as not to have multiple calls down into stack for all those addresses.

Discussion of scopes and destination address choice

Elz: going to write a draft where DNS only returns highest scope and nodes when they connect algorithmically create smaller scope to use. If packet gets through and you have a site-local response back, then change to site-local. You can do this independent of what application requests.

Draves: Some dangers, including that it would add latency.

Elz: Would only add small amount if site is not too big a thing.

Nordmark: Version 00 of the site-local draft had something like this, but it provides less administrative control, for instance you don't have option of leaving out the site-local address entries from the DNS for nodes you know are frequently mobile. You might want to have that admin control.

Elz: Mobile IPv6 has arranged for site-local addresses to work. Anyway, will write up his draft.

The Grand Outline discussion was consensus of the design team - Phase 1 solves the most pressing problems.

Discussion -

Dupont: TCP survivability/renumbering is entirely solved by mobility mechanisms.

Narten: Have to disagree, because with mobility, you know when you've moved, but when a link goes down, or something other than router advertisements cause a new prefix to be needed, it is not as clearcut for the sender to know. The change is harder.

Dupont: Have implemented it. It works.

Carpenter: Change term renumbering to something like prefix migration - your home address is what's going to disappear at the end of the prefix migration.

Nordmark: If we'd have done Phase 2 two years ago, it would have been phased in with the new API, but there are perhaps enough people porting applications now, that the Phase 2 API could not be included in some implementations. miss some.

Hinden: This isn't an advanced API, it's more basic than basic.

Itojun: There are already many applications using the basic API, so please don't drop it.

Cheshire - MacOS connects using DNS names and it works fine - AF-DNS family name

Carpenter: It would be nice because it's a fairly concrete interpretation of having APIs with a level of abstraction from network layer. Good news because architecture justified, bad news if it carried along some delay.

Hinden: It might be good that we don't standardize APIs.

Status -
The source address selection draft is out there for working group review.

XVI. Next Steps / Bob Hinden

Hinden summarized the discussion to focus on some next steps/actions.

No voices said not to do Phase 1 - so the next step is either to add
to the source selection document to include destination ordering as
well, or make a new document for it.

Action - Continue source/destination selection draft(s).

Heard fairly strongly that there is value in doing Phase 2 - the
DNS-based API part. We could do something very simple and use it to
get experience. This doesn't break any existing applications and not
all applications have been ported to IPv6. Also we would hope IPv6
encourages some new applications, so even if the all ports are done,
here are new users of APIs to come.

Action - Start Simple IPv6 API

Crawford: An addition to this would be to use SRV records to find out
the ports too. Some negative responses to this from the room.

Action on 2260 - Next step is to have serious conversations with ISPs
and routing experts - maybe there are serious reasons on their part
not using it. To the design team's not very broad knowledge, it has
not been implemented.

Elz: Note the two ways to talk to ISP: saying something would be
technically nice to do versus saying there are tens of millions in it
for them if they do it. Provided a few well-heeled subscribers demand
RFC 2260, it will be thereafter be provided everyone.

Nordmark: ISPs often don't like tunnels because of issues with
transit or non-transit. They are known not to like 6bone tunnels.

Action - Investigate RFC2260
- Get more ISP opinions
- Consult routing experts
- Conduct 6bone tests

Carpenter: Randy Bush said RFC 2260 has not been used in IPv4 because
it is too complex. This could be a chicken-and-egg problem.

Hinden: Things do change, this is the Internet after all

Shand: Did a draft on this sort of topic 3-4 years ago. He will look
and see if it has any interesting ideas to revive.

Dupont: A lengthy draft on this stuff was just revived by NGTRANS. It
should be moved to IPNGWG.

XVII. Interim Meeting

It would be useful to have an interim meeting focused on multihoming. When - last week in September is one thought of chairs. A question is whether it would be good to have it adjacent to an IPv6 Forum meeting?

Carpenter: Consider whether or not to broaden scope to prefix migration (renumbering) in general - got clear message from ISPs in context of last week's workshop.

Hinden: good idea. Others concur.

Carpenter: Prefix migration was Mike O'Dell's phrase, by the way.

Fink: Adjacency to IPv6 Forum meeting does not have strong value to our community.

Blanchet: First one is just between NANOG and Internet2 members' meeting anyway.

Nordmark: How many went to IPv6 Forum meetings this week?

Hinden: They were for limited invitees, and not advertised.

Hinden: Please send a message to chairs if you can host the interim meeting and when you can host it.

Fink: Suggest not broaden scope too much, e.g. to include an NGTRANS meeting, because this would dilute the ability to get things done. Looking at some of the transition mechanisms, it may prove a good idea to have interim specific narrow micro-working groups for making NGTRANS progress.


None received.