2.3.8 IPNG (ipngwg)

NOTE: This charter is a snapshot of the 41st IETF Meeting in Los Angeles, California. It may now be out-of-date. Last Modified: 12-Feb-98

Chair(s):

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

Internet Area Director(s):

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

Internet Area Advisor:

Jeffrey Burgan <burgan@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:

Done

  

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

Done

  

Submit revised core IPng specifications as Internet-Drafts.

Done

  

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

Done

  

Submit extended IPng specifications as Internet-Drafts.

Done

  

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

Done

  

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

Done

  

Submit revised IPng specifications as Internet-Drafts.

Done

  

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.

Internet-Drafts:

Request For Comments:

RFC

Status

Title

 

RFC1886

PS

DNS Extensions to support IP version 6

RFC1885

PS

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

RFC1884

PS

IP Version 6 Addressing Architecture

RFC1887

 

An Architecture for IPv6 Unicast Address Allocation

RFC1897

E

IPv6 Testing Address Allocation

RFC1981

PS

Path MTU Discovery for IP version 6

RFC1970

PS

Neighbor Discovery for IP Version 6 (IPv6)

RFC1972

PS

A Method for the Transmission of IPv6 Packets over Ethernet Networks

RFC1888

E

OSI NSAPs and IPv6

RFC2019

PS

Transmission of IPv6 Packets Over FDDI

RFC2023

PS

IP Version 6 over PPP

RFC2073

PS

An IPv6 Provider-Based Unicast Address Format

RFC2133

 

Basic Socket Interface Extensions for IPv6

RFC2147

PS

TCP and UDP over IPv6 Jumbograms

RFC2292

 

Advanced Sockets API for IPv6

Current Meeting Report

Minutes of the IPNG (inpgwg) Working Group

Co-Chairs:
Robert Hinden / Nokia
Steve Deering / Cisco

Steve Deering introduced the meeting. Three meeting slots are scheduled. Robert Hinden took and edited the minutes.

The agenda was reviewed. The resulting agenda was:

Monday

Introduction / S. Deering (5 min)
Review Agenda / S. Deering (5 min)
UNH Interoperability Testing / B. Lenharth (5 min)
Document Status / R. Hinden (15 min)
Mobile IPv6 Status / D. Johnson (15 min)
Proposed ND Split / M. Wasserman (5 min)
IPv6 over PVC ATM / S. Deering (10 min)
IPv6 over NBMA & IPv6 over ATM Status / P. Schulter (10 min)
Router Renumbering / M. Crawford (15 min)
Scope Issues / S. Deering (30 min)

Tuesday

Multicast Listener Discovery Protocol / S. Deering (30 min)
IPv6 Plug and Play, Done? / R. Hinden (30 min)

Thursday

DNS Status / S. Deering (30 min)
ICMP Name Lookups / M. Crawford (5 min)
ICMP Node Info / A. Durand (10 min)
Reverse DNS Lookup / M. Crawford (15 min) <draft-ietf-ipngwg-dns-lookups-00.txt>
IPv6 Host Naming Translations / J. Paugh (10 min)
Address Allocation Status Report / R. Hinden (5 min)

I. UNH Interoperability Testing / B. Lenharth

[Editors note: B. Lenharth was not able to give the report. R. Hinden gave summary]

Most recent test event was at Connectheon. No router vendors present. Used Sun as router between two segments.

IMAG BGP4+athon

Five implementations

eBGP & iBGP tests

route redistribution

II. Document Status / R. Hinden

RFC Published

IESG Approved

IETF Last Call completed for Proposed Standard

Submitted to IESG for Draft Standard

Submitted to IESG for BCP

IPng Working Group Last Call Completed for Draft Standard

Submitted to IESG

W.G. Last Call Completed

TLA/NLA Assignment Rules Status

III. Mobile IPv6 Status / D. Johnson

Mobile IPv6: IPv6 Changes and Open Issues

Dynamic Home Agent Address Discovery

Improved Home Agent Discovery

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cur Hop Limit |M|O|H| Reserved| Router Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reachable Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retrans Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-

Other Neighbor Discovery Changes

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertisement Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Discussion about need for this. Comparison with special home agent protocol. Mobile nodes need easy way to learn that they have moved. Proposal for sending to anycast address of home agent. Possible any assignment of "3" (0 is subnet router, 1 & 2 are for point-point link address assignment, 3 is next).

Discussion about can interval be less than one seconds. Should ND be change to use milliseconds instead of seconds? Why is less than once second needed?

Question about do all links need high frequency beacons? Only wireless? Mobile IP is not focused on wireless only.

Other Issues for IPng Working Group

ACTION DOC EDITOR: Get assignment for these options code points and start the anycast address assignment. Collect all code points. ND, ION, mobileIP etc.

Deering and Johnson will write short draft describing anycast assignment in the next two weeks.

Comments, Please

IV. Proposed ND Split / M. Wasserman

ND is a useful set of mechanisms. Many IPv6 host will (and should) implement the full set. Some ND mechanisms may not apply to some:

