Current Meeting Report
Slides


2.2.5 IP Version 6 Working Group (ipv6)

NOTE: This charter is a snapshot of the 52nd IETF Meeting in Salt Lake City, Utah USA. It may now be out-of-date. Last Modified: 05-Dec-01
Chair(s):
Bob Hinden <hinden@iprg.nokia.com>
Steve Deering <deering@cisco.com>
Internet Area Director(s):
Thomas Narten <narten@us.ibm.com>
Erik Nordmark <nordmark@eng.sun.com>
Internet Area Advisor:
Thomas Narten <narten@us.ibm.com>
Editor(s):
Bob Hinden <hinden@iprg.nokia.com>
Mailing Lists:
General Discussion:ipng@sunroof.eng.sun.com
To Subscribe: majordomo@sunroof.eng.sun.com
In Body: subscribe ipng
Archive: ftp://playground.sun.com/pub/ipng/mail-archive
Description of Working Group:
IP version 6 or IPv6 (also formerly known as IP Next Generation or IPng) is intended to support the continued growth of the Internet, both in size and capabilities, by offering a greatly increased IP address space and other enhancements over IPv4. The IP Next Generation (IPng) working group was originally chartered by the IESG to implement the recommendations of the IPng Area Directors as outlined at the July 1994 IETF meeting and in "The Recommendation for the IP Next Generation Protocol," RFC1752, January 1995. Most of the tasks in that original charter have been completed, and the core IPv6 protocol specifications are now on the IETF standards track.

This charter focuses on completing the remaining work items and providing a home for IPv6 work that spans multiple IETF working groups. The working group is being renamed the IP Version 6 Working Group (IPv6) because it is a better description of the working group's focus.

The specific working group's ongoing responsibilities are as follows:

- Complete work from the original charter and follow-on work, as outlined below.

- Keep all IPv6 working group documents moving along publication / standardization track.

- Complete work from the original charter and follow-on work, as outlined below.

- Keep all IPv6 working group documents moving along publication / standardization track.

- Serve as a review board and body of competence and coordination for IPv6 architectural issues that span multiple IETF working groups.

- Provide a home for IPv6-related work that doesn't fit in an existing IETF working group and doesn't merit a working group of its own.

- Provide technical input to the IAB, IANA and Internet Address Registries with regard to IPv6 address allocation policies and procedures.

The list of the working group's current work items is as follows:

- Revise and advance to Draft Standard the IPv6 Address Architecture document [RFC 2373]

- Revise IPv6 Aggregatable Unicast Addresses [RFC 2374], removing the policy aspects that are considered RIR issues.

- Complete work on recommended address-selection algorithms

- Revise ICMPv6 spec [RFC 2463] (scope-exceeded err, no error to redirect, editorial)

- Revise Generic Tunneling spec [RFC 2473] (add bidirectional tunnels)

- Update Basic and Advanced API specs [RFC 2553, RFC 2292]

- Complete Scoped Address Architecture spec and any necessary revisions to other working group drafts required to properly implement support for IPv6 address scoping

- Work on host-based solutions to site-multihoming problems (in coordination with multi6)

- Complete work on local IPv6 networking as part of IPv6 plug-and-play (to be coordinated with other WGs as appropriate, e.g., dnsext, zeroconf, etc.)

- Document IPv6 renumbering model

- Complete the IPv6 Node Information Queries spec

- Revise and update the base IPv4/IPv6 MIBs and produce a new consistent set of MIBs that cover IPv4 and IPv6 together. RFCs to be looked at together: 2011, 2012, 2013, 2096, 2851, 2452, 2454, 2465, 2466 and possibly 3019.

New work items not listed above require the approval of the working group and Internet Area directors before they will be taken on by the working group.

The working group would welcome contributions on the following topics this is not an exhaustive list):

- Flow label standardization

- Solutions to other multihoming issues, beyond those specific to site-multihoming

- Integration of autoconfiguration, mobility, DNS, service discovery and other technologies to enhance IPv6 plug-and-play

