2.3.6 IPNG (ipngwg)

NOTE: This charter is a snapshot of the 44th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 11-Jan-99


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

Internet Area Director(s):

Jeffrey Burgan <burgan@corp.home.net>
Thomas Narten <narten@raleigh.ibm.com>

Internet Area Advisor:

Jeffrey Burgan <burgan@corp.home.net>

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



Basic Socket Interface Extensions for 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

Current Meeting Report

IPng Meeting
Minneapolis IETF
March 15, 1999

Robert Hinden / Nokia
Steve Deering / Cisco
IPng w.g. Co-Chairs

Minutes taken and edited by Robert Hinden.

Introduction / S. Deering (5 min)

Steve Deering introduced the meeting and passed out the rosters.
Working group meet for two sessions:

MONDAY, March 15, 1999 0930-1130 (Salon D)
MONDAY, March 15, 1999 1930-2200 (Salon D)

Approximately 200 people attended.

Review Agenda / S. Deering (5 min)

- Introduction / S. Deering (5 min)
- Review Agenda / S. Deering (5 min)
- New Internet Draft Procedure / R. Hinden (5 min)
- Current Deployment Activities / P. Metzger (10 min)
- UNH Interoperability Testing / W. Lenharth (5 min)
- 6REN Status / R. Fink (5 min)
- Document Status / R. Hinden (15 min)
- Report from IPng Grenoble Meeting / S. Deering (45 min)
- Chairs' Recommendation on IPng w.g. / S. Deering, R. Hinden (15 min)
- Mobile IPv6 Status / D. Johnson (5 min)
- DNS Extension Status / M. Crawford (5 min)
- Router Renumbering Status / M. Crawford (5 min)
- Multicast Listener Discovery Protocol / S. Deering (5 min)
- Tunnel Broker Terminology & Concepts / A. Durand (5 min)
- Tunnel Broker / I. Guardini (10 min)
- Connection/Link Status Investigation (CSI) for IPv6 / H. Kitamura (10 min)
- Node Information Query / Matt Crawford
- Generic Address Mapping / A. Durand (15 min)
- Steal This Slide / M. Crawford (10 min)
- ND Extensions for Frame Relay / A. Conta (15 min)
- Using E.164 Telephone numbers as IPv6 addresses / H. Afifi (10 min)
- GateD IPv6 Status / W. Siadak
- Current State of IPng Multihoming / S. Deering (30 min)

New Internet Draft Procedure / R. Hinden

The IESG announced the following procedure for all Internet Drafts:

"All Internet-Drafts must begin with ONE of the following three statements:

- This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026.
- This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 except for the right to produce derivative works.
- This document is an Internet-Draft and is NOT offered in accordance with Section 10 of RFC2026, and will only exist as an Internet-Draft.

Any submission which does not include one (and only one) of the above three statements will be returned to the submitter. The IETF Secretariat will NOT add this text."

IPng Procedure

The IPng w.g. chairs require anyone considering the submission an IPng Internet Draft (i.e. draft-ietf-ipngwg-xxxx) that does not include the first statement obtain permission from the chairs prior to publication

Without the first statement is not possible to consider the draft for entry into the standards process.

Current Deployment Activities / P. Metzger

Perry Metzger could not attend. Report from floor that new web site is up at http://ipv6.org

UNH Interoperability Testing / W. Lenharth

Testing last week at Connectathoen. Tested w/ three companies.

Next event will be week before November IETF. Have added new items to test suite, more ND, Mobile IPv6, and plan to add OSPFv6 to test suite. See http://www.iol.unh.edu for more information.

Question about if other vendors use lab. outside of test period? Yes, many of the vendors have the lab do testing outside of the public test periods.

6REN Status / R. Fink

The 6REN
- ESnet has established an open participation initiative, the 6REN
- it will act as an IPv6 rallying point for all Research & Education Networks world-wide (and any others that want to join)
- thus enabling production IPv6 services worldwide

Isn't this just the 6bone?
- The 6bone is a testbed network coordinated by the IETF NGTRANS WG
- Production quality portions of the 6bone will be a part of the 6REN
- The 6REN will promote and coordinate production quality IPv6 service
- The 6REN is NOT a network, it's an initiative to create production ipv6 networks

6REN participation
- Free and open to all Research and Education Networks that provide production IPv6 service
- Other for-profit and not-for-profit IPv6 networks are also encouraged to participate on this basis as well
- you only need a willingness to join in helping create production quality IPv6 networks

