2.3.6 IPNG (ipngwg)

NOTE: This charter is a snapshot of the 50th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 14-Mar-01

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

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

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

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

RFC3041

PS

Privacy Extensions for Stateless Address Autoconfiguration in IPv6

RFC3019

PS

IP Version 6 Management Information Base for the Multicast Listener Discovery Protocol

Current Meeting Report

IPng Working Group
Minneapolis IETF Meeting
March 19, 22, 2001

Bob Hinden / Nokia
Steve Deering / Cisco
Chairs

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

Agenda

Introduction and Review Agenda / S. Deering (10 min)
Document Status / R. Hinden (10 min)
IPv6 Addressing Documents Issues and Status / Thomas Narten (10 min)
Source/Destination Address Selection / Rich Draves (30 min)
<draft-ietf-ipngwg-default-addr-select-03.txt>
Default Router Preferences & More Specific Routes in RAs / Rich Draves (20 min)
<draft-draves-ipngwg-router-selection-01.txt>
MIB Design Team Report / Bill Fenner (10 min)
An analysis of IPv6 anycast / Jun-ichiro itojun Hagino (10 min)
<draft-itojun-ipv6-anycast-analysis-02.txt>
Host-based Anycast using MLD / Brian Haberman (30 min)
<draft-haberman-ipngwg-host-anycast-00.txt>
Site prefixes in Neighbor Discovery / Erik Nordmark (30 min)
<draft-ietf-ipngwg-site-prefixes-05.txt>
Generic Packet Tunneling in IPv6 - Bi-directional Tunneling / Alex Conta (15 min)
<draft-conta-extensions-ipv6-tunnel-01.txt>
IPv6 Scoped Address Architecture / Steve Deering (10 min)
<draft-ietf-ipngwg-scoping-arch-02.txt>
IPv6 Near-Unique Site-Local Addresses / Paul Francis (20 min)
<draft-francis-ipngwg-unique-site-local-00.txt>
DNS Server Discovery Mechanisms for IPv6 Update / Dave Thaler (15 min)
<draft-ietf-ipngwg-dns-discovery-00.txt>
Multicast Listener Discovery Version 2 (MLDv2) for IPv6 / Luis Costa (10 min)
<draft-vida-mld-v2-00.txt>
IPv6 Flow Label Track (60 min)
Introduction / Steve Deering (10 min)
Flow Transparent Mobility and QoS Support for IPv6-based Wireless Real-time Services / Winston Seah (10 min)
<draft-shen-ipv6-flow-trans-00.txt>
Redefining the IPv6 Flow Label / Alex Conta (15 min)
Flow Label Hybrid "H Compromise" / Jim Bound (15 min)

------------------------------------------
Monday, March 19, 2001 0900-1130 (Salon D)
------------------------------------------

Introduction and Review Agenda / S. Deering
-------------------------------------------

Steve Deering introduced the meeting. Working group still called IPng, will be renamed to IPv6 when new charter is approved.

Presented agenda. No changes.

Document Status / R. Hinden
---------------------------

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

RFC's Published
- RFC3041 Privacy Extensions for Stateless Address Autoconfiguration in IPv6 (Proposed Standard)
- RFC3019 IP Version 6 Management Information Base for the Multicast Listener Discovery Protocol (Proposed Standard)

IESG Approved
(none)

IETF Last Call completed
- Transmission of IPv6 Packets over IEEE 1394 Networks (Proposed Standard)
o Mailing list discussion if IP over IEEE1394 should be revised first.

AD thought document would go forward as is, if IPoverIEEE1394 changes it would apply to IPv6 and IPv4.

- RFC2372 IP Version 6 Addressing Architecture (Draft Standard)
o IESG Report to Follow
- RFC2374 An IPv6 Aggregatable Global Unicast Address Format (Draft Standard)
o IESG Report to Follow
- IPv6 Node Information Queries (Proposed Standard)
o Comments from last call, waiting for updated draft
- Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification (Proposed Standard)
o IESG Comments

AD reported that IESG has approved, but notice had not be sent yet.