- IPv6 dial-up issues relating to address assignment, use of Neighbor Discovery, etc. (not including AAA work)

- Specifications for IPv6 over additional media

- Host use of anycast; TCP use of anycast

- Support for multi-link subnets (single subnet spans multiple links)

- Scope-name discovery

- IPv6 protocol extensions to accommodate mobile wireless networks.

Goals and Milestones:
Jul 01   Revise IPv6 Address Architecture and resubmit to IESG for Draft Standard
Jul 01   Revise IPv6 Aggregatable Unicast Addresses and submit for publication as an RFC.
Jul 01   Resubmit the IPv6 Node Information Queries spec
Aug 01   Compete Address Selection specification and submit for Proposed Standard
Dec 01   Update ICMP document and resubmit for Draft Standard
Dec 01   Complete DNS Discovery draft and submit for Proposed Standard
Dec 01   Update Generic Tunneling specification and resubmit for Proposed Standard
Dec 01   Complete updates to Basic and Advanced API specifications and submit for Informational
Mar 02   Complete Scoped Address Architecture and submit for Proposed Standard
May 02   Submit document describing IPv6 renumbering model for Informational.
Internet-Drafts:
No Request For Comments

Current Meeting Report

IPv6 Working Group Minutes
Salt Lake City IETF
December 2001

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

Minutes taken and edited by Bob Hinden

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

