2.3.7 IPNG (ipngwg)

NOTE: This charter is a snapshot of the 43rd IETF Meeting in Orlando, Florida. It may now be out-of-date. Last Modified: 25-Nov-98

Chair(s):

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

 

RFC1885

PS

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

RFC1886

PS

DNS Extensions to support IP version 6

RFC1887

 

An Architecture for IPv6 Unicast Address Allocation

RFC1883

PS

Internet Protocol, Version 6 (IPv6) Specification

RFC1897

E

IPv6 Testing Address Allocation

RFC1981

PS

Path MTU Discovery for IP version 6

RFC1888

E

OSI NSAPs and IPv6

RFC1972

PS

A Method for the Transmission of IPv6 Packets over Ethernet Networks

RFC1970

PS

Neighbor Discovery for IP Version 6 (IPv6)

RFC2019

PS

Transmission of IPv6 Packets Over FDDI

RFC2023

PS

IP Version 6 over PPP

RFC2133

 

Basic Socket Interface Extensions for IPv6

RFC2147

PS

TCP and UDP over IPv6 Jumbograms

RFC2292

 

Advanced Sockets API for IPv6

RFC2373

PS

IP Version 6 Addressing Architecture

RFC2374

PS

An IPv6 Aggregatable Global Unicast Address Format

RFC2375

 

IPv6 Multicast Address Assignments

Current Meeting Report

IPng Working Group
December IETF

Bob Hinden / Nokia
Steve Deering / Cisco
Co-Chairs

Steve Deering introduced the meeting. Two meeting slots were scheduled.
Bob Hinden took and edited the minutes.

Thursday 3:30PM - 5:30PM
Friday 9:00AM - 11:30AM

The agenda was reviewed. The resulting agenda was:

Agenda:

Unified IPv6/IPsec Stack / K. Kamamoto

We decided to merge our code:

Targets are BSD variants

Schedule

Document Status / R. Hinden

IETF Last Call completed for Proposed Standard

Submitted to IESG for Proposed Standard

IPng Working Group Last Call Completed for Proposed Standard

IPng Working Group Last Call Completed for Informational

IPng Working Group Last Call Completed for Experimental

IPv6 Code Points / R. Hinden

Assignments for:

Accepted by IANA
Available on IANA Assigned Numbers Web Site: http://www.iana.org/numbers.html

Carpenter: Important to carefully document IANA<->WG procedures for parameter assignment. Best to do as an RFC with big stamp of approval from the IESG.

Addressing to Draft Standard / R. Hinden

Addressing Documents

Implementation reports available at: ftp://playground.sun.com/pub/ipng/implementation-reports/

Start working group last call for Draft Standard

Implementation reports available. Bob proposes to start last call at this point for advancement of these 2 documents to Draft Standard. No objections.

ACTION: Document editor will start working group last call to move the IPv6 addressing specifications to Draft Standard.

Initial IANA Sub-TLA Assignments / R. Hinden

Regional IP Registries plan to start allocating IPv6 addresses in Q1 1999

RIRs each need initial blocks of Sub-TLA ID's to assign
New draft to propose initial Sub-TLA ID Blocks: "Initial IPv6 Sub-TLA ID Assignments"
<draft-ietf-ipngwg-iana-tla-00.txt>

Background

| 3 | 13 | 13 | 19 | 16 | 64 |
+----+------+-------+---------+------+--------------------------+
| FP | TLA |Sub-TLA| NLA | SLA | Interface ID |
| | ID |ID | ID | ID | |
+----+------+-------+---------+------+--------------------------+

^
|
|

FP = 001 = Format Prefix
TLA ID = 0x0001 = Top-Level Aggregation Identifier

Sub-TLA ID Assignments

Binary Range (Hex) Assignment
---------------- --------------- -------------------
0 0000 00XX XXXX 0x0000 - 0x003F IANA
0 0000 01XX XXXX 0x0040 - 0x007F APNIC
0 0000 10XX XXXX 0x0080 - 0x00BF ARIN
0 0000 11XX XXXX 0x00C0 - 0x00FF RIPE NCC
0 0001 00XX XXXX 0x0100 - 0x013F (future assignment)
0 0001 01XX XXXX 0x0140 - 0x017F (future assignment)
0 0001 10XX XXXX 0x0180 - 0x01BF (future assignment)
0 0001 11XX XXXX 0x01C0 - 0x01FF (future assignment)
0 0010 00XX XXXX 0x0200 - 0x023F (future assignment)
. . .
. . .
. . .
1 1111 11XX XXXX 0x1FC0 - 0x1FFF (future assignment)

Where "X" indicates "0" or "1".

Carpenter: Tuesday night, the IAB sent a request to IANA to assign blocks of sub-tla's to APNIC, ARIN, and RIPE-NCC in the same manner as specified in the draft.

IPv6 6REN Status and Plans / R. Fink

IPv6 Research and Education Networks Initiative

The problem

Where we are

A start