Submitted to the IESG
- IPv6 multihoming support at site exit routers (Info)
o IESG wants to move document to Multi6 w.g.
- IPv6 Multihoming with Route Aggregation (Info)
o IESG comments, move to Multi6 w.g.
- Separating Identifiers and Locators in Addresses: An Analysis of the GSE Proposal for IPv6 (Info)
o IESG discussing security issues / conclusions
o New Draft promised for April 2000
o Work in progress, new draft promised for August 2000
o Status???? ????

Authors promised to let w.g. chairs know what the status is.

IPng Working Group Last Call Completed
- Unicast-Prefix-based IPv6 Multicast Addresses (Proposed)
o Ready to submit to IESG

ACTION: Document editor editor will submit "Unicast-Prefix-based IPv6 Multicast Addresses" to IESG for Informational.

- Basic Socket Interface Extensions for IPv6 (Info)
o Hold for updates based on last call comments
- A Method for flexible IPv6 Address Assignment (Info)
o New draft issued as "A flexible method for managing the assignment of bits of an IPv6 address block"
o Ready to submit to IESG

ACTION: Document editor will submit "A flexible method for managing the assignment of bits of an IPv6 address block" to IESG for Informational.

DOCUMENT STATUS
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

Template available at:

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

ACTION: Document editor will send email to implementors requesting implementation reports for these documents.

NEW CHARTER STATUS
- Revised charter submitted to IESG
- Working with Internet AD's to revise

IPv6 Addressing Documents Issues and Status / Thomas Narten
-----------------------------------------------------------

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

Note: Email sent to IPng mailing included here.

To: ipng@sunroof.eng.sun.com
Subject: status of IPng addressing documents
Date: Sun, 18 Mar 2001 21:54:08 -0500
From: Thomas Narten <narten@raleigh.ibm.com>

This note is to summarize some recent discussions concerning a number of IPv6 documents and bring the WG up-to-date on a suggested plan of action.

First, the IESG is currently discussing whether to advance draft-ietf-ipngwg-addr-arch-v3-04.txt (the original ID submitted to the IESG) to draft standard. IESG discussions have resulted in requests for two changes to the document:

a) Section 2.5.6 "Aggregatable Global Unicast Addresses" contains text and a diagram excerpted from a separate document, RFC 2374. That text is deemed inappropriate in a Draft Standard document because:

- the described fields and their widths are not a fundamental part of the IPv6 architecture. Implementations do not (and should not) need to know the format of any of the fields, their widths, etc.
- Putting them in the document can lead people to believe they are fundamental part of the architecture
- The topic of RFC 2374 deals with that portion of address space that is managed by the RIRs, rather than the IETF (more on this below).

IESG request: rework the discussion in Section 2.5.6 to make the reference to RFC 2374 an example, to make it clear that the address allocations and formats in RFC 2374 are not a part of the IPv6 architecture (i.e., have no implications for implementations).

b) The document makes reference to the format prefix (FP). There have been concerns raised that implementations may take the FP into consideration and treat addresses differently depending on their FP (i.e., FP 1 is assigned, while others are unassigned). But for future flexibility, it is important that all implementations process global unicast addresses consistently and predictably, regardless of what the FP is.

IESG request: strengthen/clarify wording in the document to make it clear that all unassigned FPs are to be treated as global unicast addresses.

These requests are editorial in nature and are not expected to affect the document in a way that impacts implementations. Once these changes are made, the document is expected to be approved as a Draft Standard.

Note that version -05 appeared recently; it addresses most of the issues raised. A -06 version, under preparation, is expected to resolve the remaining issues.

While discussing the addressing architecture document, the IESG also discussed RFC 2374. The WG originally asked that this document also be advanced to Draft Standard a couple of years ago, but the IESG pushed back wanting to see more experience. While the IPng WG has not formally asked the IESG to advance this document at this time, there is an assumption that such a request might come once the addressing architecture document had been successfully advanced. Hence, the preliminary discussion on RFC 2374.

The IESG has in previous discussion not had consensus on advancing RFC RFC 2374 ("An IPv6 Aggregatable Global Unicast Address Format"). Over time the specific issues have evolved, as the community has gained more experience from IPv6 testbeds, the RIRs have begun handing out addresses, etc. Some of the current issues that have been raised include:

