2.3.7 IPNG (ipngwg)

NOTE: This charter is a snapshot of the 51st IETF Meeting in London, England. It may now be out-of-date. Last Modified: 31-Jul-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

RFC3122

PS

Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification

Current Meeting Report

IPv6 Working Group Meeting Minutes
London IETF
August 8 & 10, 2001

Chairs:
Bob Hinden / Nokia
Steve Deering / Cisco

Meeting minutes taken and edited by Bob Hinden

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

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

Agenda:

Introduction / Steve Deering (5 min)
Review Agenda / Steve Deering (5 min)
Document & Charter Status / Bob Hinden (10 min)
3GPP-IETF Design team status / Bob Hinden (10 min)
Requirements for IPv6 dialup operation / Jun-ichiro itojun Hagino (15 min)
(draft-itojun-ipv6-dialup-requirement-01.txt)
Avoiding ping-pong packets on point-to-point links / Jun-ichiro itojun Hagino (10 min)
(draft-ietf-ipngwg-p2p-pingpong-00.txt)
Multilink Subnets / Dave Thaler (20 min)
(draft-thaler-ipngwg-multilink-subnets-01.txt)
DHCPv6 Status and Last Call / Ralph Droms (10 min)
Minimum IPv6 Functionality for a Cellular Host / John Loughney (25 min)
(draft-manyfolks-ipv6-cellular-host-00.txt)
AAAv6 Status / Charlie Perkins (5 min)
(draft-perkins-aaav6-04.txt)
IPv6 Site Renumbering / Christian Huitema (20 min)
(draft-huitema-ipv6-renumber-00.txt)
Source/Destination Address Selection / Brian Zill (15 min)
(draft-ietf-ipngwg-default-addr-select-05.txt)
Domain Name Auto-Registration for Plugged-in IPv6 Nodes / Hiroshi Kitamura (15 min)
(draft-kitamura-ipv6-name-auto-reg-00.txt)
A proposal for the IPv6 Flow Label Specification / Alex Conta (30 min)
(draft-conta-ipv6-flow-label-02.txt)
DNS Discovery / Dave Thaler (20 min)
(draft-ietf-ipngwg-dns-discovery-01.txt)
(draft-ietf-ipngwg-dns-discovery-analysis-00.txt)
An analysis of IPv6 anycast / Jun-ichiro itojun Hagino (10 min)
(draft-ietf-ipngwg-ipv6-anycast-analysis-00.txt)
Disconnecting TCP connection toward IPv6 anycast address / Jun-ichiro itojun Hagino (10 min)
(draft-itojun-ipv6-tcp-to-anycast-01.txt)
IPv6 MIB Update Status / Bill Fenner (15 min)
(draft-ietf-ipngwg-rfcnnnn-update-00.txt) nnnn=2096,2011,2012,2013
Socket API for IPv6 traffic class field / Jun-ichiro itojun Hagino (5min)
(draft-itojun-ipv6-tclass-api-03.txt)
Status of Linux and USAGI IPv6 / Yuji Sekiya (5 min)

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

WEDNESDAY, August 8, 2001 1300-1500
------------------------------------

Introduction / Steve Deering
Review Agenda / Steve Deering
-----------------------------

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

Steve Deering introduced meeting and reviewed agenda.

Document & Charter Status / Bob Hinden
--------------------------------------

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

DOCUMENT STATUS

RFC's Published
RFC3122 Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification (Proposed Standard)

IESG Approved
Transmission of IPv6 Packets over IEEE 1394 Networks (Proposed Standard)

IETF Last Call completed
RFC2372 IP Version 6 Addressing Architecture (Draft Standard)
New version submitted (-06), waiting for IESG response
RFC2374 An IPv6 Aggregatable Global Unicast Address Format (Draft Standard)
Revision underway
IPv6 Node Information Queries (Proposed Standard)
Updated draft issued, check for consistency w/ Multicast DNS and DNS
Discovery, then new IETF last call will be started