Proposal to split ND into eight separable ND mechanisms

Requirement for minimal IPv6 functionality on many link types:

Advanced Features:

Configuration "scopes":

Suggested specification changes

Suggested specification split:

Discussion. Suggestion was made that this document can define what is appropriate for each link types and what can be turned off. It would be an applicability document for ND and Autoconfiguration.

V. IPv6 over PVC ATM / S. Deering

Two competing specs for how to run IPv6 over ATM in a PVC mode. Point-to-point links between IPv6 nodes as opposed to using ATM in NBMA mode.

IPv6 over PVC ATM draft and ION NBMA draft. In previous meetings the approach discussed was that there would be a separate document that defined this mode independently from full NBMA draft. Deadline proposed. Chairs believe deadline was end of January 1998 and that deadline has passed. ION document were published prior to March 1998 meeting.

In ION documents IPv6overPVC-ATM is not in one place but spread over many sections in two documents. Some differences in two approaches: MTU, generation of link-local addresses, others?

Deering's personal opinion is that it should not be spread over two documents. Would prefer PVC case to be in a single document.

Stopped discussion and did following ION status.

VI. IPv6 over NBMA & IPv6 over ATM Status / P. Schulter

ION meet today and discussed this issue.

<draft-ietf-ion-ipv6-01.txt>

Grenville Armitage (Lucent)
Peter Schulter (Bright Tiger Technologies)
Markus Jork, Geraldine Harter (Digital)

The General Architecture

Since last we met....

Open Issues:

ACTION IPng Doc Editor: Get option assignment

<draft-ietf-ion-ipv6-atm-01.txt>

PVC rules

SVC rules

VII. Continuation of IPv6 over PVC ATM Discussion / S. Deering

Three points:

1) Technical differences. "IPv6 over Point-to-Point ATM Link" <draft-yamamoto-ipv6-over-p2p-atm-01.txt> spec is what has been implemented in WIDE implementation.
2) Should there be a stand alone document?
3) If we go with ION document, there should be proper acknowledgment of <<draft-yamamoto-ipv6-over-p2p-atm-01.txt> authors.

Asked for comments. discussion. Many liked separate document. Suggested to use ION link-local rules. Another comment suggested that once technical issues resolved we should go with ION work. Suggestion that ION has been implemented as well. Discussion should have happened in ION.

K. Yamamoto is willing to defer to ION, but wants it out quickly. Deering suggested that K. Yamamoto and ION authors get together and resolved differences. Would still like to have the PVC document be stand alone.

Will go forward with ION document with closer coordination from K. Yamamoto.

VIII. Router Renumbering / M. Crawford

Status draft -03

Spin-Off work

Comment that given authentication this document does not need to definesite. Security implicitly defines site.

VIII. Multicast Listener Discovery Protocol / S. Deering

New draft out <draft-ietf-ipngwg-mld-00.txt>. Equivalent of IPv4 IGMP for IPv6.

Changes:

Solicited comments.

IX. Scope Issues / S. Deering

Discussion with diagrams.

| | |
| | |
| | |
+--------+ +--------+ +--------+
| | | | | |
| Rtr | | Rtr | | Rtr |
| | | | | |
+--------+ +--------+ +--------+
| | |
| | |
| | |
============================================

Link Local: Drew scope boundary through the middle of Routers

Site Local: Showed three alternatives. First site boundaries is in the middle of routers. Second boundary is in the middle of links. Third is interface based.

Assumption that sites are not overlapping. Overlapping sites are not currently supported. There is only one site-local prefix.

Question about why we want site local. Why do we want to have them? This was discussed at length on mailing list. Conclusion was to keep them. It would be more destructive to get rid of them, than to keep them and to define usage. Current objective is they are useful during renumbering. Site local addresses don't have to change.

Comment that Erik Nordmarks draft is only defined usage of site-local. Think we can keep this usage without defining in detail.

Deering want to propose simple definition with guidance for implementors. If they don't get use, this will not be a problem.

+--------+ +--------+
| | | |
| Rtr 1 +--------------------+ Rtr 2 |
| | | |
+--------+ +--------+

..site A.. | ..........site B........... | ......site C.........