- there is a lack of clear consensus in the community regarding the exact size of the various fields (TLA vs. NLA, etc.), how permanent the boundaries will be over time, etc. Boundaries that seem appropriate today, may be different in ten or twenty years. As an example, while the limitation of 8192 TLAs is viewed as a laudable goal, it is also not viewed as a hard architectural limit that can/will never change. If the boundaries are subject to change in the future, that argues against the document being advanced on the Standards Track to Draft status.

- there is concern that it does not reflect the current practice of what the addressing registries (RIRs) are doing or will be doing over the next few years (again an argument against advancement to Draft Standard). For example, sub-TLAs are not defined in RFC 2374.

- on matters of address allocations and assignments, the RIRs (and not the IETF) have responsibility for managing and assigning unicast address space to ISPs and end sites. Note that on issues of address boundaries, the further one moves from the right to the left within an address, the greater the role of the RIRs, and lesser the impact on the overall IPv6 architecture. For example, the IPv6 architecture clearly defines the /64 boundary. But the /48 boundary is less clearly required by the architecture, though there are many technical reasons for having it.

- Because the RIRs are are the ones that carry out any recommendations the IETF might make, they need to be in agreement with those policies and incorporate them into their own formal policies. This argues for engaging the RIRs on the topic of address assignments and encouraging them to develop such policies in a cooperative manner with appropriate input from the IETF.

Summary: the IESG is unlikely to advance RFC 2374 on the standards track in its current form, and recommends that the RIRs be approached for their views on this topic and on what recommendations they have for how best to cooperate on reaching a common goal -- that of assigning addresses in a way that encourages deployment and supports the IPv6 vision and architecture. Should the RIRs be willing to formally take up this topic, it is expected (and imperative!) that the IETF provide technical input.

Note that moving the policy component to the RIRs is not expected to result in any change in current assignments and operations in the short term, but one can expect assignment policy to evolve over time. Any such changes would be the subject of extensive review by the IETF and RIR communities. The exact details of how to do this need to be worked out through discussions between the IETF and RIRs.

A third document, draft-iesg-ipv6-addressing-recommendations-00.txt recently appeared. This document is a revised version of a statement issued by the IESG/IAB in September, 2000. The focus of the document is to provide a strong case that that the default IPv6 address allocation to end sites should be a /48. The reason for publishing the document is to refine and clarify the statement and eventually publish it as an informational RFC (i.e., for the historical record). The purpose of this statement is to provide input to the RIRs, as they formulate their IPv6 address assignment policies.

Thomas

Discussion:

Jim Bound asked what the chairs thought about this. Chairs agreed with the general approach (e.g., registries own assignment and policy, IETF owns architecture). Jim thought this was good because the implementors could talk to the registries directly.

What will be next step for the aggregatable document? Need to figure out what next step is. There will be some sort of new document, it might be two document one focused on technical the other on policy.

Source/Destination Address Selection / Rich Draves
<draft-ietf-ipngwg-default-addr-select-03.txt>
--------------------------------------------------

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

Issues:

- Configuration mechanisms and default treatment for mobility and privacy
preferences.
o Home vs. care-of-address
o Temporary vs. public addresses

- Current draft says:
o Prefer home address over care of address
o Prefer temporary address over public address
o Configure via socket option (but does not preclude other approaches)

What about mobility if mobile starts at home with site local address?
Thinks is not a problem. Needs to verify in spec.

Question about destination selection for correspondent nodes. Should bean issue because this only comes into play when there are more than one address to choose from.

Jim Bound thinks this shouldn't be a standard, should be informational.

Thinks is policy. This should be suggested recommendation, not default.

Draves: Thinks this document does have implementation requirements. "Must" requirement have implementation consequences.

Bound: Doesn't agree with some of the choices (e.g., selection of site scope as source to send to global destination).

Nordmark: Concern about temporary addresses. Seems wrong to make it the general requirement. Should be more application specific. Safest to have it driven by application. While the current approach works for some application (e.g., web browser), it might break other applications. There may not be reverse lookups for temporary addresses. Could register these addresses, but would require names to be created. Seems unlikely that this would happen (i.e., they are temporary).

Nordmark: Thinks this should be standards track. Splitting between must and should.

Does this cover mobility requirements.

