Current Meeting Report

2.3.7 IP Version 6 Working Group (ipv6)

In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at: -- Additional IPv6 Page
NOTE: This charter is a snapshot of the 54th IETF Meeting in Yokohama, Japan. It may now be out-of-date.

Last Modifield: 06/25/2002

Bob Hinden <>
Steve Deering <>
Margaret Wasserman <>
Internet Area Director(s):
Thomas Narten <>
Erik Nordmark <>
Internet Area Advisor:
Thomas Narten <>
Bob Hinden <>
Mailing Lists:
General Discussion:
To Subscribe:
In Body: subscribe ipng
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.
  • - draft-ietf-ipngwg-icmp-name-lookups-09.txt
  • - draft-ietf-ipngwg-ipaddressassign-02.txt
  • - draft-ietf-ipngwg-rfc2292bis-07.txt
  • - draft-ietf-ipngwg-icmp-v3-02.txt
  • - draft-ietf-ipv6-default-addr-select-08.txt
  • - draft-ietf-ipngwg-addr-arch-v3-08.txt
  • - draft-ietf-ipngwg-scoping-arch-04.txt
  • - draft-ietf-ipngwg-rfc2553bis-05.txt
  • - draft-ietf-ipngwg-uni-based-mcast-03.txt
  • - draft-ietf-ipv6-dns-discovery-05.txt
  • - draft-ietf-ipv6-router-selection-02.txt
  • - draft-ietf-ipngwg-ipv6-anycast-analysis-01.txt
  • - draft-ietf-ipv6-host-load-sharing-00.txt
  • - draft-ietf-ipv6-3gpp-recommend-02.txt
  • - draft-ietf-ipv6-flow-label-02.txt
  • - draft-ietf-ipv6-cellular-host-03.txt
  • - draft-ietf-ipv6-link-scoped-mcast-01.txt
  • - draft-ietf-ipv6-node-requirements-01.txt
  • - draft-ietf-ipv6-rfc2012-update-00.txt
  • - draft-ietf-ipv6-rfc2096-update-00.txt
  • - draft-ietf-ipv6-rfc2011-update-00.txt
  • - draft-ietf-ipv6-rfc2013-update-00.txt
  • - draft-ietf-ipv6-multilink-subnets-00.txt
  • Request For Comments:
    RFC1885 PS Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)
    RFC1883 PS Internet Protocol, Version 6 (IPv6) Specification
    RFC1886 PS DNS Extensions to support IP version 6
    RFC1884 PS IP Version 6 Addressing Architecture
    RFC1887 I An Architecture for IPv6 Unicast Address Allocation
    RFC1897 E IPv6 Testing Address Allocation
    RFC1981 PS Path MTU Discovery for IP version 6
    RFC1970 PS Neighbor Discovery for IP Version 6 (IPv6)
    RFC1972 PS A Method for the Transmission of IPv6 Packets over Ethernet Networks
    RFC1888 E OSI NSAPs and IPv6
    RFC2019 PS Transmission of IPv6 Packets Over FDDI
    RFC2023 PS IP Version 6 over PPP
    RFC2073 PS An IPv6 Provider-Based Unicast Address Format
    RFC2133 I Basic Socket Interface Extensions for IPv6
    RFC2147 PS TCP and UDP over IPv6 Jumbograms
    RFC2292 I Advanced Sockets API for IPv6
    RFC2375 I IPv6 Multicast Address Assignments
    RFC2373 PS IP Version 6 Addressing Architecture
    RFC2374 PS An IPv6 Aggregatable Global Unicast Address Format
    RFC2464 PS Transmission of IPv6 Packets over Ethernet Networks
    RFC2462 DS IPv6 Stateless Address Autoconfiguration
    RFC2463 DS Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification
    RFC2461 DS Neighbor Discovery for IP Version 6 (IPv6)
    RFC2460 DS Internet Protocol, Version 6 (IPv6) Specification
    RFC2471 E IPv6 Testing Address Allocation
    RFC2450 I Proposed TLA and NLA Assignment Rules
    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
    RFC2452 PS IP Version 6 Management Information Base for the Transmission Control Protocol
    RFC2466 PS Management Information Base for IP Version 6: ICMPv6 Group
    RFC2470 PS Transmission of IPv6 Packets over Token Ring Networks
    RFC2467 PS Transmission of IPv6 Packets over FDDI Networks
    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 I 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 I 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
    RFC3178 I IPv6 multihoming support at site exit routers
    RFC3146 PS Transmission of IPv6 Packets over IEEE 1394 Networks

    Current Meeting Report

    IPv6 Working Group Meeting
    Yokohama Japan

    Thursday, July 18th, 0900-1130 & 1300-1500 (Room 301/302)

    CHAIRS: Steve Deering <>
    Bob Hinden <>
    Margaret Wasserman <>


    Introduction & Agenda Bashing
    Priorities and Status -- Bob Hinden
    - Presentation of current priorities and status
    - Discussion of WG priorities moving forward
    IPv6 MIBs Status and Open Issues -- Margaret Wasserman
    IPv6 Node Requirements -- John Loughney
    DAD vs. DIID Discussion -- Chairs
    - Including DAD-related changes, if any, required to:
    Addressing Architecture Open Issues -- Bob Hinden
    Default Address Selection Open Issues -- Rich Draves
    DNS Discovery Status and Next Steps -- Chairs and Erik Nordmark
    Prefix Delegation Requirements -- Shin Miyakawa
    Node Information Queries Status & IESG Feedback -- Chairs
    Node Information Queries for Reverse DNS Lookup -- Jun-ichiro itojun Hagino
    Flow Label -- Jarno Rajahalme
    Scoped Address Architecture -- Tatuya Jinmei
    IPv6 Anycast Architecture -- Jun-ichiro itojun Hagino
    A Protocol for Anycast Address Resolving -- Shingo Ata
    Issues in IPv6 Deployment/Operation -- Jun-ichiro itojun Hagino or Tatuya Jinmei
    Link Scoped IPv6 Multicast -- Jung-Soo Park
    Use of /127 Prefix Length Between Routers Considered Harmful -- Chairs

    Morning Session 0900-1130 (Room 301/302)

    Introduction & Agenda Bashing

    Steve Deering introduced the meeting and reviewed the agenda. There we
    no changes to the agenda.

    Priorities and Status -- Bob Hinden
    - Presentation of current priorities and status
    - Discussion of WG priorities moving forward

    [Slides available at]

    Bob Hinden Presented WG Status and Priorities

    Asked for comments on the structure of the list. No objections -- interpreted as consensus that this is acceptable. Made it clear that this is how we plan to manage the group going forward.

    Discussed topics that are "Urgent for Deployment". Solicited comments on whether this list was good -- add items, disagree with any items? No comments, indicating consent.

    Reviewed items under "Completing Current Work".

    Discussed status of Basic Sockets Extensions draft. Current draft removes support for scoped addresses, to match Austin group and resolve normative references. Is this okay? Rough consensus (not unanimous) that the current status is okay -- will move ahead as written.

    Update to ICMPv6: Actually needs a new draft. There are open comments that need to be resolved.

    Presented "Longer Term, but Important" list. Somewhat arbitrary where we divided this work. The previous list is shorter term, in final stages.

    Comment that we should consider moving flow label from "longer term" list to "current work" list.

    Raised the question of whether we should pursue IPv6 over 3GPP PDP Contexts (or similar title). Soininen promised to write the document due to 3GPP recommendations design team comments, but he hasn't written it yet. Will write it if the WG thinks it is useful. Wasserman discussed original reasons for this idea: running a generic PC/Workstation stack over a 3GPP card. Narten thinks that motivation came from need for cellular requirements. May not be needed.

    Comment that we should update the PPP RFC if updates are needed. Narten: We have a process to work with 3GPP and 3GPP2, and they haven't asked for PPP updates. Wasserman: PPP spec implies that only one address will be assigned to a PPP link. This isn't a problem for 3GPP, but it may be a problem within IPv6. Need for clarification/updates related to P-to-P links. Comment indicated that this is very important.

    Specifications ready to move to Draft Standard

    DNS extensions WG will actually be responsible for advancing the DNS extensions -- drop from IPv6 WG list.

    Presented "Priorities for IPv6", not in IPv6 WG.

    Thaler: Asked if we are proposing the multi-link subnets should be moved to a new WG. Steve: That is the intention of this section, to answer that question. Narten: Commented that this is part of the larger issue of robust plug-and-play. Alain Durand: Multi-link subnet is an important project, but could be done elsewhere. Itojun: Multi-link subnets are an interesting problem, but it is weird in an architectural sense.

    Question: Why does Narten think that this is part of robust plug and play? Steve: talked about motivation for multi-link subnets, as a way to get benefits of variable length addressing. Wasserman: Constrain discussion to whether or not multi-link subnets should be done in this WG. Comments and discussion on doing IPv6 work in other WGs.

    Huitema: Thinks that this is an important part of IPv6, so belongs here. Thaler: Two parts of multi-link subnets: one part is useful for prefix delegation (RA proxy, blocked on DAD vs. DIID).

    Conclusion: Chairs will discuss with ADs and make a proposal later.

    IPv6 MIBs Status and Open Issues -- Margaret Wasserman

    [Slides available at]

    Current Drafts:


    A few people have implemented new MIBs.

    Asked people to look at the MIB definitions and see if it matches the way people have implemented these data structures. Does this model fit with current implementations?

    No questions.

    IPv6 Node Requirements -- John Loughney

    [Slides available at]

    Current Draft:

    Discussion about Unconditional Mandatory, Conditional Mandatory, Unconditionally Optional.

    Narten: Finds these definitions non-intuitive. Suggest MUST/SHOULD/MAY etc. A: This is somewhat different. This is a different from normal way these are used. How best to capture implementation requirement. The terms try to capture different between things that are optional to implement (e.g., IPv6 over Ethernet) and how something is implemented. Terms were derived from SNMP area on MIB compliance.

    Narten: Some inconsistency about how these terms are used.

    Continue discussion on mailing list. Rob Austen: Recommends reading RFC1123/1122, that defines MUST/SHOULD.

    W.G. should discuss and decide on the requirements.

    DAD vs. DIID Discussion -- Chairs
    - Including DAD-related changes, if any, required to:

    [Slides available at]

    Relevant Documents:

    Nordmark commented on the difference between what we enforce now, and what the documents say -- deferred for full discussion.

    Narten: Does this mean don't do DAD on link-local addresses? Yes, if derived from global tokens. Narten: Implication of omitting global address checking when link-local is checked is that we would have to create a link-local for all addresses.

    Soliman: Reasons for DAD is that some requirement for DAD was cheap cards that didn't have unique MAC addresses.

    Itojun: Prefers DAD, not DIID. Thinks implementation needs to defend against all addresses. This works today.

    Draves: Agrees with remove restriction in address architecture, likes changing DAD to not test global token addresses.

    Bound: Thinks uniqueness property is critical. Thinks this is an unnecessary change to the architecture.

    Huitema: Thinks best to enforce uniqueness for addresses, not IIDs. Duplicate address detection, is a mixed bag. Good to detect a duplicate, but easy to create DOS attack. Like proposal to not do it.

    Other comment that doesn't like relaxing DAD.

    KRE: We should solve architectural problem first. Agrees with Jim. Disagree w/ Huitema about DOS attack. Others way to breaking ND. Overall impression is that cost of DAD is OK (where it makes sense). We would have to go back to PS.

    Perkins: Feature that node can get a lot of addresses. Likes removing it if we can.

    Nordmark: Comment that the second bullet on slide 3 is not true. Steve disagrees. Agreement that this doesn't really matter, this is a detail. Comment on duplicate ethernet addresses. Thinking used to be: Doing DAD is fairly cheap, even though it doesn't work all of the time, and it is a good tradeoff for finding address overlap. May not be considered cheap anymore, because of mobility and privacy addresses. But, may still be a chance of collision.

    Dupont: To allocate a global address, I should allocate a link-local address and do DAD on that? Is that this proposal? Steve: No, this proposal is independent of DAD vs. DIID. Currently having a discussion of DAD vs. DIID -- looking for consensus. Believes that we shouldn't remove DAD for EUI-64 addresses, but we can avoid this for links that guarantee uniqueness like PPP. Steve: Disagrees that PPP can guarantee uniqueness.

    Thaler: Likes the proposal, but wants to comment on architecture. DAD is architecturally cleaner. Steve: Before we talk about DAD, which architecture are we talking about? Dave: One where addresses are unique on the link is architecturally cleaner. Comment that addresses should actually be unique on a subnet, not just a link. So, prefers DAD.

    Jinmei: Prefers DAD, not DIID. DIID causes some problems. Prefers that addresses are unique, not IDs. Thinks that we should do DAD on all addresses.

    Narten: Ought to be having the architectural discussion. What are the benefits vs. the costs? Deering: Tried to capture in slides (#2) -- does Narten want to disagree or supplement? Narten still doesn't understand why the architectural requirement is there for ID uniqueness. Folks are already doing DAD using ARP, probably don't want to eliminate that. Hinden: IPv4 addresses are not made with global tokens, and few addresses on the link.

    Huitema: On cost issue of doing DAD. DAD causes it to take longer for your system to boot. This is a high cost. Also, delays when you do mobility or privacy addresses. This is actually a large cost.

    Nordmark: Can we eliminate some of the costs of DAD by doing optimistic DAD?

    Steve: Need to answer architectural question to advance Address Architecture. Can we get sense of room? Fairly large majority thought that we should NOT require interface identifier uniqueness on a link. Very rough consensus to make the change.

    Addressing Architecture Open Issues -- Bob Hinden

    [Slides available at]

    Current Draft:

    Presented slides.

    KRE: Additional comment on the addressing architecture. The U-bit should not be specified to indicate global uniqueness. We know that subnet prefixes longer than /64 exist, so we can't use this bit. Steve: Only if they violate the spec. KRE: Can't rely on this bit. Narten: Clarification of KRE's statement? KRE: Apart from the fact that we don't have any use for this, we also know that we can't rely on it because we can't tell, from the outside looking in, and determine how this address was made. Narten: Think that the first few bits and this bits do make an assertion about how the address was generated. Thinks that text may need changes, but doesn't agree with getting rid of this completely.

    Bound: What is the issue? Where are these coming from? Are they holding up the spec? Hinden: Yes. Bound: More interested in knowing what the IESG is saying. What don't they like about these two bullets.

    Hinden: Mentioned he has some reservations about the consequences of previous consensus -- addresses unique, not IDs.

    Discussion on site-local address format change.

    Itojun: Router renumbering document hard-codes subnet boundaries at /48. Would need update.

    Bound: Supports change. Needs mailing list discussion. Here once before, discuss this but it got killed. Any consensus by show of hands at a meeting is not final consensus. Final consensus can only be done on the mailing list. Chairs: Agreed.

    Jinmei: Clarification that router renumbering doesn't hard-code /48, but has a fixed field for the prefix length. However, the specification of router renumbering assumes /48 as site prefixes. So, despite the clarification, it's true that this proposal would make router renumbering less useful.

    Zill: Why extend subnet ID? Larger subnet fields or globally unique subnet IDs? Bob: Larger subnet fields. Brian: Common agreement to use /48, are we trying to change that? Steve: Customers can already negotiate a larger subnet field, but can't use it in site-local. Brian: Agrees with this change, but to make the subnet values globally unique.

    Hain: Suggestion to change wording from "subnet ID" to "locally administered". Bob: Will add appropriate usage wording for larger than 16 bits.

    Narten: Key thing is to remove the 16-bit hard-coded boundary and bring subnet addresses in line with the global addresses that have a flexible boundary. Calling it subnet ID is fine -- that's what it says in both address pictures.

    Itojun: They might make site-local more useful, which is bad.

    Call for consensus: majority agreed to make the change, but not unanimous. Rough consensus for site-local change. New draft will be summarized to mailing list.

    Default Address Selection Open Issues -- Rich Draves

    [Slides available at]

    Current Draft:

    Draves presented slides.


    Hinden: Gave introduction that it was important to reach closure on this document and that we are hearing the same arguments repeated.

    Durand: Thinks we should have gone with BCP approach.

    Deering: Cautioned against having the same arguments over and over again.

    Jinmei: Supports draft and has used it. Thinks that standard status is less important than publishing the draft. Hinden: Already have consensus to move this on the standards track. This was discussed at last two IETF meetings.

    Narten: Clarification on Steve's point. Should also discuss things again when the mood of the community changes or there is more experience.
    Hinden: Agrees.

    Draves: This is already implemented and shipping.

    Chairs declared that based on mailing discussions there is a consensus in the working group to move this to Proposed Standard. It is now back in the IESG for consideration as a Proposed Standard.

    DNS Discovery Status and Next Steps -- Chairs and Erik Nordmark

    [Slides available at]

    Current Draft:

    Nordmark sent email to mailing list.

    Deering disagreed with notion that well known site local addresses set a new precedent. We have well known anycast and multicast addresses.

    Comment that if needed to for short term deployment, it would be OK. The best is the enemy of the good.

    Huitema: Thinks this is the kind of thing people are complaining about at the IESG plenary.

    KRE: While we have subnet anycast addresses, they are useless. We shouldn't be defining how address space is used.


    Rob: Suggested that DHCPv6 is good enough for now.

    Deering: This type approach is being used operationally in Japan.

    Chairs View / Margaret Wasserman

    [Slides available at]

    Droms: Lots of talking past ourselves. Thinks we are discussing current draft. Current draft is DNS resolution, not DNS discovery. Current draft uses well known unicast addresses. Last thing, looking at options, problem for me has been these are not mutually exclusive solutions. There are operational scenarios that have different requirement. What are requirements around "o-bit" in ND.

    Wasserman took poll for choices listed. Results were:

    1) Continue w/ existing proposal, Proposed Standard or Experimental:

    Consensus to standardize short term solution
    Consensus to continue work on current proposal.

    2) Accept DHCP in addition to current work

    Consensus to continue working on DHCPv6

    3) Requirements: Important to further develop requirements?

    Small consensus to not work on requirements

    4) Consider new short term solution:


    Afternoon Session 1300-1500 (Room 301/302)

    Prefix Delegation Requirements -- Shin Miyakawa

    [Slides available at]

    Current Draft:

    Presented slides.

    Nordmark: In zero configuration case -- on first start, sites may be willing to take any prefix. Later ask for same prefix. Is this part of requirements? Miyakawa: Yes.

    Huitema: We have additional requirements. For instance, when a link is shared by multiple customers (i.e. using Ethernet) the situation is more complex -- can take existing prefix and reuse it for the network. Need strong authentication for request, using authentication structure of Internet today (RADIUS, etc.). Not in draft -- extensibility requirements, complex cases, etc. Miyakawa: Just trying to get WG to accept the document. NTT will be starting deployment this summer. Would appreciate comments. Huitema: We need to identify all of the requirements before we look at solutions.


    Polled group to determine if this document should become a work group document and if w.g. should continue working on prefix delegation.

    Do people want to accept this document as w.g. item? Consensus to accept as a working group item.

    Continue working on prefix delegation? Consensus that w.g. should work on prefix delegation.

    Presented options for how to do this.

    Should choices be limited to DHCPv6 or proxy RA's? Should there be one or more solutions.

    Suggestion that there could we get a light weight solution for P-P link.

    Huitema: Difference it link is dedicated or shared between customers. Simple if not shared. Other case requires more complex solutions.

    Soliman: Thinks we should look at the requirements and see which solutions best meet them.

    Thaler: Must be able to have link look like multiple links. Want to have multiple links and bring together. RA proxy solution can be used without extra protocols.

    Drums: Not the same as DNS. There are reasons why only one solution is preferable.

    Wasserman: Suggested to continue to work on requirements and try to pare down choices on the mailing list.

    Narten: Could work on both at the same time.

    Slight consensus on to focus on DHCPv6 and proxy RAs, but not overwhelming.

    Narten: Good to understand why people didn't vote for limiting the two solutions.

    Conta: Thinks it is artificial to limit solutions.

    Narten: This is only about limiting to what we work on now. Other things are possible in the future.

    Node Information Queries Status & IESG Feedback -- chairs

    [Slides available at]

    Current Draft:

    Bob Hinden presented slides.

    Call for working group opinion. Choices:

    - Drop the draft

    - Update it to address technical comments, remove extraneous stuff and augment applicability statement

    Narten: This isn't black and white? Spectrum of things to do here.

    Poll of group: Consensus to continue work on the document, and update to address concerns.

    Node Information Queries for Reverse DNS Lookup -- Jun-ichiro itojun Hagino

    [Slides available at]

    Current Draft:

    Presented slides. Noted that work is outside of the applicability statement currently in Node Information Queries.

    Nordmark: Difference between DNS server and node itself serving the address. Response: Not true if you run your own DNS.

    KRE: Dynamic DNS would allow a node to say what name is given out. Shouldn't call these things DNS names, as raised in draft. Not DNS names, use another label.

    No decision about how to proceed

    Flow Label -- Jarno Rajahalme

    [Slides available at]

    Current Draft:

    Presented slides.

    Flow label scope issue. Was proposing fix to correct KRE's confusion, but KRE wasn't confused. Change not needed.

    Should routers create flow state for unknown flows? Jarno proposes no.

    Nordmark: Prohibit this behaviour. Jarno: Yes, prohibit it.

    Wasserman: How does this relate for use in load balancing? Jarno: Load balancing is actually a flow set-up algorithm, so the flow state would already be there. So, it would be okay to cache. Wasserman: Will this be explained in the document? Jarno: Needs to discuss this with other authors.

    Nordmark: Document says that the host should use a new flow label value for each connection. Is that only when there is a flow establishment mechanism? A: On next page.

    Nordmark: What about flow reuse? Jarno: Skipped slide due to lack of time.

    No overall conclusion. Will need additional discussion on the mailing list.

    Scoped Address Architecture -- Tatuya Jinmei

    [Slides available at]

    Current Draft:

    Thinks ready for working group last call. Thinks current draft resolves all issues with raised on mailing list.

    Fenner: This is inconsistent with what routing protocols can provide. ISIS model is that site boundaries are in links, not in nodes. Not sure how to resolve this. Weaken text about where site boundaries are, change model, etc. Thinks current architecture is not reliable given limitations of current routing protocols. Suggestions? One possibility is to relax requirement that site boundary is in node, that it could be in a node, or link is not in a site.

    Deering: This could be handled by thinking of a virtual node in the middle of a link. Routing vendors currently handle multiple Net 10 in routers, so this is similar. Not sure where push back is coming from.

    Fenner: If you keep your site local addresses separate by different instances of routing protocols, might cause traffic to want to exit the site to get the other part of the site. When sending from a site local to a global address.

    Nordmark: Should send ICMP error when dropping a packet due to scope violation.

    Wasserman: Does this then depend on update to ICMP spec? Yes, if ICMP responses are specified. Currently, there is an inconsistency between how routing protocols work and what architecture is completed. Inconsistencies need to be resolved.

    Narten: Thanks Bill Fenner for raising issues. More working in the document needs to be done to resolve this, or is it OK as is. Fenner: This is trying document what is under specified in IPv4. Some of the issues are being written down here.

    IPv6 Anycast Architecture -- Jun-ichiro itojun Hagino

    [Slides available at]

    Current Draft:

    Presented slides.

    Chairs are not prepared to make decision on whether another last call is required. Will consider and decide.

    A Protocol for Anycast Address Resolving -- Shingo Ata

    [Slides available at]

    Current Draft:

    Presented individual draft.

    Comment on slide with diagram of procedure. How can the client tell if a given address is an anycast address? A: Currently, we cannot tell which address is unicast or anycast. Current implementation sends an ICMP echo packet to determine if the address is anycast. If the same address is used as source on the return, it is anycast. Further comment: Send this for every address.

    Nordmark: Are there people interested in forming a working group to work on the general problem of making anycast useful for services and applications? Many hands raised.

    Issues in IPv6 Deployment/Operation -- Tatuya Jinmei

    [Slides available at]

    Current Draft:

    Will continue working on draft. Draft will stay a individual submission and will not be a w.g. draft.

    Link Scoped IPv6 Multicast -- Jung-Soo Park

    [Slides available at]

    Current Draft:

    Ready to advance.

    ACTION: Chairs will start a w.g. last call to advance "Link Scoped IPv6 Multicast" for Proposed Standard

    Use of /127 Prefix Length Between Routers Considered Harmful -- Chairs

    Current Draft:

    [Note was not discussed]

    Meeting Adjourned


    IPv6 MIB Status and Issues
    Uniqueness Properties of Interface Identifers (IIDs), and DAD vs. DIID
    IPv6 Address Architecture to Draft Standard
    Default Address Selection for IPv6
    DNS Discovery
    DNS Discovery Discussion
    Requirements for IPv6 prefix delegation
    Prefix Delegation Discussion
    Node Information Queries
    Use of ICMPv6 node information query for reverse DNS lookup
    IPv6 Flow Label Specification
    IPv6 Scoped Address Architecture
    An analysis of IPv6 anycast
    A Protocol for Anycast Address Resolving
    Unidentified Issues in IPv6 Deployment/Operation
    Link Scoped IPv6 Multicast Addresses