In this example there is a site boundary between each router. This
results in three sites (left 1/2 of rtr 1, right 1/2 of rtr 1 through
left 1/2 of Rtr 2, etc.

Long discussion.

General consensus in the discussion to keep site local and agreement to make site boundaries in node (not link or interface).

ACTION: S. Deering to write a draft

X. IPv6 Plug and Play, Done? / R. Hinden

Context

Where Are We Now?

What Is Missing?

Solutions

DNS Server Location

Approaches

Next Steps

Ohta: for DNS lookups, and DNS server will do; for registering/updating names, need specific server

Nordmark: what about coffee machines without keypads?

Bound: don't dump on servers!

Cheshire: svrloc allows literal addresses, so would work fine for DNS discovery

Deering: maybe spin off to a separate working group?

Bound: to use anycast, need to allow hosts to have anycast addrs

Durand: DNS service itself is complex, server-based; not exactly what dentists want?

More random discussion.

General conclusion that topic should be pursued, but not clear if it should be in the IPng working group.

XI. DNS Status / S. Deering

First item is where we are in DNS work. Major piece of core charter. Need to find current state and what should we do. What document should be moved forward, what not, what else needs to be done. Solicited opinion.

CH: Did revision of draft based on previous decision. Submitted first release in January. New draft based on comments. Draft stable. Added tutorial part, comment to expand this and clarify. Reluctant to do any changes. Wants doc to go to wg. last call. Has not received any major objections. Only wants to make changes based on wg. comments. Waiting for results of reverse lookup.

Publish as is or merge with new reverse lookup approach. Relationship w/ current RFC. Backwards compatible with current AAAA RFC. Conclusion (w/ no objections) is this will replace current AAAA RFC. RFC1886 will become obsoleted (historic).

ACTION: Chairs do W.G. last call for when new draft is out.

XII. ICMP Name Lookups / M. Crawford

Status (-02)

XIII. ICMP Node Info / A. Durand

ICMP Node Info / Local extensions of ICMP "who are you"

Motivation

Two ICMP types, several codes, X: request, Y: reply

X/0: "localname" request Y/0: "local name" reply
X/1: incoming interface Y/1: incoming interface
global address request global address reply
X/2: all interfaces global Y/2: All interfaces global
address request address reply

Unicast Usage

Multicast Discovery

Security Considerations

Question: relationship between this and link local naming.

CH: Should coffee pot use this or DNS? Answer this. Discussion. Generally thinks naming functions should be in DNS resolver and not in ICMP.

M. Otha: Should this be used in sites? No only link scope. These names should only be used with limited scope. This can be used to discover all of the names on the link.

Deering: Thinks functionality should be in resolver, but that doesn't mean that this needs to be in DNS protocol. Matt: Could make small changes to "who are you" draft to allow more request types and replies.

Kazu: Doesn't link this under ICMP. On Unix systems UDP would be better. Need root access to send/receive ICMP messages.

ACTION: Chairs to figure out how to keep this work going. Might be in new wg., somewhere else.

Dimitry H: Need mechanisms to discover global address of router from link-local address. Doesn't think SNMP is appropriate. Could add ND option to router advertisement to advertise global address of router. Can we require routers to accept packets sent to prefix it is advertising with interface ID from link local address of router. Becomes an anycast address for router.

Deering: links and subnets are not necessarily the same thing. Would like architecture to allow subnets to span multiple links.

Discussion:

Nordmark: Wants to keep node in control of what addresses it uses.
Doesn't want other nodes to decide. Also, is this also needed for hosts
too?

Bound: Thinks we should just have ND advertise all address of node.

Nordmark: If so, would need to add lifetimes with each addresses. Lots
of detail here.

Otha: Thinks sites are collection of links.

Discussion....

XIV Reverse DNS Lookup / M. Crawford <draft-ietf-ipngwg-dns-lookups-00.txt>

IPv6 DNS Lookups

Goals and Semi-Goals

New DNS Tools

Proposed Structure

[ Slide w/ examples]

Pesky Details

Questions: Has this been reviewed by DNS wg? Meet yesterday, feeling is that it should be done. Some technical details to work out, but should be done quickly. Expect to be done by next IETF meeting (August 98).

CH: Thinks this is compatible with new DNS draft. Has talked to Matt C. about it. Good to have all of this together. Good thinking, very complementary. All data in one place. Only practical question is of timing. Relationship between DNAME and Binary Labels? Could this be blocked for a long time? Matt did not think this would happen. KRE: DNS group has a good track record to get work out. Should be ready for IESG by next IETF.

Conclusion is to merge the two drafts.

XV. IPv6 Host Naming Translations / J. Paugh

Solaris NIS/NIS+ Naming Services

Goal is to not break IPv4 applications

IPv4 & IPv6 Addresses Stored Separately

Server Side Changes

[ Figure showing getXbyY() Application ]

XVI. Address Allocation Status Report / R. Hinden

Meet with registries and IANA. General conclusion is continue with approach described on Monday. New change is approach to initially assign sub TLA to transit providers who request allocation. When this is 90% used, they can then ask for a full TLA. This will be assigned with the understanding that they will have to give back the sub-TLA after a transition period. This should keep the top level routing in the order of the number of transit providers. Will work with registries and IANA to revise the draft. Expect to publish it in early May.

Dimitry: Make sure policy doc does not rule out allocation of TLAs to exchanges.

Carpenter: this doc will not be an IESG-approved doc; will be published as Informational RFC.

XVII. IANA Status / R. Hinden

Meet with Jon Postel. Will collect and sanitize current code point request and send to IANA. Future request sent to IANA will be reviewed by IPng document editor.

R. Hinden will serve as IANA technical reviewer for v6 numbers; asked for all spec authors to email him their code-point requirements and corresponding document citations.

Meeting adjourned.

Slides

None Received

Attendees List

go to list