Carpenter: Temporary addresses. Won't work for server farms. Thinks "should" in this case needs to very a very week "should".

Should this draft support applications that know how to handle multiple source and destination addresses? Could be added.

Crawford: Thinks what happens if first set of selected addresses doesn't work. Would be good if draft mentions this.

Tony Hain: Could also add discussion about server situations.

Deering: Important that all implementations support both client and server functionality. Should treat them as different machines. Leans toward changing default to be to use global address instead to temporary address.

Default Router Preferences & More Specific Routes in RAs / Rich Draves
<draft-draves-ipngwg-router-selection-01.txt>
-----------------------------------------------------------------------

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

What next: Progress towards proposed standard, informational, experimental?

IANA assignment to type?

Comment:

Thinks first usage scenarios (home user creates VPN into corp network] is bad security policy.

Deering: This idea of adding more routing information is in general problematic, but thinks this draft addresses issues he is concerned about.

Deering: Draft specifies four types of hosts. Doesn't understand what fourth does. May not be needed.

Carpenter: Thinks operations people won't like pushing routing information into hosts. He likes it in principal, but may be objections.

Nordmark: Does the document talk about any limit on number of prefixes. It would be good to add advice to keep from sending a complete routing table using this mechanism.

JI: Host does make routing decision, that doesn't make it a router.
Operations people should object to this approach.

Deering took room poll. Some preference that this is a good thing. We should talk to operations community, but looks like we can adopt as a working group document.

ACTION: Make "Default Router Preferences & More Specific Routes in RAs" an IPng working group document.

MIB Design Team Report / Bill Fenner
------------------------------------

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

First revisions of IPv6 MIB has been published as internet drafts.

<draft-ops-rfc2011-update-00.txt>
<draft-ops-rfc2012-update-00.txt>
<draft-ops-rfc2013-update-00.txt>
<draft-ops-rfc2096-update-00.txt>
<draft-ietf-ops-rfc2851-update-00.txt>

No comments on presentation.

An analysis of IPv6 anycast / Jun-ichiro itojun Hagino
<draft-itojun-ipv6-anycast-analysis-02.txt>
------------------------------------------------------

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

Perkins: Thought draft should deal with applications passing information between members of an anycast address group. No, this only deals with IP layer delivery. Would like members of anycast group to synchronize their state to allow things like IPSEC to work for anycast.

Deering: Justification for rule why only routers is correct but reason is wrong. Correct reason is that there is no defined way for hosts to join an anycast group.

More discussion about how to use IPSEC w/ anycast.

Discussion if should it be a working group document. Will make a working group document.

ACTION: Make "An analysis of IPv6 anycast" an IPng working group document.

Host-based Anycast using MLD / Brian Haberman
<draft-haberman-ipngwg-host-anycast-00.txt>
----------------------------------------------

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

Open issues:

- More security
- Anycast architecture
o anycast routing
o anycast group delegation
o etc...
- where does document live?
o IPNG WG?
o Anycast WG?

Deering: Disappointed w/ document. Security & authentication is hard problem and document did not address it. If goal is to make it easy to join anycast group, there needs to be a way to control access to a group. Manual configuration of routers will suffice for now. Security community may have real solution by the time we will need it.

Dave T: Should this be combined with MLDv2 document. Might be good but might require MLDv2 to be renamed.

Not clear where this work should live. An anycast architecture document might be needed. Not sure it should be in IPNG w.g. or in it's own w.g. Need to discuss w/ Internet AD's. May also applies to Jun-ichiro itojun Hagino anycast document.

ACTION: IPng chairs discuss with Internet AD's where anycast work should be done in the IETF. IPng, new Anycast w.g., etc.

Site prefixes in Neighbor Discovery / Erik Nordmark
<draft-ietf-ipngwg-site-prefixes-05.txt>
---------------------------------------------------

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

Discussion:

For Mobile IP, what about multicast that originated in site. What should it mandate?

What are boundaries that this should work for unicast and multicast.
This is an architectural issue for this work.

There could be a scenario where you are never in home site and always visiting.

Discussion about how this works in mobile IP environment. Need to figure out what we should do about mobility.

