Current Meeting Report
Slides
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:
http://playground.sun.com/pub/ipng/html/ipng-main.html -- 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
Chair(s):
Bob Hinden <hinden@iprg.nokia.com>
Steve Deering <deering@cisco.com>
Margaret Wasserman <mrw@windriver.com>
Internet Area Director(s):
Thomas Narten <narten@us.ibm.com>
Erik Nordmark <erik.nordmark@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:
- 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:
RFC | Status | Title |
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 <deering@cisco.com>
Bob Hinden <hinden@iprg.nokia.com>
Margaret Wasserman <mrw@windriver.com>
AGENDA:
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 http://playground.sun.com/ipng/meetings.html]
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 http://playground.sun.com/ipng/meetings.html]
Current Drafts:
<draft-ietf-ipv6-rfc2096-update-00.txt>
<draft-ietf-ipv6-rfc2011-update-00.txt>
<draft-ietf-ipv6-rfc2012-update-00.txt>
<draft-ietf-ipv6-rfc2013-update-00.txt>
Discussion:
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 http://playground.sun.com/ipng/meetings.html]
Current Draft:
<draft-ietf-ipv6-node-requirements-01.txt>
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 http://playground.sun.com/ipng/meetings.html]
Relevant Documents:
<rfc3041.txt>
<rfc2462.txt>
<draft-ietf-ipngwg-addr-arch-v3-08.txt>
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 http://playground.sun.com/ipng/meetings.html]
Current Draft:
<draft-ietf-ipngwg-addr-arch-v3-08.txt>
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 http://playground.sun.com/ipng/meetings.html]
Current Draft:
<draft-ietf-ipv6-default-addr-select-08.txt>
Draves presented slides.
Discussion:
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 http://playground.sun.com/ipng/meetings.html]
Current Draft:
<draft-ietf-ipv6-dns-discovery-05.txt>
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.
Discussion.
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 http://playground.sun.com/ipng/meetings.html]
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:
N/A
Afternoon Session 1300-1500 (Room 301/302)
==========================================
Prefix Delegation Requirements -- Shin Miyakawa
-----------------------------------------------
[Slides available at http://playground.sun.com/ipng/meetings.html]
Current Draft:
<draft-miyakawa-ipv6-prefix-delegation-requirement-00.txt>
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.
Wasserman:
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 http://playground.sun.com/ipng/meetings.html]
Current Draft:
<draft-ietf-ipngwg-icmp-name-lookups-09.txt>
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 http://playground.sun.com/ipng/meetings.html]
Current Draft:
<draft-itojun-ipv6-nodeinfo-revlookup-00.txt>
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 http://playground.sun.com/ipng/meetings.html]
Current Draft:
<draft-ietf-ipv6-flow-label-02.txt>
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 http://playground.sun.com/ipng/meetings.html]
Current Draft:
<draft-ietf-ipngwg-scoping-arch-04.txt>
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 http://playground.sun.com/ipng/meetings.html]
Current Draft:
<draft-ietf-ipngwg-ipv6-anycast-analysis-01.txt>
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 http://playground.sun.com/ipng/meetings.html]
Current Draft:
<draft-ata-ipv6-anycast-resolving-00.txt>
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 http://playground.sun.com/ipng/meetings.html]
Current Draft:
<draft-itojun-jinmei-ipv6-issues-00.txt>
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 http://playground.sun.com/ipng/meetings.html]
Current Draft:
<draft-ietf-ipv6-link-scoped-mcast-01.txt>
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:
<draft-savola-ipv6-127-prefixlen-04.txt>
[Note was not discussed]
------------------------------------------------------------------------
Meeting Adjourned
------------------------------------------------------------------------
Slides
Agenda
- Bob Hinden
- Steve Deering
- Margaret Wasserman
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
- Jarno Rajahalme
- Alex Conta
- Brian E. Carpenter
- Steve Deering
IPv6 Scoped Address Architecture
- Steve Deering
- Brian Haberman
- Tatuya Jinmei
- Eirk Nordmark
- Atsushi Onoe
- Brian Zill
An analysis of IPv6 anycast
- Jun-ichiro itojun Hagino
- K. Ettikan
A Protocol for Anycast Address Resolving
- Shingo Ata
- Hiroshi Kitamura
- Masayuki Murata
Unidentified Issues in IPv6 Deployment/Operation
- Jun-ichiro itojun Hagino
- Tatuya Jinmei
Link Scoped IPv6 Multicast Addresses
- Jung-Soo Park
- Myung-Ki Shin