IETF 6MAN Working Group Meeting Wednesday, July 30, 2008, 0900-1130 The jabber log can be found at: http://jabber.ietf.org/logs/tictoc/2008-07-30.txt The meeting was called to order by 6MAN co-chair Brian Haberman. Bob Hinden was unable to attend this meeting. The minutes were taken by Karen O'Donoghue and Ed Jankiewicz. The blue sheets were distributed, and the agenda was presented with no additions. Brian Haberman reviewed the current working group document status. (slides: Document Status, 6man-0.pdf) PMIP6 Indication and Discovery, Basaravaj Patil =============================================== Document: draft-damic-netlmm-pmip6-ind-discover-03.txt Slides: PMIP6 Indication and Discovery, 6man-1.pdf Basaravaj Patil presented the document on extensions to IPv6 router advertisements to better support mobility. Three possible options with justifications for each were presented. There were numerous questions from the attendees including questions about which address is the PMIP6 address and is this just for PMIP networks that have a HA. Several attendees felt the justifications for the options were not strong enough. Pekka reminded the group that we needed concurrence from the netlmm wg for anything done in this area. Thomas Narten indicated that it was not clear that netlmm will pick up this effort. If netlmm isn't interested we shouldn't take it up. Brian Haberman proposed that they update the proposal and bring it back next time. IPv6 Address Selection, Ruri Hiromi =================================== Document: draft-arifumi-6man-rfc3484-revise-00.txt Slides: RFC 3484 Revision, 6man-3.pdf Ruri Hiromi provided an overview of some suggested revisions to RFC3484. There was discussion on several of the suggestions. Some felt that the problem statements were fine, but the proposed behaviors were not the right solutions or the solutions were incomplete. Brian Haberman polled the room to judge the consensus. He asked the following questions: "How many people in room or on jabber feel that there needs to be an update 3484?" Several hands were raised. "How many feel there should not be an update to 3484?" Tony Hain was the only one opposed. Tony indicated that this was not required because we haven't identified what problem can't be solved by a mechanism to dynamically update policy. He feels that we need that mechanism first. We then use defaults that work for the generalized zero conf case. Thomas Narten requested that we ask if the group feels there should be a way of updating the policy to react to changing local conditions. The general response to this was yes. In this case, fixing 3484 is necessary but not sufficient. The draft should be updated, and the discussion should continue on the mailing list. Document: draft-arifumi-6man-addr-select-sol-01.txt Slides: IPv6 Address Selection, 6man-4.pdf Ruri Huromi continued with a draft addressing approaches to allow hosts to do appropriate address selection automatically. The draft evaluates 4 approaches. There was some discussion about each approach. Brian asked if the protocol work for a DHCP policy table should be done here or in DHC. Ralph Droms (chair of the DHC WG) indicated that the IESG recommends that the "customer" group define the semantics and the syntax of the needed options. The DHC group reviews for compatibility and appropriateness. There should be a coordinated WGLC. However, there wasn't consensus that the DHC approach was the right mechanism in the first place. Brian Haberman asked several questions to gauge consensus. Several people thought we should have a dynamic option. No one was willing to indicate that they thought the approaches in the document were reasonable than unreasonable. Thomas Narten indicated that it's not clear that the solution is going to be based on the framework in this document. The general sense of the room was that some work in this area needs to be done, but this document is not really appropriate as a starting point. It is more an analysis of possible approaches than a solution document itself. The approach is to form a design team to work offline to develop a solution. Router Advertisement M and O flags, Joseph Cha ============================================== Document: draft-cha-ipv6-ra-mo-00.txt Slides: Clarifying M and O flags, 6man-2.pdf Joseph H. Cha presented a draft proposing changes to clarify the M and O flags. Discussion followed on the meaning of the flags and the efforts to clarify them in the past. We can't do anything on the flag transition issue because we don't have consensus on the meaning of the flag. We are wasting time because there isn't consensus to go any further on this topic. We have spent 10 years clarifying the M&O bits. There is not consensus that there is a problem. Some feel the hung DHC client is the problem. Brian Haberman concluded that that we should not reopen the discussion of the M&O bits. This has been discussed multiple times with no consensus. Overlapping Fragments, Suresh Krishnan ====================================== Document: draft-krishnan-6man-overlap-fragment-01.txt Slides: Overlapping Fragments, 6man-5.pdf Suresh presented a short presentation on the issue of overlapping fragments. This is an oversight in RFC 2460. To fix this loophole, you basically need a half-sentence change to an existing RFC. We will adopt this draft as a working group document and go to WGLC as an update to RFC 2460 as soon as possible. Extension Headers, Suresh Krishnan ================================== Document: draft-krishnan-ipv6-exthdr-03.txt Slides: Extension Headers, 6man-6.pdf Suresh reported on the update to the extension headers draft. He addressed all comments received except for the "who is going to use extension headers?" comment. The point of this document is "if you use them, this is how you do it". A number of issues were addressed in the update. The remaining open issue is backwards compatibility. Extension headers may alter processing. A packet cannot be processed by older implementations that don't understand the extension header. The standard approach for dealing with this issue is recommending that implementations do not process unrecognized extension headers. There was a question about who is responsible for the IPv6 API? It is currently an informational RFC. It falls within the domain of the POSIX standards community, but they have not taken it up yet. We can only give recommendations to the POXIX community. Brian Haberman concluded the discussion by asking Suresh to revise the document and ask the mailing list for consensus. The meeting was adjourned.