2.3.8 IPNG (ipngwg)

NOTE: This charter is a snapshot of the 49th IETF Meeting in San Diego, California. It may now be out-of-date. Last Modified: 03-Nov-00

Chair(s):

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@iprg.nokia.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

RFC1887

 

An Architecture for IPv6 Unicast Address Allocation

RFC1886

PS

DNS Extensions to support IP version 6

RFC1981

PS

Path MTU Discovery for IP version 6

RFC1888

E

OSI NSAPs and IPv6

RFC2147

PS

TCP and UDP over IPv6 Jumbograms

RFC2292

 

Advanced Sockets API for IPv6

RFC2375

 

IPv6 Multicast Address Assignments

RFC2374

PS

An IPv6 Aggregatable Global Unicast Address Format

RFC2373

PS

IP Version 6 Addressing Architecture

RFC2461

DS

Neighbor Discovery for IP Version 6 (IPv6)

RFC2462

DS

IPv6 Stateless Address Autoconfiguration

RFC2463

DS

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

RFC2464

PS

Transmission of IPv6 Packets over Ethernet Networks

RFC2467

PS

Transmission of IPv6 Packets over FDDI Networks

RFC2470

PS

Transmission of IPv6 Packets over Token Ring Networks

RFC2471

E

IPv6 Testing Address Allocation

RFC2460

DS

Internet Protocol, Version 6 (IPv6) Specification

RFC2452

PS

IP Version 6 Management Information Base for the Transmission Control Protocol

RFC2454

PS

IP Version 6 Management Information Base for the User Datagram Protocol

RFC2465

PS

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

RFC2466

PS

Management Information Base for IP Version 6: ICMPv6 Group

RFC2450

 

Proposed TLA and NLA Assignment Rules

RFC2472

PS

IP Version 6 over PPP

RFC2473

PS

Generic Packet Tunneling in IPv6 Specification

RFC2497

PS

Transmission of IPv6 Packets over ARCnet Networks

RFC2507

PS

IP Header Compression

RFC2526

PS

Reserved IPv6 Subnet Anycast Addresses

RFC2529

PS

Transmission of IPv6 over IPv4 Domains without Explicit Tunnels

RFC2553

 

Basic Socket Interface Extensions for IPv6

RFC2675

PS

IPv6 Jumbograms

RFC2710

PS

Multicast Listener Discovery (MLD) for IPv6

RFC2711

PS

IPv6 Router Alert Option

RFC2732

PS

Format for Literal IPv6 Addresses in URL's

RFC2874

PS

DNS Extensions to Support IPv6 Address Aggregation and Renumbering

RFC2894

PS

Router Renumbering for IPv6

RFC2928

 

Initial IPv6 Sub-TLA ID Assignments

Current Meeting Report

IPng Meeting Minutes
San Diego, IETF
December 13, 14, 2000

Bob Hinden, Nokia
Steve Deering, Cisco
Chairs

-------------------------------------------------------------------

Agenda
------

Introduction / S. Deering
Review Agenda / S. Deering
Document Status and Charter Status / B. Hinden
Summary of Internet Address Registry Presentations / Alain Durand

Source/Destination Address Selection / Rich Draves

An analysis of IPv6 anycast / Itojun Hagino

Analysis of DNS Server Discovery Mechanisms for IPv6 / Dave Thaler

Discovery of Resource Records Designating IPv6 Address prefixes / Matt Crawford

Socket API for IPv6 traffic class field / Itojun Hagino

Default Router Preferences & More Specific Routes in RAs / Rich Draves

Automatic Prefix Delegation Protocol for IPv6 / Brian Haberman

Destination Option Headers Cleanup / Francis Dupont

An end-to-end usage of IPv6 flow label / Jochen Metzler

Socket API for IPv6 flow label field / Itojun Hagino

Multihoming / Masataka Ohta

Record Route Hop-by-Hop Option for IPv6 / Hiroshi Kitamura

ETSI bake-off report / Francis Dupont

Overview of USAGI Project (Linux IPv6 Improvement Project) / Yuji Sekiya

Site renumbering using router renumbering protocol / Tatuya Jinmei

How to write UDP/IPv6 applications that care about path MTU / Tatuya Jinmei