Isn't this just the 6bone?

6REN participation

Work underway

More work

Also of interest
Effort is underway to help Australia and China RENs to develop plans and proposals to provide country-wide production IPv6 service

The Environment Today

+------------+ Direct native IPoverATM
/| Internet 2 | PVC links w/ BGP4+ peering
/ +------------+
/
+-------+ / +------+
| |/ | |
| ESnet |----------------| WIDE |
| |\ | |
+-------+ \ +------+
| \
| \
| \
+-------+ \+-------+
| CA*net| | CAIRN |
+-------+ +-------+

Providing...

Applications and IPv6

Join the 6REN Initiative

Bound: Corporate America doe snot have to wait for Microsoft. There are reasons to deploy now.

IPv6 over IPv4 w/out Explicit Tunnels / B. Carpenter

Working group last call. Draft discussed here and in NGTRANS.

Comments:

Section 7 of document will be removed because it was half baked and draft will be reissued.

ACTION: Document editor to send "IPv6 over IPv4 w/out Explicit Tunnels" to IESG for PS when new draft is out.

Basic API Revision / J. Bound

As soon as new ID is out, DE is submitted for Informational.

ACTION: Document editor to send "Basic API Revision to IESG for informational when new draft is out.

DNS Extension to Support IP Version 6 / Matt Crawford

Document Status

Implementation / Experimentation

Deployment Concerns

Router Renumbering / M. Crawford

Two small sets of IESG comments received

New draft should resolve IESG issues and allow this to move forward.

Jumbograms / S. Deering

It was reported that we now have two interoperable implementations. Can this move to Draft Standard now? Will this satisfy IESG requirements? It was already at proposed when it was part of IPv6 specification. Internet AD answered that it would be better to start at Proposed Standard.

Comment to combine this with TCP/UDP jumbograms to produce one Jumbogram documents. After some discussion, documents authors will decide appropriate approach.

Multicast Listener Discovery Protocol / S. Deering

A new version of the draft is needed. Also, found problem with behavior when query time of zero. Needs to be defined meaning of zero. Zero will mean zero delay.

Deering will issue new draft.

It was noted that is dependent of IPv6 Router Alert.

Concern raised about attack w/ zero value. Need to make sure these messages can not be forwarded from routers.

ACTION: Document Editor will start w.g. last call for "Multicast Listener

Separating Identifiers and Locators in Addresses: An Analysis of the GSE Proposal for IPv6 / L. Zhang, et. al.

History

Current State and Next Step

ACTION: Document editor will issue w.g. last call for publishing

Site Prefixes in Neighbor Discovery / E. Nordmark

Site prefixes in Neighbor Discovery <draft-ietf-ipngwg-site-prefixes-02.txt>

Outline

Model

Model for mobile nodes away from home

Proposal

Prefix option format

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Prefix Length |L|A|R|S|Resvd1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Site PLength | Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

S site prefix flag: Site PLength is valid.

Site PLength: Number of bits in site prefix.

Example

2837:a:b:987:X:Y:W:Z1 2000:1:2:987:X:Y:W:Z1
fec0::987:X:Y:W:Z1 2837:a:b:34:X:Y:W:Z2
2000:1:2:34:X:Y:W:Z2 fec0::34:X:Y:W:Z2
2abc:77:66:23:X:Y:W:Z3

2837:a:b::0/48 2000:1:2::0/48

fec0::987:X:Y:W:Z1 fec0::34:X:Y:W:Z2

2837:a:b:987:X:Y:W:Z1 2000:1:2:987:X:Y:W:Z1
2837:a:b:34:X:Y:W:Z2 2000:1:2:34:X:Y:W:Z2
2abc:77:66:23:X:Y:W:Z3

Question about motivation. Beneficial, if you think internet is not going to renumber, wants to use site local addresses for all internal traffic. Only have external traffic use global addresses. Make internal traffic impervious to renumbering.

Comments:

This is a big deal and makes DNS resolver very complex.

Thinks draft has not been read/understood. Thinks we should do this.
Should we add this to BIND9? Some work in resolver.

Another motivation for this is that site local address are the IPv6 equivalent of "Net10" private address space. Some people think having private addresses are important. This draft helps make this work. llows site to use both private and public with not difficult transition.

Impact of deployment? Can we get all implementations done in timely manner? Requiring two-faced DNS would be a mistake.

Mobile nodes

Home agents

Correspondent nodes

Summary

Questions/Comments:

This works by matching up something in ND messages w/ what is in DNS.
Could also do DNS-DNS matching. Reply: This wouldn't work for Mobile nodes.

Deering: Some people are unhappy with this.

Any impact on firewalls? No

Question about leakage of internal structure of DNS information outside of network.

How would work w/reverse zones. Answer in draft. Can construct reverse addresses

Jim Bound thinks this will help deployment.

Chair took poll to see if having to make resolver changes to support this is too hard. No strong objection. Strong agreement to continue this work.

Future IPv6 Direction / S. Deering