[Slides available at http://playground.sun.com/ipng/meetings.html]

AGENDA
-------

TUESDAY, December 11, 2001, 0900-1130

Introduction, Steve Deering
Review Agenda, Steve Deering
Document Status, Bob Hinden
Default Address Selection for IPv6, Brian Zill
Default Router Preferences and More-Specific Routes, Brian Zill
IPv6 Host to Router Load Sharing, Bob Hinden
Redundant Address Deletion when Encapsulating IPv6 in IPv6, Steve Deering
The IPv6 Payload Header, Francis Dupont
Scoped Address Architecture, Tatuya Jinmei
Flow Label Introduction, Steve Deering
An IPv6 Flow Label Specification Proposal, Jarno Rajahalme
Discussion, Steve Deering

THURSDAY, December 13, 2001, 0900-1130

DNS Discovery Problem Statement Review, Steve Deering
DNS Discovery Update, Dave Thaler
Using DHCPv6 for DNS Configuration in Hosts, Ralph Droms
Recommendations for IPv6 in 3GPP Standards, Margaret Wasserman
Minimum IPv6 Functionality for a Cellular Host, John Loughney
IPv6 minimum host requirement for low cost network appliances, Nobuo Okabe
Node Requirements Summary, Steve Deering
Threat Analysis for IPv6 Public Multi-Access Links, James Kempf
Advanced API, Tatuya Jinmei
Host-based IPv6 Multicast Addresses Allocation , Jung-Soo Park

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

Introduction, Steve Deering
Review Agenda, Steve Deering
----------------------------

Steve Deering introduced the meeting and reviewed the agenda. No changes to the agenda.

Document Status, Bob Hinden
---------------------------

[Slides available at http://playground.sun.com/ipng/meetings.html]

RFC's Published
RFC3177 IAB/IESG Recommendations on IPv6 Address Allocations to Sites
RFC3146 Transmission of IPv6 Packets over IEEE 1394 Networks (Proposed Standard)
RFC3178 IPv6 Multihoming Support at Site Exit Routers (Info)

IESG Approved
(none)

IETF Last Call completed
Unicast-Prefix-based IPv6 Multicast Addresses (Proposed)
In final stages of IESG approval (w/ MALLOC draft)
IPv6 Node Information Queries (Proposed)
IESG wants applicability statement on usage


Discussion about Node Information Queries. Internet AD Thomas Narten said that there need to be some sort of applicability document was need because there are multiple ways of doing the same function. Some agreement that separate local/connected document would be useful. Perry said that there isn't a problem. Implementors have figured out what to do currently and are using it now.

Submitted to the IESG
RFC2372 IP Version 6 Addressing Architecture (Draft Standard)
New version submitted (-07), IETF last call soon
Default Address Selection for IPv6 (Proposed)
Under AD review, some issues
A flexible method for managing the assignment of bits of an IPv6 address block (Info)
Needs new draft based on IESG comments
An analysis of IPv6 anycast (Info)
In AD review

IPng Working Group Last Call Completed
(none)

Documents Ready for Working Group Last Call
Internet Control Message Protocol for IPv6 (Draft)
<draft-ietf-ipngwg-icmp-v4-01.txt>
Basic Socket Interface Extensions for IPv6
<draft-ietf-ipngwg-rfc2553bis-04.txt>

W.G. LAST CALL for ICMPv6 ID?
Changes in <draft-ietf-ipngwg-icmp-v3-02.txt> from <-01>

Added token-bucket method as an example rate-limiting mechanism for ICMP error messages, and changed default value for the fixed timer approach, parameter T, from 1 second to 0.5 second.

Added specification that all ICMP error messages shall have exactly 32 bits of type-specific data, so that receivers can reliably find the embedded invoking packet even when they don't recognize the ICMP message Type.

In the description of Destination Unreachable messages, Code 3, added rule prohibiting forwarding of packets back onto point-to-point links from which they were received, if their destination addresses belong to the link itself ("anti-ping-ponging" rule).

Added description of Time Exceeded Code 1 (fragment reassembly timeout).

ACTION: Document editor will start working group last call for Basic API for Informational.

ACTION: Document editor will start working group last call for new ICMPv6 draft for Draft Standard.


Default Address Selection for IPv6, Brian Zill
----------------------------------------------

<draft-ietf-ipngwg-default-addr-select-06.txt>

[Slides available at http://playground.sun.com/ipng/meetings.html]

Open issues:

Durand: Thinks longest match prefix should be limited to 64bit bits. Nordmark: Tie breaker will do. Hain: Problem Can be resolved in other ways. Deering: Doesn't think there is down side to current approach. Thaler: There is no requirement that node know it source address prefix length. Doesn't fit all cases. Zill: Thinks best to leave it as is. Huitema: Host can still be smart if it has more information. Document is for default behavior. Other behaviors are still allowed. Deering: Could add text to show this as an example of what else could be done. Nordmark: Thinks current document should be left alone. It can't be solved with simple text change.

Took poll of working group on making this change. Majority to leave as is, but not large number of people voted. Deering suggested Durand send some proposed text to the list. If there is no objections to text this will be adopted.

Discussion on should source address selection have a final tie-breaker. Bill Mann thought is was useful. Other people disagreed. Deering suggest proposed text be sent to the list. Unless ground swell of support, it will be left out.


Default Router Preferences and More-Specific Routes, Brian Zill
---------------------------------------------------------------

<draft-ietf-ipngwg-router-selection-00.txt>

[Slides available at http://playground.sun.com/ipng/meetings.html]

Open issues:

Probing unreachable routers

Discussion. Wasserman: Thinks need to discuss about how this relates to redirects. Thinks there are security issues that need to be addresses. Incorrect route information might cause traffic to go the wrong way. Issue with RIPng. Isn't sure that this is better than having the hosts implement RIP.

Soliman: Wants some more text in document

Combine with load sharing draft?

Move forward to PS or informational Note: MS shipped this in WinXP

Not ready to last call. Will need new draft.


IPv6 Host to Router Load Sharing, Bob Hinden
--------------------------------------------

<draft-hinden-ipv6-host-load-sharing-01.txt>

[Slides available at http://playground.sun.com/ipng/meetings.html]

Discussion on relationship to ND and address preference draft. Conclusion to go ahead with this as separate draft, make a working group document, and start a w.g. last call after new draft is available.

ACTION: Document editor start a working group last call on "IPv6 Host to Router Load Sharing" when new draft is issued.


Redundant Address Deletion when Encapsulating IPv6 in IPv6, Steve Deering
-----------------------------------------------------------------------------

<draft-deering-ipv6-encap-addr-deletion-00.txt>

[Slides available at http://playground.sun.com/ipng/meetings.html]

Discussion:

Thinks this may be useful, but also need to solve some of the other related problem (like Mobile IPv6 has done). Soliman: Thinks is a useful tool. Do we need to add something how to deal with hosts that don't implement it? Huitema: Might also be used when using IPSEC tunnels. This would then become a simple end-to-end header compression scheme for IPSEC traffic. Discussion on this topic.

Dupont: There is a security issue with using this for transport mode ESP IPSEC. Deering disagreed. Itojun: ESP checksum is calculated before encapsulation. This won't work without changing IPSEC. Will be discussed off-line. Perry: Thinks IPSEC is the third rail of the IETF. It might be dangerous if we touch it. Zill: Security issue with Mobile IPv6 is not related to tunneling. Deering: Is there enough of a benefit to move this forward? Small concerns to keep moving this forward. Keep as an individual submission for now.


The IPv6 Payload Header, Francis Dupont
----------------------------------------

<draft-dupont-ipv6-payload-00.txt>

Presented the idea and its origin: old draft by Robert Elz, and piggy-backing discussion in the mobile-ip mailing-list

Pros & Cons:
+ reduce the number of delays for medium acquisition
+ the "atomicity" argument: if a binding update and a RSVP renegotiation are in the same packet they should be processed in the same time.
- this is a link-layer issue

Wants feed back from w.g. Good idea, bad idea, etc.

Deering: This approach was proposed before and the w.g. choose to not adopt it. The issue comes up when where media access cost is high. If this is motivation, best to handle at level 2, not at IP layer.

Dupont: Agrees, not in favor of his own proposal!

Carpenter: This will break boxes that look inside of packets like firewalls, etc.

Nordmark: Some folks in Mobile IPv6 don't like L2 piggy backing. L2 approach doesn't help with outgoing traffic. Might be useful in some environments or some specific cases. Useful to explore. People who want to use this will need to deal with the issues.

Soliman: Dangerous to combine things that are not related to each other in same packet. They might need different QOS, special handling, etc.

Strong consensus to not continue this work. Dupont will write draft that discusses pros and cons and show why this should not be done.


Scoped Address Architecture, Tatuya Jinmei
------------------------------------------

<draft-ietf-ipngwg-scoping-arch-03.txt>

[Slides available at http://playground.sun.com/ipng/meetings.html]

Discussion:

Discussion about mobility issues. How to represent zones for mobile nodes.

Will need new draft before ready for w.g. last call.


Flow Label Introduction, Steve Deering
--------------------------------------

Introduced flow label discussion. Wants to get a sense of group to see what we should do with flow label. Top level choices are use for:
- original model
- something like current proposal
- just make reserved.

Discussion will be occur after next presentation.


An IPv6 Flow Label Specification Proposal, Jarno Rajahalme
----------------------------------------------------------

<draft-rajahalme-ipv6-flow-label-00.txt>

[Slides available at http://playground.sun.com/ipng/meetings.html]


Discussion, Steve Deering
-------------------------------

Discussion:

Soliman: Is the flow label immutable? How does this relate to security? Only means destination

Callon: Only source host can fill in value, or could router on the path fill in initial value? If used for host-to-host, how many will be used? How will this scale. Also thinks there is merit to not defining all of these bits in the IPv6 header now. A: Thinks the best usage is to replace the current 5-tuple flow classification usage.

Crawford: Thinks it is a problem that we have not defined this field yet. Likes this proposal. Reserving bits in the header won't be useful in backbone routers, only in hosts.

Carpenter: Isn't an author of this draft because didn't have time to work on it, was an author of earlier draft. Likes this approach. Host defining flow label is a good idea. Thinks this is the best approach he has seen at this time. Not clear which choice we should make (using this definition or reserving for the future).

Huitema: Has same dilemma. Overall doesn't think we need to do this now. Better to leave alone for now.

Deering: Added clarification that a router receiving a packet with a zero flow label would just forward it. Overall likes this proposal. Thinks it is an improvement over current text in the document.

Zill: Thinks this is the best proposal for using the flow label he has seen. Likes host based approach. Thinks for at least IPv6 "PR" reason we need to do something now. Need to have some sort of statement on this now. Need a plan for how to proceed.

Callon: Likes S+D approach. Suggested that some bits could be reserved. Given this model we don't need as many bits.

Bound: Thinks very good and is better than current approach. Like S+D approach. This we should adopt as a set of work. Thinks we should do something now. Need to move forward.

Zill: Doesn't think we need to reserve any bits for the future. There isn't too much value in reserving some for the future. We have extension headers. Keeping field at 20 bits will allow sparse usage.

Likes, but thinks intermediate router could set flow label if value was zero. Deering: Problem that host may be using same value for other packets with the same S+D. Intermediate router can't know what flow label values the host is using.

Perry: Admits to being confused. We put this field in because we might need it later. Doesn't understand the need to do this now. Deering: Benefit is this will stop people from doing five tuple classification by looking further into the packet.

Huitema: Preference is to leave it alone for next three years. If do something now, would be better to leave some bits to define different flow label types. Is it possible to have a range of values to be reserved by the IANA?

Narten: Doesn't like argument that we need to define it now because we need to define it now.

Deering polled room: 1) Make field reserved for now, 2) Proceed with this proposal, make w.g. document, etc., 3) Something else

Fairly strong consensus for continuing with this proposal and making it a working group document.



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

THURSDAY, December 13, 2001, 0900-1130 (Grand A), ,

DNS Discovery Problem Statement Review, Steve Deering
-------------------------------

[Slides available at http://playground.sun.com/ipng/meetings.html]

Set context of DNS discovery design team work. Major goals of IPv6 was plug and play. Currently we have plug and play of IP layer parameters using ND and Stateless auto-configuration.

Also have an override mechanisms to use DHCP to get all or additional information.

Long discussion. Many people talking. Service Location Protocol is also available to learn about services. Narten: "Not happy with slant of last bullet on second slide".

Questions about this approach. Does it really capture the problem? Several question about why SLP wasn't used. Suggestion that analysis be advanced to Info RFC to allow more review/comments.

More discussion. No conclusion.


DNS Discovery Update, Dave Thaler
---------------------------------

<draft-ietf-ipngwg-dns-discovery-03.txt>

[Slides available at http://playground.sun.com/ipng/meetings.html]

Reviewed current draft update.

No discussion.


Using DHCPv6 for DNS Configuration in Hosts, Ralph Droms
--------------------------------------------------------

<draft-droms-dnsconfig-dhcpv6-00.txt>

[Slides available at http://playground.sun.com/ipng/meetings.html]

Questions about some of the assertions in the intro, asking to clarify some of the statements.

Nordmark: Cost benefit tradeoffs. Steve points out that without state sharing problem is an improvement. Is this enough of an advantage to be worth the trouble of deploying? Deering agrees. The real question for the w.g. do we need anything beyond DHCP for client configuration?

Soliman: Thinks being able to do discovery and configuration without DHCP servers is good. Has always been a goal of the w.g. Thinks fate sharing is a significant issue with DHCP and other server approaches. Thinks claim that DHCP server can be combined in same box may not be enough. Need to have discovery mechanism in same function (process) as the service. Thinks this is a very important and DHCP doesn't meet this requirement.

Austein: Disagrees about the fate sharing comments. Could put DHCP in same process. It is an implementation issue. Doesn't see that anycast helps with the fate sharing. DHCP approach is better in the long term because it handles other information. DNS is staring to have a dependency on NTP. Doesn't want to define a special configuration mechanisms for every service. Thinks DHCP is a better solution.

Zill: If you send out one of the DHCP information requests. Will one server know all? Narten: Not a problem that you learn an incorrect list of servers.

Suggestion that level 1 compliance is OK. Could use DHCP for level 2.

Huitema: Thinks original requirement as stated by Steve Deering is correct. Limited fate sharing is better approach. Thinks we need a simple solution that work in simple networks. Thinks this DNS discovery approach provides more flexibility the just using DHCP server.

Nordmark: What is the extensibility in each approach? Talking about these as one thing is part of the problem. Could separate anycast to reach server from getting service information.

Deering took poll of room: How many people think w.g. should continue work on stateless DNS discovery? Consensus to continue work.


Recommendations for IPv6 in 3GPP Standards, Margaret Wasserman
--------------------------------------------------------------

<draft-wasserman-3gpp-advice-00.txt>

[Slides available at http://playground.sun.com/ipng/meetings.html]

Polled room to if w.g. wants to accept this as a working group document.

Durand: Thinks /64 issues belongs to registries. Answer: Design team is making a minimal technical recommendation. Shorter prefixes also OK.

Narten: Question about DNS discovery mechanism. Thinks 3GPP will use DHCPv6. Answer: Need some defined answer here. Is this a 3GPP position?

Another comment: Likes document. Concerns about /64 requirements.

Hain: Address selection rules should help use of different prefixes.

Deering queried working group if there was any disagreement about making this a w.g. document. No objection. Document will be adopted as working group item.


Minimum IPv6 Functionality for a Cellular Host, John Loughney
-------------------------------------------------------------

<draft-manyfolks-ipv6-cellular-host-01.txt>

[Slides available at http://playground.sun.com/ipng/meetings.html]

Asked if this should be a w.g. document.

Why is there a dependence on Mobile IPv6? A: Need to be able to be a Mobile IPv6 correspondent node.

Bound: Thought that DHCPv6 was required.

Soliman: Doesn't think the GPRS mechanisms will scale. Also, thinks DNS discovery issues needs to be resolved.

Wasserman: Thinks is an excellent document. Would like to see it as a w.g. document.


IPv6 minimum host requirement for low cost network appliances, Nobuo Okabe
--------------------------------------------------------------------------

<draft-okabe-ipv6-lcna-minreq-00.txt>

[Slides available at http://playground.sun.com/ipng/meetings.html]

No discussion.


Node Requirements Discussion, Steve Deering
----------------------------============---

[Slides available at http://playground.sun.com/ipng/meetings.html]

General need for IPv6 node requirements document. Current approaches are focused on specific devices. Thinks better to focus on documents to meet specific network requirements (e.g., low bandwidth, small amount of memory, etc.).

Wasserman: Suggest take current documents on as informational.

Deering polled group if there was any objections to adopting cellular draft as a working group document. No objections. Group will adopt as a w.g. document.

Will also start effort to work to develop general node requirements document.

John L. volunteered to work on general document.


Threat Analysis for IPv6 Public Multi-Access Links, James Kempf
---------------------------------------------------------------

<draft-kempf-ipng-netaccess-threats-00.txt>

[Slides available at http://playground.sun.com/ipng/meetings.html]

Discussion:

Comment: This work is not specific to IPv6 and should not be in IPv6 w.g.

Comment: Doesn't see advantage of making media look like PPP link as an alternative approach doesn't really help.

Comment: Threats are directed at IPv6 neighbor discovery so is specific to this w.g.

Chairs think this work is important, but don't think it is within the scope of current charter. Need to talk to area directors to see best place for this work.


Advanced API, Tatuya Jinmei
-------------------------------

<draft-ietf-ipngwg-rfc2292bis-03.txt>

[Slides available at http://playground.sun.com/ipng/meetings.html]

No discussion.


Host-based IPv6 Multicast Addresses Allocation , Jung-Soo Park
--------------------------------------------------------------

<draft-park-host-based-mcast-00.txt>

[Slides available at http://playground.sun.com/ipng/meetings.html]

Comments:

Thaler: Current multicast allocation draft is in IESG. Comment from IESG on how it applies to link local. Doesn't see an advantage in current draft. This proposal is better for link local and they could change current draft to not include link local scope. Not so clear what to do with site scope. Thinks this would be OK for site scope multicast address allocation, but needs to check with co-authors. If current authors agree, this could be accepted. Change current draft to make it only apply to scope 6 and above.

Deering: Looks like good approach for limited scope multicast. Needs new draft before can be considered as a w.g. document as well as agreement from current document authors.

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


Slides

Agenda