Status of OSPFv3 implementation for Zebra / Yasuhiro Ohara

LIN6: Mobility Support in IPv6 based on End-to-End Communication Model / Fumio Teraoka

--------------------------------------------------------------

Introduction / S. Deering
-------------------------

Steve Deering opened the meeting, introduced chairs, etc.

Review Agenda / S. Deering
--------------------------

Reviewed agenda. Added short summary talk on IPv6 Multihoming meeting held on Tuesday.

Document Status and Charter Status / R. Hinden
-----------------------------------------------
[See slides at http://playground.sun.com/pub/ipng/html/meetings.html

DOCUMENT STATUS

RFC's Published
- RFC2894 Router Renumbering for IPv6 (Proposed Standard)
- RFC2928 Initial IPv6 Sub-TLA ID Assignments (Informational)

IESG Approved
- IP Version 6 Management Information Base for the Multicast Listener Discovery Protocol (Proposed Standard)
- Privacy Extensions for Stateless Address Autoconfiguration in IPv6 (Proposed Standard)

IETF Last Call completed

- RFC2372 IP Version 6 Addressing Architecture (Draft Standard)

DOCUMENT STATUS

IETF Last Call completed (continued)
- RFC2374 An IPv6 Aggregatable Global Unicast Address Format (Draft Standard)

- IPv6 Node Information Queries (Proposed Standard)

- Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification (Proposed Standard)

Submitted to the IESG
- IPv6 Multihoming with Route Aggregation (Informational)

- Separating Identifiers and Locators in Addresses: An Analysis of
the GSE Proposal for IPv6 (Informational)

IPng Working Group Last Call Completed
- Transmission of IPv6 Packets over IEEE 1394 Networks (Proposed Standard)

ACTION: Document editor will submit "Transmission of IPv6 Packets over IEEE 1394 Networks" to the IESG for Proposed Standard.

- IPv6 multihoming support at site exit routers (Informational)

ACTION: Document editor will submit "IPv6 multihoming support at site exit routers to IESG for Informational.

- A flexible method for an IPv6 addressing plan (info)

The chairs would like the title changed to something that does not appear to be an address assignment plan and text stating this in the draft itself.

ACTION: Document editor will start new working group last call "A flexible method for an IPv6 addressing plan" for informational.

- IAB: The Case for IPv6 (Informational)

Carpenter: no longer an IAB doc.
Perkins: Could be taken on by NGTRANS working group.

ACTION: Document editor will no longer report on status of the "IAB: Case for IPv6" to the IPng working group. The NGTRANS may pick up this document.

IPng Working Group Documents Ready for Draft Standard
- IPv6 over Ethernet
- IPv6 over FDDI
- IPv6 over Token Ring
- IPv6 over ARCNET
- IPv6 over PPP

Implementation reports for candidates for Draft Standard needed

http://playground.sun.com/pub/ipng/implementation-reports/templates/

NEW WORKING GROUP CHARTER STATUS
- Revised charter submitted to IESG

MOBILE / WIRELESS IPv6 DEVICE DESIGN TEAM
- Develop recommendations on how mobile / wireless devices should use IPv6 Include

- Identify relevant specifications

Multi6 BOF Summary / Thomas Narten
------------------------------------

Summary
- Room too small, less than 1/2 people fit
- Official chair got in 15 min late
- Randy Bush ran meeting
- Operators were present and actively participated
- Outcome:

Summary of Internet Address Registry Presentations / Alain Durand
-----------------------------------------------------------------
[See slides at http://playground.sun.com/pub/ipng/html/meetings.html]

Summary of presentation made to recent Internet Registry meetings.

Recommendation was accepted by RIPE NCC and APNIC. ARIN did not accept it and wants further discussion.

Source/Destination Address Selection / Rich Draves
<draft-ietf-ipngwg-default-addr-select-02.txt>
---------------------------------------------------
[See slides at http://playground.sun.com/pub/ipng/html/meetings.html]

Source Address Selection Rules

Nordmark: Rule 7 issue. Concerned that temporary addresses will break applications. Didn't think it should be in the default list of addresses to select. Selection should be very application specific and can't be in basic rules. Suggest that temporary addresses need specific rules to enable.

Dupont: Also concerned with rule 4. Draves thinks that need to be controlled by API.

Dupont: Raised thought that this should informational, not standards track. Draves thought that this was required for interoperability. Deering thought this was important to insure uniform operation. Should be on standards track.

Bound: Suggest don't use phrase "route lookup". Also, had concern about rule 7 about temporary addresses. Would prefer that there be a client / server switch for this.

Durand: Thinks rule 7 is application dependent. Needs per application control and should be in default list.

Itojun: Thinks "must" items are there for interoperability. Others should be in host/router requirements.

Carpenter: Doesn't agree with Dupont. Need to specify default behavior. Should be standards track.

Other: Likes draft. Would like some simpler way of achieving these goals. Draves: Doesn't turn into too much code.

Remaining issues
- API (socket options?) for controlling mobility and privacy preferences

- Consolidate SrcLabel/DstLabel?
- Last call

Deering: Still open issues. Need to close issues on mailing list and then measure consensus on list. Want to move this forward before next IETF.

An analysis of IPv6 anycast / Itojun Hagino
<draft-itojun-ipv6-anycast-analysis-01.txt>
---------------------------------------------
[See slides at http://playground.sun.com/pub/ipng/html/meetings.html]

Discussion/questions about security issues and how to use IPSEC or not. Document needs to be clarified in several areas.

Analysis of DNS Server Discovery Mechanisms for IPv6 / Dave Thaler
<draft-ietf-ipngwg-dns-discovery-00.txt>
-------------------------------------------------------------------
[See slides at http://playground.sun.com/pub/ipng/html/meetings.html]

Result of DNS Discovery design team.

Deering: Wanted to get w.g. input on use of anycast. Is this a reasonable way to go forward on this approach. Polled group. Rough consensus on using anycast transport mechanisms. The design group will look at content approached based on using anycast for transport and will report back to working group.

[Editor: Does site boundaries limitation cause problems with anycast (e.g., discovery message is sent from one site to another)?]

Discovery of Resource Records Designating IPv6 Address prefixes / Matt Crawford

------------------------------------------------------------------
[See slides at http://playground.sun.com/pub/ipng/html/meetings.html]

Next step is to update spec, then submit for informational. Discussion about why this needed to be a standard to insure interoperability. Took poll of w.g., very rough concerns for standards track.

-----------------------------------------------------------------------
THURSDAY
-----------------------------------------------------------------------

Introduced session. Chairs announced that they are considering having an interim meeting before the March IETF. It would allow more detailed discussion of important topics.

Socket API for IPv6 traffic class field / Itojun Hagino

-------------------------------------------------------
[See slides at http://playground.sun.com/pub/ipng/html/meetings.html]

The need for traffic class API Hosts want to be able to mark Class and Flow Label bits in header.

Discussion about default value. Either zero is OK or software can read initial value before setting and restore it.

Also, no need for dealing with IPv4 TOS in IPv6 API.

Default Router Preferences & More Specific Routes in RAs / Rich Draves

----------------------------------------------------------------------
[See slides at http://playground.sun.com/pub/ipng/html/meetings.html]

Changes:

Add a two bit preference field
Add Route Information Option

Would like to get option type from IANA.

Discussion:

F. Dupont said he suggested this something like this in the early days of IPv6. Question about need for variable length of prefixes in option, vs. fixed length. Draves: draft only has three choices: 0, 8, or 18. This isn't too complex.

Question about conception model. Should it be done in RA?

PRF bits in RA Header change overlap multicast bits.

Relation to Multi6 w.g. activity. They might end up with something similar.

There might be multiple administrators who are not cooperating setting these bits. Might be an issue here.

Deering: Ideas has been around for a while. Most concerns raised previously have been addressed (e.g., full routing tables not sent), concern that this puts more manual configuration in hosts, etc.

Hinden: Liked idea, but has concerns about how to set the preferences. Too many conflicting scenarios.

Deering took poll to see if this should be a working item. Group consensus that work should continue but it is too early to decide if it should be a w.g. document.

Automatic Prefix Delegation Protocol for IPv6 / Brian Haberman

--------------------------------------------------------------
[See slides at http://playground.sun.com/pub/ipng/html/meetings.html]

Describing work outside of IETF dealing with home networking.

Wants advice from w.g. about what way to go.

Deering: Important to make sure that router always gets the same prefixes. IPv6 addresses need to be long lived. Third parties make this harder. How big a prefix? This is an open issue.

Matt Crawford: Didn't see a focus on which part of the problem this was addressing. Lots of details to resolve.

Brian Carpenter: Do you have any feedback if they might be interested. Need to consider DNS issues as well.

Destination Option Headers Cleanup / Francis Dupont

---------------------------------------------------
[See slides at http://playground.sun.com/pub/ipng/html/meetings.html]

Deering asked why speaker said the destination option was a "nightmare". Dupont: because that the destination header can occur at different places. Deering answered that this is the way that IPv6 was designed. Dupont doesn't think that this freedom is useful.

Zill: We should design the API around the protocol, not the protocol around the API.

Deering: Important to keep flexibility to allow new uses as new applications are conceived/developed. Deering does not understand the need for this approach. Dupont want there to be more structure in destination header placement.

Bound: Also doesn't think we should change the protocol to match the API.

[Editor: ran out of time, stopped presentation/discussion, but there didn't see to be much support for this proposal]

An end-to-end usage of IPv6 flow label / Jochen Metzler

-------------------------------------------------------
[See slides at http://playground.sun.com/pub/ipng/html/meetings.html]

Question from 3GPP on the use of the IPv6 flow label for bearer identification.

Current definition of flow fits well with 3GPP definition of bearer service.

Alex Conta: Question that if application assign flow label, how does the network know what the flow label means. Network can learn that application wants all the packet with the same label to be treated the same.

Discussion...

Bound: Needs more overall solution, need to think about whole problem, and needs to use integrated services to handle this.

3GPP usage: Wants to be able us flows labels to identify end-end flows. Would require some sort of signaling to tell what flow label means. Routers can not change flow labels.

Conta: Can change flow labels in network, but still change them. Want topic discussed at interim meeting.

Deering: Thinks that there is interest in standardizing usage of flow label.

Discussion......

Nordmark: Instead of talking about solution, would like to see what problems need to be solved. Deering: Agrees, we need to focus on the problems and should discuss at an interim meeting.

[Editors note: if discussed at interim meeting, make sure transport people are involved]

Socket API for IPv6 flow label field / Itojun Hagino

-----------------------------------------------------
[See slides at http://playground.sun.com/pub/ipng/html/meetings.html]

Deering: Good work, but can't define API until after we define what flow label is.

Multihoming / Masataka Ohta

-------------------------------------------
[See slides at http://playground.sun.com/pub/ipng/html/meetings.html]

Chairs suggest that this work be moved to the new IPv6 multhoming w.g.

Record Route Hop-by-Hop Option for IPv6 / Hiroshi Kitamura

----------------------------------------------------------
[See slides at http://playground.sun.com/pub/ipng/html/meetings.html]

Comments. Alain Durand seems like proposal made last year. Had denial of service attack problem.

Crawford: Doesn't think compression is necessary.

Deering asked people to comment on mailing list.

ETSI bake-off report / Francis Dupont
-------------------------------------
[See slides at http://playground.sun.com/pub/ipng/html/meetings.html]

Overview of USAGI Project (Linux IPv6 Improvement Project) / Yuji Sekiya
------------------------------------------------------------
[See slides at http://playground.sun.com/pub/ipng/html/meetings.html]

Site renumbering using router renumbering protocol / Tatuya Jinmei
------------------------------------------------------------------
[See slides at http://playground.sun.com/pub/ipng/html/meetings.html]

How to write UDP/IPv6 applications that care about path MTU / Tatuya Jinmei
--------------------------------------------------------------
[See slides at http://playground.sun.com/pub/ipng/html/meetings.html]

Status of OSPFv3 implementation for Zebra / Yasuhiro Ohara
----------------------------------------------------------
[See slides at http://playground.sun.com/pub/ipng/html/meetings.html]

LIN6: Mobility Support in IPv6 based on End-to-End Communication Model / Fumio Teraoka
----------------------------------------------------------------------
[See slides at http://playground.sun.com/pub/ipng/html/meetings.html]

------------------------------------------------------------
Meeting Adjourned
------------------------------------------------------------

Slides

None received.