IPv6 Working Group Meeting Yokohama Japan Thursday, July 18th, 0900-1130 & 1300-1500 (Room 301/302) ========================================================= CHAIRS: Steve Deering Bob Hinden Margaret Wasserman 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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 ------------------------------------------------------------------------