Site locals using ICMP lookups: Adding extra packet exchanges to determine if site local seems like a bad idea. Introduces extra latency.
Security would also be a problem.

Next steps:
- In DNS or not?
- ICMP name lookups security?
- Or should we give up trying to solve this problem?
- Mobile IP requirements?

Why is multi-faced DNS last resort solution? Doesn't scale well down to small sites and small home/office environment.

Will be hard to keep site local addresses out of DNS. Might as well deal with it. Rich Draves: Microsoft implementation will register site local address in DNS. Prefers current DNS approach.

Deering: Suggests that we should limit the usage of site local to just for communication inside of a site. Need to resolve this issue before can address other issues.

What should we do? Nordmark thinks we should continue fleshing out DNS approach. Not sure what to do about Mobile IP. Answer come from IPv6 scoped address architecture document? Dupont said that he will have a new proposal that deals with the Mobile IP issues soon.

Perkins: Thinks working group should set goals what this work should be doing.

Deering agreed that using the scoped address arch document would be a good approach to resolve issue.

--------------------------------------------
Thursday, March 22, 2001 1530-1730 (Salon D)
--------------------------------------------

Announcements:
--------------

Bob Hinden asked the working group for feedback on how the working group chairs are doing chairing the w.g. They have been chairing the w.g. for a long time and wanted to find out how the working group members thought they were doing. Email can be sent to them directly at <hinden@iprg.nokia.com> and deering@cisco.com>, or the Internet AD's at <narten@raleigh.ibm.com> and <Erik.Nordmark@eng.sun.com>.

Interim Meeting
---------------

Chairs announced Interim meeting to be held on May 30, 31, June 1, 2001. It will be located at Microsoft in Redmond, Washington, US. Part of the meeting will include a joint meeting with some people from 3GPP. More details and local arrangements will be sent to IPng mailing list.

IPv6 Usage at IETF 50 / Jun-ichiro itojun Hagino
------------------------------------------------

Jun-ichiro itojun Hagino showed a slide that number of reachable IPv6 nodes on the wireless and wired segments at the IETF meeting. It should a peak reachable of 68 nodes. This is about 6-7% of the overall hosts being used at the meeting.

For more details see: http://www.kame.net/ietf50/

Generic Packet Tunneling in IPv6 - Bi-directional Tunneling / Alex Conta
<draft-conta-extensions-ipv6-tunnel-01.txt>
-------------------------------------------------------------------------

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

Deering: Thinks motivation for header checksum in tunnel header is weak. Better to handle w/ link CRC. For links that doesn't support this, it can be handled with a shim layer. Another suggestion that link layers should do this. Another most link layers that are flaky will have error detection. Thinks it is good to assume L2 detects link errors.

Deering suggested that part of this work (locking down intermediate hops of bi-directional tunnels) could also be considered in the new sub-ip area in the IETF. Relevant issue is wanting to control the intermediate points in the path. Conta think this would go along with the rest of the IPv6 tunneling mechanisms and is an extension to that work.

Another view this is more of an application of an existing protocol and not a new protocol. It would be appropriate for the sub-ip area.

Narten: Thinks CCAMP (SP?) w.g. would be good place to look at this work. If traffic engineering is main motivation, talk to CCAMP to see if this fits within their scope.

IPv6 Scoped Address Architecture / Steve Deering
<draft-ietf-ipngwg-scoping-arch-02.txt>
------------------------------------------------

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

Major change in new draft was to incorporate "%" scope notation, expanded specification of zone indices, changed node-local to interface-local, plus many smaller changes.

Comment that document doesn't adequately describe how numbering space for all zones works. Needs to more specific. Deering said he was aware of problem and it could be fixed by making zone index specific to the scope of the address. For example change the zone ID to be a 32bit integer and determining zone scope form address's scope.

Nordmark suggest it would also be good to clean up API document regarding scopes to make it consistent.

New draft will be needed, not ready for w.g. last call.

IPv6 Near-Unique Site-Local Addresses / Paul Francis
<draft-francis-ipngwg-unique-site-local-00.txt>
----------------------------------------------------

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

Proposing to make site local prefixes non-local by adding a random number to "zeros part" in site local addresses.

