6MAN Working Group 2011-07-26 (Tuesday) 1520-1810 -------------------------------------------- Document status: - Flow label spec in IESG review - 3697bis -revised id needed - ecmp and update in AD follow-up - Node requirements in AD review; waiting on response from authors - UDP-Zero ready for WG Last Call - UDP-Checksum requires revision prior to WG Last Call - Line ID proposal awaiting resolution with issues raised in draft-dec -------------------------------------------- IPv6 Extension Header issues Suresh Krishnan et al - Recommends destination options as means for extension of IPv6 - Recommends against development of new extension headers - Defines a way to add new extension headers, including a parseable format Concern raised about *all* extensions being in a destination option since some potential extensions might be hop-by-hop in nature. Draft to be sent to IESG. -------------------------------------------- Security Implications of IPv6 extension headers in Neighbor Discovery Arturo Servin/Fernando Gont Problem statement: There is no current use of IPv6 extension headers with ND. There is concern that implementations will cut corners, and therefore miss implications of extension headers in SAVI, RA Guard, or other uses. Evasion technique #1: do not process entire header chain and therefore not realize that it's an ICMP packet. Evasion technique #2: use a destination options header and fragment ICMP packet, and therefore miss it due to fragmentation. Evasion technique #3: use multiple destination options headers plus fragmentation, and therefore fail in parsing. Solution: prohibit extensions in ND. Solution: require layer 2 devices to parse the entire header. Solution: prohibit fragmentation of ICMP messages. Draft must have added text re SEND and other issues before consideration for WG adoption. -------------------------------------------- Update to RFC 3484 Tim Chown: rfc3484-revise - 3 open issues, those close to closed - deprecated prefixes in policy table - keep to manage bad things. no dissent expressed. - mechanism for selection of EUI-64 Address vs Privacy Addresses - Tim: no specific support required Goal is to focus on moving this version forward quickly and focus on new policy-based information in a later update. - Add address lifetime as a criterion in choice? Recommendation: leave as is. No dissent expressed. - Document will move toward WG Last Call after next revision. addr-select-opt - needs review before WGLC. Chairs to request review by DHC WG before 6MAN Last Call. -------------------------------------------- DAD Proxy: Jean-Michel Combes Based on BBF Liaison requesting - a mechanism proxying DAD - a mechanism to prevent IP spoofing - reference in TR-177 BOF document WG adoption has resulted in minor edits. Needs new security considerations and WGLC. Requires a new version after SAVI work. -------------------------------------------- IPv6 Neighbor Discovery DOS attack Igor Gashinsky issue: overloaded router neighbor table space from remote traffic Solutions - filter out some addresses, limit address count, or limit address shortness. NDP prioritization on the router - serve packets in a certain order NDP Queue Tuning - place limits on queue length, behavior. Allow gratuitous NA, cache priming, etc. Draft needs revision to clarify problem statement and flush out the pros and cons of the potential solutions. -------------------------------------------- NUD is too impatient Erik Nordmark Slides cover material Strong consensus to adopt as working group document -------------------------------------------- IPv6 ND Optimization for Energy-aware Devices Chakrabarti Addresses multiple concerns with power consumption by NDP on devices operating on a battery. Suggestion: use Address Registration Option to force a "permanent" neighbor entry in router, and therefore not need ND between neighboring nodes. Simplifies DAD, allows for timed transmission from routers. Some concerns about determining when unicast or multicast should be used. Interest from people interested in Internet of Things. -------------------------------------------- IPv6 over MS / TP Networks Kerry Lynn Looking at use of IPv6/6LOWPAN in Building Control space. BACNET has already changed its protocol to allow for transmission of an IPv6-compliant frame, which means enlarging the frame and providing appropriate CRC support. Uses RFC 4944 Dispatch header and RFC 6282 (IPHC) compression. Builds heavily on 6lowpan decisions. Discussion on work will be carried out on the mailing list. -------------------------------------------- RS Driven Access Considered Harmful Wojciech Dec Looking at discussion of how to attach an IPv6 router to a broadband access network (e.g., line id draft). Several issues with interaction between devices and affects on those interactions by the various NDP timers. Several options. Cable Labs has chosen to require a DHCPv6 client. Other protocols subject to similar start up issues. Fixing this requires changing the host which is untenable. Limited solutions outside the host, but they each have failure modes. Question as to the goal of this draft given the ongoing Line ID draft. Multiple questions on trying to build a perfect solution versus providing a "good enough" solution. Several people want an alternative solution be proposed by the author. -------------------------------------------- Meeting adjourned at 1825.