IETF 6MAN Working Group Meeting Monday, 17 November, 2008 Minneapolis Hilton, Salon E, 1300-1500 Co-Chairs: Bob Hinden and Brian Haberman The meeting was called to order by 6MAN co-chairs Brian Haberman and Bob Hinden. The minutes were taken by Karen O'Donoghue and Ed Jankiewicz. The Jabber Scribe was Suresh Krishnan. The blue sheets were distributed, and the agenda was presented with no additions (slides: Introduction, 6man-0.pdf). Brian Haberman reviewed the current working group document status. (slides: Document Status, 6man-1.pdf). Use of the IPv6 Flow Label as a Transport-Layer Nonce, Steve Blake ================================================================== Document: draft-blake-ipv6-flow-label-nonce-00.txt Slides: IPv6 Flow Nonce, 6man-4.pdf Steve Blake presented his draft on the use of the IPv6 flow label as a transport layer nonce. This would help protect against off path blind spoofing. The work is applicable to TCP and UDP. Further effort is required to look at the applicability for SCTP, DCCP and RTP. Dave Thayer indicated that for UDP you would have to change the application to set the nonce for applications that don't already have a nonce in the application protocol. If you have to change the application anyway, it may be cleaner to do an application nonce. Bob Hinden stated that it personally seems like a useful thing to do. It is not too expensive, and it doesn't break anything. Steve is going to present to TSV area for feedback. Based on the comments received, he will update the draft and bring it back to this group. Brian Haberman asked if he had thought about implementing it as a service at the network level. Steve agreed to look into this. He will update the draft and bring it back to the working group. IPv6 Address Selection Design Team, Arifumi Matsumoto ===================================================== Document: draft-chown-addr-select-considerations-00.txt Slides: Address Selection Design Team Report, 6man-6.pdf At IETF 72 in Dublin, a discussion on RFC 3484 triggered Brian Haberman to ask a design team to go off and look at the issues. A design team of 15 people was formed, and Arifumi Matsumoto reported on the progress of that team since the IETF72. He identified the issues being considered and the approach taken by the team. They have identified three types of drivers for policy changes: internal, external, and other (e.g. IETF/IANA). There was a lengthy discussion on the potential frequency of the policy changes. If we focus on admin triggers (rather than routing triggers) the solution would be much simpler. Another questions was how policy changes will be propagated? Multihomed hosts also need to be carefully considered, e.g. how do you merge input from siteA and siteB. There are additional issues for an RFC 3484 update beyond policy distribution. Brian Haberman indicated that we need to focus on the requirements first and then determine how to proceed with the solutions. Jari Arkko indicated that the working group should solve both policy distribution and any additional 3484 update issues. The design team will take the feedback received and continue working. Node Requirements Update, Ed Jankiewicz ======================================= Document: draft-ietf-6man-node-req-bis-02.txt Slides: Node Requirements Update, 6man-3.pdf Ed Jankiewicz presented the status of the node requirements update in the absence of John Loughney. A number of issues are being tracked in the issue tracker and are summarized in the slides. The IPsec discussion in the document is still quite controversial. This WG needs to decide how it wants to proceed. It will then go to the full IETF prior to finalization. Jari clarified that it is true that you can not change other specifications with this document. Brian Haberman asked the working group to review the issues in the issue tracker and comment on them on the mailing list. DSL Line Identification using Router Solicitation, Suresh Krishnan ================================================================== Document: draft-krishnan-6man-rs-mark-01.txt Slides: Line Identification in NDP Messages, 6man-5.pdf Suresh Krishnan presented his draft on line identification using ND Messages. This work came from discussions in the Broadband Forum on how to deal with identifying subscriber premises when there are multiple customers on a VLAN. There were several questions about the approach taken in the draft. Margaret Wasserman indicated that this was not inherently a bad idea, but the draft is pretty sketchy and needs a lot more detailed work. There was some concern expressed about there being a problem with unsolicited Router Advertisements in this scenario. Suresh indicated that this would only be applicable at the "first sign of life" from a host. There were additional questions about the scale being considered here. Suresh indicated that this is applicable to perhaps hundreds of premises. Jari added that while some of the questions relate to the architecture and are interesting, the draft isn't changing that in any way. There was a suggestion to use a more general subscriber specific multicast mechanism. If there are other use cases for this approach, we might be better off doing it elsewhere. Bob Hinden expressed some reservations about inserting RA options in transit. Have you considered the implications on SND? We should go back to the broadband forum for additional information and coordination. We should also liaison with IEEE 802 to see if there is something to be done there. Suresh will do another revision of the draft based on the feedback received. Ephemeral IPv6 Addresses and IPv6 Address State Extension, Hiroshi Kitamura =========================================================================== Document: draft-kitamura-ipv6-ephemeral-address-00.txt Document: draft-kitamura-ipv6-uncertain-address-state-00.txt Slides: Ephemeral Addresses and New Address State, 6man-7.pdf Hiroshi Kitamura presented two drafts on ephermeral addresses and a new address state. The motivation of these drafts is to create a security enhancement for privacy. It would change the legacy concept of address usage. An ephemeral address is used for a single session. Concept creates a new address state called "uncertain". There were several questions about the effort. The security problem being addressed needs to be more clearly defined. There are scalability issues for applications that want to save state in switches and routers. In fact, this could be similar to a DOS attack on a router. There was some concern that the neighbor cache problem has just exploded. Some applications are going to break. Why wasn't optimistic DAD considered? There was no consensus to adopt this effort at this point in time. Domain name-based interface selection, Teemu Savolainen ======================================================= Document: draft-savolainen-6man-fqdn-based-if-selection-00.txt Slides: Interface selection using FQDN, 6man-2.pdf Teemu Savolainen presented his draft on domain name-based interface selection. This draft attempts to address the situation of multihomed devices where destinations are not all equally reachable. This allows network interfaces to advertise their reachability and possibly additional special services possibly via DHCP. There was a short discussion on the definition of optimal in this case. Margaret Wasserman commented and Kurtis Lindquist agreed that there were major technical issues with this draft. Additionally, there is nothing in this approach that is specific to IPv6 and there are serious problems with tying DNS and routing together. Dave Thayler would like to see a comparison between this and the specific routes draft. ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- The meeting was adjourned. ---------------------------------------------------------------------------- ----------------------------------------------------------------------------