Now thinks that this doesn't help with the main problems stated in the draft. When merging sites, half will still have to renumber. Not any different from using the current site local prefix. In both cases some of the subnets will have to be renumbered.

Crawford: Not quite as bad. When merging each half could maintain their original unique prefixes.

Deering noted that notion of sites is not whole companies. More like a notion of a campus. He also thinks we should think about non-routable global address space. Thinks there may need for that. Something like a special TLA that ISP's will never route in the global Internet.

Alain Durand, think this is unnecessary as we have lots of global addresses and we don't need to create way to use local addresses for non-local communication.

Additional discussion.

DNS Server Discovery Mechanisms for IPv6 Update / Dave Thaler
<draft-ietf-ipngwg-dns-discovery-00.txt>
--------------------------------------------------------------

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

Presented update of work of dns discovery design team. Work focused on format of messages used for anycast DNS discovery.

Team achieved rough consensus on recommendation.

Recommendation is to use DNS SRV record format. Can be done in one message exchange, with out changing DNS servers, and can be done with out DNSEXT w.g work. Can also use statefull configuration bit in RA's to turn on and off.

Will update current draft so document new recommendation and then write up proposal as an independent internet draft. Both should be come working group documents.

Question about how will the domain name be conveyed. What is the minimum amount of state that a device needs. Proposal will provide domain suffix, not host name.

Multicast Listener Discovery Version 2 (MLDv2) for IPv6 / Luis Costa
<draft-vida-mld-v2-00.txt>
--------------------------------------------------------------------

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

Current status of version two of MLD for IPv6. Translation of IGMPv2 for IPv6.

Currently an individual submission. Should it go to IPNG or MAGMA.
Should it fusion with "Host based anycast using MLD"?

Deering suggested that it would be good if MAGMA w.g. was willing to take it on. No dissent.

IPv6 Flow Label Track
----------------------
----------------------

Introduction / Steve Deering
----------------------------

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

Steve Deering gave introduction. Desire to pin down how we are going to use the flow label field. People are starting to design hardware and need to know what usage to design around.

Choices are:

- Complete standardization of the original spec (appendix of RFC2460)
- Specify and standardize a different usage
- Continue to leave it unspecified.

Trying to restart discussion on topic. Need to have discussion on the mailing list and at interim meeting.

Short discussion. No conclusions.

Flow Transparent Mobility and QoS Support for IPv6-based Wireless Real-time Services / Winston Seah (10 min)
<draft-shen-ipv6-flow-trans-00.txt>
---------------------------------

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

Speaker was not able to travel to IETF. Talk not given.

Redefining the IPv6 Flow Label / Alex Conta
-------------------------------------------

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

Speaker was not able to give talk because he had to leave early to catch a flight. Talk not given.

Flow Label Hybrid "H Compromise" / Jim Bound
--------------------------------------------

Agrees with Steve position. Would prefer to compromise and support both end-to-end and hop-by-hop modes.

Left most bit of flow label
0 == Router owns it
1 == End-to-End owns it (immutable)

End-to-End == Phone call (VoIP)
- End-to-End identification
- End-to-End PCB lookup advantage
- Need checksum

Router-Router
- RIB + FIB identifier
- Indirection to MPLS label

Need to do what Erik Nordmark asked to determine the problem and requirements.

Matt Crawford: Doesn't see to much gain in hybrid scheme. Doesn't save that much work in a router.

One argument to be used against the hop-by-hop approach is that MPLS uses it's own header.

Carpenter: Heard from Fred Baker that this not an important for MPLS. Doesn't think important for diff service, but is useful in integrated services. Doesn't see need for dividing the space. Just use w/ RSVP.

Narten: Doesn't think we need to do anything now. We should wait until there is an application and implementation that shows it can be used constructively.

Hinden: Think if we specified what a flow was and how to put bits in it that identified the flow, it would be used in applications that want to use flows. This is independent of QOS.

Discussion.

Another use for flow classification. For multipath work it is useful to keep packets in the correct order. Having a random number would help. Even for best effort service.

Deering: Alex Conta was going to propose [had to leave early] putting some of the port numbers and protocol ID in the flow label. Other idea was to use it a pointer to point to these filed in the packet.

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

Slides

Agenda