Submitted to the IESG
Unicast-Prefix-based IPv6 Multicast Addresses (Proposed)
In IETF Last Call
A flexible method for managing the assignment of bits of an IPv6 address block (Informational)
Undergoing IESG review, some comments expected
IPv6 multihoming support at site exit routers (Info)
Pseudo-last call in Multi6, then to IESG, expected to be published
IPv6 Multihoming with Route Aggregation (Info)
Contact author, if interest, submit to Multi6

IPng Working Group Last Call Completed
Default Address Selection for IPv6
New draft based on w.g. comments, to be discussed at w.g. meetings
Open issue standard track, Must/Should, etc.
Basic Socket Interface Extensions for IPv6 (Info)
On hold for updates based on last call comments

Documents Ready for Working Group Last Call
Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification (Draft standard)
(draft-ietf-ipngwg-icmp-v3-01.txt)

Discussion:

A couple comments have been received on latest draft. Will start WG last call to solicit any additional comments and then submit to IESG.

[Editor's note: Based on later discussion, the w.g. last call will be deferred until after a new version of the draft is published with additional text]

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 CHARTER STATUS
- Revised charter submitted to IESG
- New Charter approved!
o Official announcement after London IETF
- Working group name changed from:

- Updated work items, milestones, etc.

WORK ITEMS
- 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

GOALS AND MILESTONES
Jun 2001 Revise IPv6 Address Architecture and resubmit to IESG for Draft Standard
Jul 2001 Revise IPv6 Aggregatable Unicast Addresses and submit to IESG
Jul 2001 Resubmit the IPv6 Node Information Queries spec
Aug 2001 Compete Address Selection specification and submit for Proposed Standard
Dec 2001 Update ICMP document and resubmit for Draft Standard
Dec 2001 Complete DNS Discovery draft and submit for Proposed Standard
Dec 2001 Update Generic Tunneling specification and resubmit for Proposed Standard
Dec 2001 Complete updates to Basic and Advanced API specifications and submit for Informational
Mar 2002 Complete Scoped Address Architecture and submit for Proposed Standard
May 2002 Submit document describing IPv6 renumbering model for Informational.

3GPP-IETF Design team status / Bob Hinden
-----------------------------------------

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

BACKGROUND
- Output of joint IPng w.g. and 3GPP session at interim meeting in Redmond
- Goals
o Review 3GPP's current usage of IPv6 and make recommendation for improvements
o Write ID to be submitted to IPv6 w.g.
- Non-Goals
o Redesign of 3GPP architecture / protocols
o Non-Goal example: Change 3G mobility to use Mobile IPv6

MEMBERS
- Bob Hinden (Chair)
- Steve Deering
- Karim El-Malki
- Paul Francis
- Christian Huitema
- Niall Richard Murphy
- Thomas Narten
- Erik Nordmark
- Markku Savela
- Jonne Soininen
- Margaret Wasserman (Document editor)

TOPICS
- Allow use of standard IPv6 implementations
- Addressing
o Single address per PDP context (current)
o Prefix per PDP context
- Per device
- same prefix for all PDP context's for same device
- shared among PDP context's for many devices
o Node able to create multiple addresses
o Static or temporary IPv6 addresses

TOPICS (CONTUNED)
- Model for support of devices behind handset
o Router, bridge, proxy
- DNS
o Locating a DNS server
o Handset address in DNS
- Security
- MTU
- Issues left to implementers in 3GPP specifications

TOPICS (CONTUNED)
- Transition
o IPv6 only, dual stack, etc
o Communication with IPv4 internet
- Remote Management
o MIB support

Multilink Subnets / Dave Thaler
(draft-thaler-ipngwg-multilink-subnets-01.txt)
-------------------------------------------------

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

Discussion:

"Transmit" means not forwarding between different subnets, but does allow multi-link forwarding.

Need to mention in draft if in the future we are able add security to ND, this might have issues.

Thaler proposes to describe simple and complex in main draft, but only specify simple behavior. Would like this draft to become a working group document. Continue complex work in a separate document.

Nordmark: There might be issues about learning about looping topologies. Current ND default advertisements might be too slow.

Deering: Looks good. Wants it to not have any configuration.

Comment: Site typically have IPv4 subnets. How does this relate to this?

Thinks it might make it match and not diverge. Also, is this a sub-ip effort. Prefers to do this at the IP level.

Wasserman: How does the router figure out how router learns about hosts on a link. Send ND on both links and learn answer. Also, is this different from proxy arp. Not significantly different, but proxy Arp doesn't allow multiple levels.

Deering took poll if this should become a w.g. draft. Rough consensus to become a working group draft.

ACTION: Next version of "Multilink Subnets" should be published as a working group draft.

Requirements for IPv6 dialup operation / Jun-ichiro itojun Hagino
(draft-itojun-ipv6-dialup-requirement-01.txt)
-----------------------------------------------------------------

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

What is experience so far with dialup support in IIJ? Problem is that can not deploy dialup nationwide in IIJ.

What are speakers preference of different options? Five different options. Not sure what is best. There are different scenarios that are appropriate.

Deering: Good to get feedback from operational folks. Itojun: Has asked Japan operators forum.

Can this be a w.g. item. Chairs thought it should be standards track. Not sure it should be IPv6. Need to discuss.

ACTION: Chairs to talk to area directors to see what is best w.g. to take dialup operation requirements and move it forward onto standards track.

Avoiding ping-pong packets on point-to-point links / Jun-ichiro itojun Hagino
(draft-ietf-ipngwg-p2p-pingpong-00.txt)
----------------------------------------------------------------------

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

Perry: This function needs to be a MUST. We need to make our equipment more robust. This is showing in IPv4 due to the CODE RED attacks where the attack is sending packets to random addresses. Packets will loop on point-point link with IPv4. This is creating a lot of needless load on routers.

Deering: Thought this behavior should go into ICMPv6 specification.

Perry: Should this also be done for IPv4? Yes, but this needs to be done elsewhere in the IETF.

Is this limited to other types of link. No, this is only need on links where address resolution is not needed. Usually this means only point-to-point links.

Deering took poll to see if this should be added to ICMP draft and be a MUST requirement. Consensus to do this.

ACTION: Deering to add rules to prevent ping-pong packets on point-to-point links to ICMPv6 draft.

ACTION: Once new draft IPCMPv6 draft with new text on "ping-pong" packet rules is completed, Document editor will start a working group for Draft Call (cycle in place).

DHCPv6 Status and Last Call / Ralph Droms
-----------------------------------------

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

Expect to have new draft (-20) completed before the end of August and submit to w.g. last call afterwards. Wants IPv6 w.g. review as part of last call. Will also post announcement to ipng mailing list.

Minimum IPv6 Functionality for a Cellular Host / John Loughney
(draft-manyfolks-ipv6-cellular-host-00.txt)
--------------------------------------------------------------

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

Comments:

Deering mention real issues are not that devices that are cellular and wireless, but that links are "expensive to use". Better approach is to describe by type of link as appropriate. Other issues might be memory limited. etc.

Metzger: Need to also discuss DOS attacks. Is in document, know it is an important attack.

Hesshim: Questions about meaning of intra-domain.

Overall authors are Looking for comments from w.g. Can this be considered as a w.g. draft?

Questions:

Perkins: What is the relationship to design team? Thinks this spec is more immediate work than what the design team is focused on. Also, what is requirement for how much IPsec is needed? Plans to talk to IESG security ADs.

Was QOS or voice service included in the draft. Thinks it is not IPv6 specific so did not include in this draft.

Wasserman: Thinks the design team is trying to do something quickly.

Also, isn't this the start of an IPv6 host requirement document? Yes, it could be.

Soininen: Thinks this document is important. Design team should review document and provide comments to authors.

Why was AAA not included? Thinks authentication is important.

Comment that this is a useful draft, but see it separate from design team.

Deering thinks this we need to think about if it should be generalized or just focused on cellular before we can think about making it into a w.g. document.

Socket API for IPv6 traffic class field / Jun-ichiro itojun Hagino
(draft-itojun-ipv6-tclass-api-03.txt)
------------------------------------------------------------------

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

Want to know how to proceed. Add to current API document or be a separate document.

Nordmark: There is work going to update "Advanced Sockets API for IPv6".

How to get consensus on changes?

Discussion. Should be in advanced API update. No disagreement from w.g. about adding it to advanced API. Deering took poll. Will be added to advanced API update.

AAAv6 Status / Charlie Perkins
(draft-perkins-aaav6-04.txt)
-------------------------------

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

Wants IPv6 w.g. to take a look at new AAA document. Does IPv6 w.g. think this should this work go forward into AAA w.g.?

Chairs don't think this is IPv6 specific. W.g. thinks this work should go on but not in IPv6 w.g.

Hinden suggested that Perkins send email to list describing problem and ask opinion on open issues. It is important to get feedback from the IPng w.g.

FRIDAY, August 10, 2001 0900-1130
-----------------------------------

IPv6 Site Renumbering / Christian Huitema
(draft-huitema-ipv6-renumber-00.txt)
-----------------------------------------

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

Wants to get agreement on renumbering scenarios and then do a detailed analysis of each scenario to make sure we have the right tools to make these scenarios work. Then develop missing tools, publish as a BCP, etc.

Demonstrate at IETF, Interop, etc.

Discussion: Itojun: Important to also specify times, frequency, etc.

Deering: Multi6 has defined some of these scenarios as part of multihoming. Some of these scenarios can be handled with multihoming mechanisms. Also, thinks it is hard to enumerate all of the places that configure IP addresses. Bill Manning: Almost identical to what the pier w.g. was trying to do. Missing network management. Need to also fix MIBs to work without IP addresses. IP address is the identifier. Thinks this is hard to change.

No clear consensus as to how much renumbering is good or how automatically it should be. Author will continue working in this area.

Discussion: lots of different views as to merits of renumbering.

AD-Hoc Interop Test Report / Brian Zill
---------------------------------------

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

~20 people, 7 implementers
12 subnets, 4 different routers
Tested:
ND over configured tunnels (no defined v4 LL options)
Node information queries
ISATAP
Dynamic NDS registration of AAAA
DNS v4/v6 self proxy
RIPng
ping-pong problem on point-to-point links

Source/Destination Address Selection / Brian Zill
(draft-ietf-ipngwg-default-addr-select-05.txt)
-------------------------------------------------

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

Reviewed open issues in draft.

Discussion:

Deering: There was a discussion after the interim meeting presentation on MUST vs. SHOULDS. Thinks it might be better to split document between protocol and policies. Zill: Disagrees, in current draft the MUSTs are there to make sure it interoperates. The issue probably relates to the SHOULDs. Thinks it would be hard to separate these things outside of draft. Narten: Suggested that the document should call out that implementers should be aware that some of the SHOULDs may change and they need to make sure that their implementations can change later if necessary. Nordmark: Would like to keep to a single document.

More discussion.

Deering: Any objections to keeping as single document? May need to restructure later when moving to Draft. General consensus on keeping as single document and advancing to proposed standard.

ACTION: Document editor will submit "Source/Destination Address Selection" to IESG for Proposed Standard when new draft is published.

Domain Name Auto-Registration for Plugged-in IPv6 Nodes / Hiroshi Kitamura
(draft-kitamura-ipv6-name-auto-reg-00.txt)
------------------------------------------------------------------

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

Discussion:

Gudmundsson: Likes what this is trying to do. One problem, DNS will get filled up with lots of garbage if you have lots of visiting nodes. Thinks part of this draft should be handled in DNS-EXT w.g. People in DNS community also have strong opinions on who can register information in DNS.

Zill: Thinks DNS discovery draft provides DNS name search. Doesn't like the approach in this draft because it adds too many boxes. We are trying to make IPv6 work w/ less boxes.

There may be a problem with multiple zones sharing same link?

Nodes do not want their temporary addresses registered in DNS.

Deering: Thinks work would be better handled in DNSEXT w.g. Need to talk to chairs. No action for IPv6 w.g. at this time.

A proposal for the IPv6 Flow Label Specification / Alex Conta
(draft-conta-ipv6-flow-label-02.txt)
--------------------------------------------------------------

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

Questions: Why is this needed given we already have a "class" field in IPv6.

A: This would allow classifying of finer grained flows that diff serv can do currently.

How do you know that information node is putting correct information in the field? It could be lying. This is different from what nodes can do today and it makes it easier to have a flow label that gets better performance than the use of the ports would allow (without both ends cooperating).

Deering: Proposing to change the flow label field to allow router to set the class field in the header. This is a layer violation. Thinks this will create many unanticipated consequences. What you are trying to achieve can be done in simpler ways. Use class field to identify type of service and flow label to identify individual flows. Discussion.

Disagreement about cost of handling random flow labels vs. this proposal.

Discussion.....

Comment that if there was a need to have port number in IP header, then we would have put them in the first place. As long as some sort of signaling is needed to install state in routers, then the current flow label definition is OK.

Further discussion on mailing list.

DNS Discovery / Dave Thaler
(draft-ietf-ipngwg-dns-discovery-01.txt)
(draft-ietf-ipngwg-dns-discovery-analysis-00.txt)
----------------------------------------------------

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

Changed use of SRV DNS record to TXT records.

Questions about having multiple domains on the link. Not handled in current proposal.

Narten: Nervous about using text records. Doesn't think TXT records are uniformly implemented.

Wasserman: Why is this using site anycast? How to find DNS server in ISP? A: This is covered in the draft as how to have the site router proxy to the ISP.

Matt Crawford: Draft is currently assuming that the subnet boundary is a multiple of four bits. Might need finer grained queries. Should be addressed in draft. Discussion.

Austein: Please do not use TXT. Not good to standardize. Better to have new record type.

Erik G: Suggestion that we make the use of TXT record a standard for this usage. Rob: Heading down road of standardizing general format that will encourage considerable conflicting abuse.

Continue work, but needs more work to get convergence.

An analysis of IPv6 anycast / Jun-ichiro itojun Hagino
(draft-ietf-ipngwg-ipv6-anycast-analysis-00.txt)
------------------------------------------------------

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

Would like to publish as an informational RFC. Queried room, no disagreement.

ACTION: Document editor will start a working group last call for to publish "An analysis of IPv6 anycast" as an informational RFC.

Disconnecting TCP connection toward IPv6 anycast address / Jun-ichiro itojun Hagino
(draft-itojun-ipv6-tcp-to-anycast-01.txt)
----------------------------------------------------------------------

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

Discussion:

Does per-address notification, this will also effect UDP traffic. May need different type of notification.

Usage of address unreachable is not correct, as address was reachable.

Deering would like to be able to open a TCP connection to an anycast address and get the unicast address(es) back to continue the connection.

Itojun: Beyond the scope of the draft (in anycast analysis doc). This draft is about returning error messages.

Dave Thaler: Doesn't think this is TCP specific. Should be expanded to also cover other protocols. While most UDP applications don't need this, some do. Good to expand to cover UDP and other protocols.

Author will revise document and ask for comments.

IPv6 MIB Update Status / Bill Fenner
(draft-ietf-ipngwg-rfcnnnn-update-00.txt) nnnn=2096,2011,2012,2013
---------------------------------------------------------------------

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

Deering: Timetable? TCP/UDP MIBs should be done in a few months. IP MIB will be harder and take longer. Deering suggested setting deadlines.

Are there plans to do other MIBs for IPv6 specific items. Many of these things are in the new IP MIB.

Status of Linux and USAGI IPv6 / Yuji Sekiya
--------------------------------------------

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

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

Slides

None received.