Current 6REN Participants



Canarie (CA)

Renater/G6 (FR)

Chungwa (TW)

Sprint (US)

Esnet (US)

SURFnet (NL)

Internet2 (US)


IPFnet (DE)


MCI/vBNS & NGnet (US)

AARnet (AU)*

(*soon we hope!)

Work underway
- Existing 6bone backbone networks are being approached to find out who can participate in this effort (this includes Sprint and NTT, so it's not just RENs)
- Effort underway to help currently non-IPv6 experienced RENs to develop plans and proposals to provide production IPv6 service

More work
- Native IPv6 peering points are being developed at:
- the StarTAP in Chicago, called the 6TAP (jointly planned, developed and operated by Canarie and ESnet)
- the Amsterdam exchange, called the AMS-IX (jointly developed by various NL organizations)
- Planning underway to coordinate these and other IPv6 exchange efforts

More work
- Qwest is providing RIPE-style registry service similar to that provided for the 6bone (courtesy of David Kessens)
- Reverse DNS (ip6.int) registry will be provided through ISI, under IANA oversight, as done now for the 6bone
- ESnet will provide transit to all 6bone participants (for all 6ren participants) to be sure no connectivity is lost to parts of the 6bone that are less reliable

- Convert the early participants to production IPv6 addresses as soon as the registries start handing out Sub-TLAs early next year
- Or continue the use of 6bone testbed addressing where appropriate
- Work on making these networks provide production quality IPv6 service

- The top down push to get site networks to put IPv6 into use
- The environment and motivation to run existing and new Internet applications over a native IPv6 infrastructure
- To guarantee that transitioning from IPv4 to IPv6 is transparent as possible
- Early operational experience and conventions for running IPv6 production networks

Join the 6REN Initiative
- See the new web site for the 6REN: http://6ren.net
- Contact Bob Fink if you have any questions: fink@es.net

Document Status / R. Hinden

Document Status
- RFC Published
- RFC2497 A Method for the Transmission of IPv6 Packets over ARCnet Networks (PS)
- RFC2507 IP Header Compression (PS)
- RFC2526 Reserved IPv6 Subnet Anycast Addresses (PS)
- RFC2529 Transmission of IPv6 Packet over IPv4 Domains without Explicit Tunnels (PS)
- IESG Approved
- Basic Socket Interface Extensions for IPv6 (Informational)

Document Status
- IETF Last Call completed for Draft Standard
- RFC2372 IP Version 6 Addressing Architecture
- RFC22374 An IPv6 Aggregatable Global Unicast Address Format
- IESG want experience w/ scoped multicast forwarding and other IESG issues?
- IETF Last Call completed for Proposed Standard
- Router Renumbering for IPv6
- IESG Comments
- New draft ready for Last Call
- Submitted to IESG for Proposed Standard
- IPv6 Router Alert Option
- IESG wants to reconcile w/ IPv4 Router Alert
- AD has the action item to ensure that spec for IPv6 Router Alert is up-to-date, and that reasons for difference from IPv4 Router Alert are documented.
- DNS Extensions to Support IP Version 6
- IESG issues?
- There will be discussions at the IETF meeting to better understand issues and if required update drafts. Result will be reported to the w.g. mailing list.

ACTION: Document editor to contact implementors to document scoped multicast forwarding multicast.

ACTION: AD is check that current specification up to date and documents why IPv6 Router Alert is different from IPv4 Router Alert.

ACTION: "DNS Extension for IP Version 6" document authors to send email to w.g. list to with resolution of issues.

Document Status
- Submitted to IESG for Informational
- Separating Identifiers and Locators in Addresses: An Analysis of the GSE Proposal for IPv6
- AD reported that the IESG hasn't gotten to it yet; no known objections at this point.
- IPng Working Group Last Call Completed for Proposed Standard
- IPv6 Jumbo Payload Option
- Decision to combine w/ TCP/UDP Jumbograms specification.
- Next step is to do an w.g. last call.
- IPng Working Group Last Call Completed for Informational
- Initial IPv6 Sub-TLA ID Assignments
- IESG asked to delay
- IPng Working Group Last Call Completed for Experimental
- IPv6 Name Lookups Through ICMP
- Renamed to be "IPv6 Node Information Queries", see below.

- Ready for Working Group Last Call?
- IPv6 Jumbograms (PS)
- A Method for flexible IPv6 Address Assignment (Informational)
- Multicast Listener Discovery (MLD) for IPv6 (PS)
- IPv6 Node Information Queries (Experimental)
- Author will update draft and combine with related draft by A. Durand.
- IAB: The Case for IPv6 (Informational)
- Do an unofficial w.g. last call

ACTION: Document editor to start an IPng w.g. last call for "IPv6 Jumbograms" for Proposed Standard.

ACTION: Document editor to start an IPng w.g. last call for "A Method for flexible IPv6 Address Assignment" for Informational.

ACTION: Document editor to start an IPng w.g. last call for "Multicast Listener Discovery (MLD) for IPv6" for Proposed Standard.

ACTION: Document editor to start an unofficial IPng w.g. last call for the "The Case for IPv6" for Informational.

Report from IPng Grenoble Meeting / S. Deering

IPng WG Wrap-Up Session
February 4, 1999

WG Docs to Finish Up
- MLD [done?]
- ICMP revision
- scope-exceeded err, no err to redirect, editorial
- advanced API
- router renumbering [done?]
- merged jumbogram specs [done?]
- generic tunneling (add bidirectional tunnels)

Unfinished IPng WG work
- flow label standardization (no action now)
- scope issues, source address selection
- multihomed host/site issues
- autoconfig <-> DNS <-> mobileip story [Apparently already under control in other WGs; move this to "other WG prodding" category]
- dial-up issues? [e.g., WIDE proposal for prefix assignment on PPP connection establishment]
- [IPv6 literal addresses in URLs, etc.]

Comment that there is a missing piece in Autoconfig/MobileIP. We don't know how to do secure/authenticated plug and play. Someone needs to put the whole picture together.

New IPng WG tasks
- specify transient interface IDs for privacy concerns
- specify E.164-in-IPv6 addressing
- specify IPv6 over additional media
- USB? Bluetooth?, IOG pipe?, ...
- start an IPv6 "host/router requirements" document
- [ND extensions for address querying / mapping (from Frame Relay work)]

Other current WG chores
- keep all WG docs moving along publication/standardization track
- identify "base set" of docs for advancement to full standard

Other lower-layers WGs to prod
- DNS, DHCPv6, IPv6-over-Firewire, Mobile-IP, RIPv2, OSPF, IS-IS, IDR, MOSPF, PIM, Diff-Serv, (Diameter), Malloc (maybe)

New work for other WGs
- IPv6 readiness check (incl. MIBS) [an IPng WG will probably have to take responsibility for making this happen]
- secure ICMP/ND (ipsec)
- authenticatable, auto-config'd hosts (ipsec)

Other ideas to pursue, perhaps in new WG(s)
- specify how exchanges can work
- TCP/UDP/host use of anycast
- next level of plug-n-play ("AppleTalk"-like)
- 6-over-4 cut-through (NHRP-like)
- more complete story for billions of mobile devices (esp. phones)
- multi-link subnets
- Other ideas to pursue, perhaps in new WG(s) (cont.)
- scope-name discovery
- conformance tests [not in IETF scope]
- tools for reducing network mgmt costs

Possible items for IRTF
- transport use of global interface Ids
- higher-layer survival of renumbering
- router auto-config / auto subnet numbering
- "better" multicast address alloc.
- "better" VPNs
- "better" billing opportunities
- architected MLD snooping
- firewall-in-the-host [already under control, e.g., will be in NT5]
- ICMPv3 -> MLD

- convey msg that "IPv6 is done"; it's time to implement, deploy, and port apps
- review/strengthen "case for IPv6" and various documents about NAT problems.
- keep prodding IP address registries
- develop a voice-over-IPv6 story
- participate more in other WGs
- pass API docs to other stds bodies

Question from B. Carpenter: Should we also send formal statements to other standards bodies? Comment that Open group thinks IPv6 is done, and is ready in include IPv6 API's into unix standard.

Chairs' Recommendation on IPng w.g. / S. Deering, R. Hinden

Revise Charter of IPng WG to:

- Itemize (from previous presentation)
- "Unfinished work"
- "New IPng WG tasks"
- "Other current
- "Chores" tasks, with new (near-term) milestones
- Change name to "IPv6 Working Group"
- Form "IPv6 Directorate" to handle shepherding tasks and recommendations for new WGs and/or RGs

Discussion and questions: Jim Bound: how would directorate members be selected? Normally ADs select directorate members. Discussion. E. Nordmark (new Internet AD) said he thought this was a good idea. Working group agree do these changes.

ACTION: IPng w.g. chairs to revise w.g. charter with new work items and name change.

ACTION: Internet ADs to create "IPv6 Directorate".

Mobile IPv6 Status / D. Johnson

Current version of Mobile IPv6 draft has been through w.g. and IESG last call. Send additional comments to IESG. Some discussion. Doesn't think document needs to be changed. Mobile IP w.g. will discuss on Tuesday.

DNS Extension Status / M. Crawford

Document Status
- One new comment received.
- Specify that the 0-7 pad bits must be zero. (For secure DNS SIG purposes.)
- Dependencies.
- draft-ietf-dnsind-binary-labels
- draft-ietf-dnsind-dname
- draft-ietf-dnsind-edns0

- All on IESG agenda, with editorial comments pending.

Some issues raised with DNS consortia people. Meeting later this week to discuss the issues.

Router Renumbering Status / M. Crawford

Changes from -06 to -08 draft version
- Various editorial detail
- Added a long section & appendix detailing how to decide when you've reached all your routers if you don't know how many routers you have
- Compute estimator of round-trip reliability of least reliable of your routers.
- Use that estimator to compute the Bayesian probability of null hypothesis Ho "reached all routers" vs. union of all Hn "n routers missed", for n >= 1

Comments: Nordmark: Another way to deal with this to always advertise all prefixes in every update with short lifetimes. Response: Then you get a different failure mode, in which routers that go out of contact expire their prefixes. But the use of regular no-op messages is mentioned in the text.

ACTION: Document editor to start IPng w.g. last call for Router Renumbering for PS.

Multicast Listener Discovery Protocol / S. Deering

- Specify behavior when Max Response time is zero
- Miscellaneous clarifications, as suggested by reviewers
- I believe it is ready for WG last call for proposed standard.

ACTION: Document editor to start IPng w.g. last call for Multicast Listener Discovery Protocol for PS.

MONDAY, March 15, 1999 1930-2200 (Salon D)

Tunnel Broker Terminology & Concepts / A. Durand


Tunnel Broker
- Virtual IPv6 ISP
- A place where users connect to register and activate tunnels
- Manages tunnel creation, modification and deletion on behalf of the users
- Shares the load among several tunnel servers
- Sends configuration orders to the relevant tunnel server when tunnels are to be created or modified
- Registers the users in the DNS
- Provides users potentially "permanent" IPv6 addresses which survive IPv4 renumbering (e.g., dial-up)

Tunnel Server
- Dual stack (IPv4 & IPv6) router connected to the global Internet
- Receives configuration order from the tunnel broker
- Creates, modifies, or deletes the half part of the tunnel toward the user.
- Maintains statistics

Meta Broker
- Tunnels brokers around the world register could register to a well know place such as: http:/www.ipv6.org
- Helps user to choose the appropriate tunnel brokers o Closest
- Cheapest
- Most reliable

Tunnel broker / I. Guardini

- IPv6 tunneling over the Internet require heavy manual configuration
- Network administrators are faced with overwhelming management load
- Getting connected to the IPv6 world is not an easy task for IPv6 beginners
- The Tunnel Broker approach is an opportunity to solve the problem.
- The basic idea is to provide tunnel broker servers to automatically manage tunnel requests coming from the users.
- Benefits
- Stimulate the growth of IPv6 interconnected hosts
- Allow early IPv6 network providers the provision of easy access to their IPv6 networks.

The Tunnel Broker Architecture

[figure of architecture]

How does it work?

[example figure1]
[example figure2]

Our Implementation
- CSELT'sTunnel Broker service available at: http://carmen.cselt.it/ipv6tb

- Basic features
- Based on widely available tools to allow fast prototyping of the service
- Basic communications between client and broker run over http
- Tunnel Broker - Tunnel server and Tunnel Broker - DNS interactions based on simple RSH commands
- The user must register before getting access to the service
- The Tunnel Broker provides scripts (automatically created) to ease client's configuration
- Both router and host support
- The provider DNS manages names - global IPv6 address mapping e.g., guardini.tb.ipv6.cselt.it and guardini-if.ipv6.cselt.it
- Administrator interface allow full control over users, tunnels and Tunnel server

Tunnel Broker Service at CSELT


Software Available
- The first version of our implementation of the Tunnel Broker will be available soon at: ftp://carmen.cselt.it/pub/broker/tb-current.tar.gz
- It already supports:
- Client / IPv6 INRIA FreeBSD, IPv6 for windows NT (MS research)
- Tunnel Server / IPv6 INRIA FreeBSD
- We need contributions to add support for more IPv6 stacks!

Connection/Link Status Investigation (CSI) for IPv6 / H. Kitamura

IPv6 Hop-by-hop option and ICMPv6 messages Extension <draft-kitamura-ipv6-hbh-ext-csi-00.txt>

Outline of "Connecting/Link Status Investigation" (CSI) Mechanism
- A generic framework to collect status information of nodes along the both outgoing and incoming path
- One new IPv6 Hop-by-hop option
- CSI option
- Three new ICMPv6 messages
- Status request / status reply
- Status report
- As simple as "ping" mechanism
- More efficient and reliable than "traceroute" type functions

Connection /Link


Requirements for CSI Mechanism
- Cause minimum traffic
- Ideally one pari of request/reply packets
- Avoid unstable (dynamic routing) patch problem
- Investigate bot outgoing and incoming paths
- Be simple enough
- Support CSI feature disabled nodes case and messages lost case
- Be scalable and easily expandable

IPv6 Hop-by-Hop CSI Option


IPv6 Hop-by-Hop CSI Option
- A packet that is set the CSI option investigates nodes along the path
- Collect and record status information when it pass through nodes
- Option tope of CSI option must be 00 1x xxxx
- Starting bits (00): to avoid discarding the packet at the CSI disabled nodes
- Third bit (1): To record the collected data
- Value is 001xxxxx.0x20+TBA (tenatively 0x22)

ICMPv6 Status Request / Reply messages


ICMPv6 Status Request / Reply messages
- A round trip probing loop (boomerang)
- Source --> Destination --> Source
- Both messages must be set the CSI option
- Trigger to start collecting status information
- Carry the collected data by the CSI option

ICMPv6 Status Report message

[ figure ]

ICMPv6 Status Report message
- Issued by hbh_CSI_management_routine()
- Carry the overflowed collected data
- from the investigated nodes
- to the source (initiator)

Status Report message transmission conditions and check algorithm
- Data is full
- Position record Bitmap is full and page must be updated
- Hop limit is expired

Traceroute (or Pathchar) type mechanism

[ figure ]

IPv6 hop-by-hop CSI Option Format (1/3)

[pkt format]

ICMPv6 Status Request Message Format

[pkt format]

ICMPv6 Status Reply Message Format

[pkt format]

Predefined Investigation Types

[pkt format]

Record Incoming Interface Address of Investigated Nodes

[pkt format]


A.Durand: Similar proposal made in 199x? How is this different? Also, how does this work with multicast traceroute. B. Carpenter: Diff Services needs to be able trace paths of a specific DS path. This could be extended to do this.

Deering queried room to see if this should be followed. Some thought it was too complex. Would not want to implement because it would take too much code. Thinks we can do something simpler.

A. Durand: Would also like to see Multicast added. Deering replied that the IPv4 multicast is limited to only trace one branch of the tree. Query sent to leaf of a tree. Done this way to reduce hazard of generating large implosions of traffic. Should think very carefully about generalizing this to multicast.

Node Information Query / Matt Crawford

- Generalized Who-are-you format
- ICMPv6, although there's no intrinsic reason it must be so
- Asks for information about the node at the destination address
- No other query parameters


| Type | Code | Checksum |
| Qtype | Flags |
| |
+ Nonce +
| |
| |
+ Reply Data +
| |

Qtypes: NOOP, Supported Qtypes, FQDN, Addresses
Flags: defined for each Qtype
Nonce: Matches replies to requests, crude anti-spoofing

- UDP would ease building apps with it
- Return node name in DNS form, not ASCII
- Urge consistency if multiple names exist
- Is use of TTL appropriate?
- Limit number of Qtypes more sharply?
- Define a compressed form of Supported Qtypes reply data
- Additional Query types?

Generic Address Mapping / A. Durand

Related Work

Address mapping matrix
Name, preferred, global, site-local, link-local, (MAC address?) to Name, preferred, global, site-local, link-local, (MAC address?)

Unicast Queries
- UDP unicast query
- Node information query
- Usage:
- local address to name mapping
- local address to global address mapping

Multicast Queries
- Well known UDP multicast <all-node implementing this service> site local
- Suggestion: use many multicast addresses hashed
- Usage:
- Name to local address mapping without DNS
- Replies may be unicast or multicast???
- Caching issues

A. Durand and M. Crawford will work together to combine drafts into one.

Steal This Slide / M. Crawford

Presented several new idea. Hopes someone will pickup and work on them.

Multicast Core or RP Location
- Flood-and-prune multicast doesn't scale, and some alternatives need to associate a multicast group address with a core or rendezvous point.
- There are 79 MBZ bits in an IPv6 multicast address.
- Unicast prefixes are up to 64 bits long.
- 64 < 79.
- A prefix could be inserted in the group address which gives the core or RP location.

Neighbor Discovery - by Name
- Serverless address-to-name mapping is possible, how about serverless name-to-address mapping? Several possible approaches:
- Multicast to all nodes.
- Bad on a large serverless subnet, if such exists.
- Doesn't cross a router.
- Multicast to a "solicited name address" based on a hash of the name.
- Would require nodes to join third mandatory multicast group.
- Build it on service location.
- A bit of a heavy stick? Maybe not.

Downstream Renumbering
- Some (most?) renumbering events will be initiated at the site level, but others will not.
- Need a multi-tiered equivalent of Router Renumbering to propagate changes downward from provider NMS to customer NMS.
- Require flexible options for human checking or automatic action.

ND Extensions for Frame Relay / A. Conta

[speaker was not able to attend due to snow storm in Boston area]

Using E.164 Telephone numbers as IPv6 addresses / H. Afifi

- Motivation
- IPv6 address formats
- E.164 address formats
- The first solution
- The second solution

- New standards are looking at global networks (IMT 2000, UMTS, Bluetooth, ....)
- One identification is better than two
- Plug and play (the telephony is ahead in this domain)

Brian C: Has not been convinced peer model is better than than layered model.
- A field where IPv4 is not usable
- A very large number of potential hosts

E.164 Numbers
- There possible types:
- For networks +33 (6) 82 888030
- For international (+1) 514 727 2282
- For global services, imarsat, etc.
- Usually a fourth type is mostly used Intelligent Network (+1) 514 727 2282
- The prefix is not part of the E.164 structure
- We can have a sub-address but not routable

E.164 Structure
- International

| Country Code | National Dest.Code | Subscriber number |
1-3 digits
<-------------------max 15 digits ---------------------->

- The routable part is 7 digits maximum

Other Formats
- E.164 for Networks (ex. ISDN, ATM, GSM, etc...)

| Country Code | Ident. code | Subscriber number |
<- 3 digits --> <- 1 to 4 digits -->
<-------------------max 15 digits ---------------------->


| Country Code | Global Subscriber number |
<- 3 digits -->

Using Intelligent Networks

Abstract flat number is mapped to real routable number.


- RFC2373

| Prefix | Address |

- RFC2374

Aggregatable Global Unicast Address
- Hierarchy prefixes
- One address at the end to identify the terminal

| FP | TLA | NLA | SLA | Interface Identifier |

Map telephone number into interface ID.

E.164 / IPv6
- Who is the routing network
- If IPv6 then:

| FP | TLA | NLA | SLA | code your number |

Very convenient for the current Intelligent Network

| FP | TLA | NLA | Code your subscriber number |

Where NLA is routable part of the number

example: +1 514 767 2282

If routing is telephone based

| Prefix | Address |

Where Prefix is a special prefix for E.164
Address is different structures for different E.164 cat.

Comments: To him E.164 is like a DNS name, not an IP address. Should not be mapped this directly.

Discussion: Needs more detail on how these formats could be used. Assumption on size of fields, could grow to larger size from 15 digits. Needs more work...

GateD IPv6 Status / W. Siadak

- Objective
- Retro-fit Gated with IPv6 Code
- IPv6 Code contributions
- Francis Dupont (RIPng, BGP4+)
- WIDE contributors (BGP4+)
- Yixin Yang of UCLA (PIM-DM)

Implementation To-Date
- Gated core code
- Protocols
- RIPng
- BGP4+
- PIMv6

- Builds
- KAME stack
- INRIA stack
- Tests Passed
- Static routes
- RIPng 2 and 4 machine test
- BGP4+ 2 and 4 machine test
- Export and import policy
- Basic tests against MRT

- More tests
- Interoperability tests
- Stress Tests
- OSPFv6
- Builds
- Solaris
- Compaq



- Snapshots
- First one was 12/98
- Latest was 3-12-99

Current State of IPng Multihoming / S. Deering

Will make sides available to group. Talk consists of features of IPv6 that may make multihoming easier and/or harder. Lays out issues, but does not have solutions.

Comments: Multihoming is very important problem. Want to see more work on topic. Deering: expect to see action in next meeting.


None received.