What should happen next? Lots of this we could do? Or not.

What chairs had in mind was to hold an interim IPv6 meeting. Tentatively first week of February. Review state of IPv6 protocols and transition mechanisms. Identify new works, new approaches, etc.

Initial proposal to meet at LBNL in S.F. Bay area. First two day would be combined NGTRANS and IPng first two days. Third day would be coordination, 6REN, 6BONE, etc.

Polled room to see who could attend: Many would attend.

Another proposal to have meeting in Europe or Japan. Possible sponsors should talk to Chairs after meeting.

Editor Note: Subsequent to the meeting it has been announced that the Interim meeting will be held on February 2-4 in Grenoble France. Details sent to IPng and NGTRANS mailing lists.

Mobile IPv6 Status / D. Johnson
<draft-ietf-mobileip-ipv6-07.txt>

Completed w.g. last call and has been submitted to IESG. IETF last call should occur soon.

New Encoding for Operational Information

Unique Identifier Sub-Option

Home Agents List Sub-Option

Dynamic Home Agent Address Discovery Details

Comment: This and RR need to handle "R" bit behavior correctly.

Miscellaneous Changes

Question: Should we put the required part for every host in separate document. Would highlight this functions. Several comments that this is not necessary.

ACTION: Document Editor will produce web page that lists required IPv6 specifications.

Reserved IPv6 Subnet Anycast Addresses / D. Johnson, S. Deering

Previously submitted to IESG for PS. Waiting for IETF last call.

IPv6 TCP and anycast address / Jun-ichiro Itoh

<draft-itojun-ipv6-tcp-to-anycast-00.txt>

Problem in TCP and anycast

Sender Receiver

S R, Anycast A
SYN
_______________
\______________\
/
______________
/_______________/
\ RST

When this situation happens

Proposed Solution

Sender Receiver

S R, Anycast A

SYN
_______________
SYN \______________\
/
______________
/_______________/
\ ICMP addr unreach

Comments: This should not be the behavior. TCP is not supposed to close connections on receipt of ICMP error messages. This error does not usually indicate "permeant" error. BSD is not a good model for this behavior.

Issues

Deering: Was hoping there would be a proposal to change TCP to allow connection initialization using any anycast address. Special option in TCP to allow this. Asked if author interested in creating a TCP option. Reply: Likes idea but think there are security problems to deal with this.

Problem w/ UDP is not a severe as with TCP. Some UDP applications already work w/ multicast. DNS is a problem.

Would like to experiment with this, then submit an internet draft for consideration by the w.g.

RPC and NFS over IPv6 / L. Wu

RPC is supposed to be transport independent. Why would it ever be an issue for RPC over IPv6?

RPC service lookup protocol Overview

+----------------+
+--------+ <program, ver, protocol> | |
| |------------------------->| |
| Client | | Server |
| |<-------------------------| |
+--------+ <port> | |
| |
+----------------+
Version 2:
protocol = 32-bit integer, Port = 32 bit integer
Version 3&4:
protocol = string, port = string

RPC IPv6 Service lookup Issues?

Using PORT MAPPER

or

Editor's Note: in slide, they don't mean changing TCP protocol number, just local identifier inside of implementation for port mapper.

Using RPCBIND

RPCBIND request: <program, version, netid>

tcp6 - for service running TCP over IPv6
udp6 - for service running UCP over IPv6

Enforcing IPv6 service port

Discussion.

RPC API

TS-RPC API

clntudp_create(sockaddr_in *raddr,
rpcprog_t, prog,
rpcvers_t vers,
register int *sockp,
u_int sendsz,
u_int recvsz)

TI-RPC API

SUMMARY

Tunnel Broker / A. Durand

Tunnel Broker / Server

<well known> Web page
+-----+ +-----+ +-----+
| | /| S | | B |\
| | / | | | | \
+-----+ Tunnel / +-----+ +-----+ \ IPv6 target
^ | Broker / +------+
| | +-----+ | |
| | +------>| B | IPv6 netowrk | |
| | / +------| |\ | |
| | / / +-----+ \4 +------+
1 | | 2 3/ / \ \ /
| | / /5 \ V /
| V / / \ +-----+ +-----+ /
+----+ / / \ | | | | /
| |/ / 6 | S | | S |/
| |=======================| | | |
+----+ +-----+ +-----+
Dual stack IPv4 host Tunnel server

The basic idea is to get the address of a tunnel broker from a web page (step 1 & 2), then running a tunnel broker protocol to the tunnel broker (steps 3 & 5) automatically obtain the address (similar to the way DHCP provides addresses) obtain a tunnel endpoint address of a tunnel server (step 6). The tunnel broker would communicate with the tunnel server as part of this process (step 4).

Discussion, many questions.

Plans on experimenting w/ this. Later might need to standardize a tunnel broker protocol.

Brian C: Does this replace 6over4 approach. Reply: No, it is complementary.

Meeting adjourned

Slides

None received.