6MAN Working Group - IETF 82 in Taipei Monday, 0900-1130, 14-Nov-2011 Chairs: Bob Hinden, Brian Haberman (remote) Minute Taker: Joel Halpern Jabber Room: Marshall Eubanks & Bill Fenner Agenda ====== Introduction, Agenda Bashing, Document Status, Chairs, 10 min. Node Requirements update based on new Flow Label RFC, Chairs, 10 min. Updates to IPv6 Address Selection, Arifumi Matsumoto, 20 min. draft-ietf-6man-RFC3484-revise-05.txt draft-ietf-6man-addr-select-opt-01.txt draft-ietf-6man-addr-select-considerations-04.txt The IPv6 UDP Zero Checksums, Marshall Eubanks, 20 min. draft-ietf-6man-udpzero-04.txt , draft-ietf-6man-udpchecksums-01.txt Energy Aware IPv6 Neighbor Discovery Optimizations, Samita Chakrabarti, 15 min. draft-chakrabarti-nordmark-energy-aware-nd-01.txt Transmission of IPv6 over MS/TP Networks, Kerry Lynn, 15 min. draft-lynn-6man-6lobac-02.txt An Offset Indicating Option for IPv6, Brian Carpenter, 15 min. draft-zhang-6man-offset-option-01.txt Enhanced Duplicate Address Detection, Hemant Singh, 15 min. draft-hsingh-6man-enhanced-dad-02.txt Introduction, Agenda Bashing, Document Status, Chairs, 10 min. Presented by Bob Hinden ============================================================== Hui Deng reported draft-ietf-mif-dhcpv6-rout-option-03 will be presented in mif working group and is also of interest to 6man WG. Revised Flow Label specifications have been published as RFCs Suresh Krishnan summarized discussion of the line-id draft. There is discussion of what should be specified about the content of the field specified by the draft. Two different groups of operators want different content, so it is hard to resolve how to specify more about the field contents. Suggestion from the floor that opaque exact match behavior may be sufficient. Node Requirements update based on new Flow Label RFC, Chairs, 10 min. ===================================================================== Should this document be updated to reflect the recently published Flow Label RFCs? So a new WG last call has been issued to confirm comfort with the changes. Jari Arkko said not to delay publishing if we cannot easily resolve this issue. Several people spoke in support of getting this text into the document now. Brian Haberman (remote, co-chair) strongly urged support for making this change. Bob Hinden polled the room, and there was strong support for the change, and no one indicated opposition. Updates to IPv6 Address Selection, Arifumi Matsumoto, 20 min. ============================================================= Update to RFC 3484 Default Address Selection for IPv6, draft-ietf-6man-RFC3484-revise-05.txt: Two comments have been received so far. Two changes were made in the last revision. 6bone testbed addresses were added back to the revised default policy table. Revision removed restrictions on using anycast addresses as source addresses, since RFC 4291 removed the restrictions. It has been noted since that there are a few exceptions that need to be noted. Brian Carpenter raised concern about how to match this text with the underlying RFC3484. This will be addressed by some text reorganization. Dave Thaler noted that the relationship to 3484 should be noted in the document header. And he then asked how large the reorganizational changes will be, and whether a new WG LC will be needed. This will be evaluated when the revisions are available. Distributing Address Selection Policy using DHCPv6, draft-ietf-6man-addr-select-opt-01.txt: This document needs dhcp review, and reviewers have now been assigned. WGLC should begin after the reviews. Considerations for IPv6 Address Selection Policy Changes, draft-ietf-6man-addr-select-considerations-04.txt: Only minor updates were made to this document this round. The presenter asked whether this document should be published as an RFC, or just dropped. Brian Carpenter indicated he thought the document was worth publishing, and is ready for WG LC. The IPv6 UDP Zero Checksums, Marshall Eubanks, 20 min. ====================================================== IPv6 UDP Checksum Considerations, draft-ietf-6man-udpzero-04.txt, UDP Checksums for Tunneled Packets, draft-ietf-6man-udpchecksums-01.txt Review: To allow UDP checksum to be zero under certain constrained circumstances. The circumstances are basically those when the UDP header is in an outer header around an inner packet with suitable error checks. The latest versions includes tightening the language and error messages. The revision added more text on keep-alives, indicating that they should be sent both with 0 and valid checksums. There was discussion of consistency of the AMT draft on the Mboned list. There should be no code change to the deployed AMT code. This has to be standards track, since this updates RFC 2460. Marshall indicated that with the next very minor revision, this is ready for WG Last Call. Checking the room, there were a modest number of hands showing support, and no opposition. Thomas Narten spoke in support of sending this to last call, and indicated that the small number of hands in the room may be due to it having fallen off people's radar. Bill Fenner speaking for Brian Haberman asked if someone was explicitly tasked to check the AMT consistency with this work. Thomas Narten suggested that AMT consistency checking should be left to the Mboned / AMT community. Energy Aware IPv6 Neighbor Discovery Optimizations, draft-chakrabarti-nordmark-energy-aware-nd-01.txt , Samita Chakrabarti, 15 min. ======================================================================= The motivation is to reduce signaling overhead, and thus reduce energy expenditure. This work is based on ideas from the 6lowpan work. The slide attempting to describe the energy impact of adding networking to devices promoted a lot discussion. Which devices have impact? Which devices move from mostly idle to always on? There is new text describing mixed-mode operation. There is now an "E" bit in the RA to distinguish which mode of operation is in use. And details of how to use the bit and when to exhibit what behavior. Details are provided on the NCE management. Sleepy nodes must support the pure energy aware operation in order to be able to sleep safely. There are several interoperable implementations of the 6lowpan work that this is based upon. There is text to address the handling of ND oriented DoS attacks. This relies on all the hosts participating in the energy-aware operation. Jeff Mulligan asked exactly what the point of the document is. Is it to enable sleeping nodes? Erik Nordmark emphasized that the goal is to reduce the needless of waking of nodes. The discussion then indicated that this will not save all of the networking costs of the devices. There was agreement that the savings were not 100%, but that it helps. Jeff Mulligan asked if this is exactly the same as the 6lowpan solution, or merely based on it? The authors answered that this is an adaptation of the 6lowpan work, and is not the same as the 6lowpan work. Erik Nordmark explained the reasons for the differences. Samita then requested that the working group adopt this as a WG document. Jari commented that this is an interesting space that needs to be addressed. He is concerned as to whether this is the right answer. He is also concerned as to what the shape of the overall solution is. There was discussion of whether to solve known pieces, or to first do a whole system analysis / architecture. Dmitri then asked what kinds of hardware this is applicable on, as distinct from hardware where the savings will be in the noise. The speaker also asked whether there is dependence on EUI-64 and whether it is legitimate to count on EUI-64. Margaret Wasserman agreed that looking at energy consumption in general would be a good think. She then noted that this proposal is an answer to existing issues. She emphasized that people are already noting that differences between IPv6 and IPv4 compliant behavior significantly affects battery lifetime and responsiveness. Stuart Cheshire reinforced Margaret's feedback. His point is that the total energy savings is less important for many cases than the battery lifetime extension. Next Questioner then returned to the topic of how much energy this proposal could save. Igor Gashinsky indicated that this would be very useful to the data center space, particularly for the DoS avoidance. Debate then ensured between Jari as AD and other folks about how to approach the work. Margaret indicated that there are a number of other issues that she thinks need to be addressed. She emphasis that the steps for coming up on a network are a lot of work, and that we should support nodes that need to wake up, send a packet, and then go to sleep. Ralph Droms asked Margaret to write up her ideas (e.g. as an I-D) soon. Kerry Lynn indicated support for this work. He relayed some explanations of the background on the numbers on the slides. Jari Arkko returned to the request for an understanding of what the issues are, the bigger picture. Transmission of IPv6 over MS/TP Networks, draft-lynn-6man-6lobac-02.txt, Kerry Lynn, 15 min. ======================================================================== The goal of the MS/TP work is to develop a low-cost wired IPv6 solution for commercial building control applications. The proposal builds on MS/TP which is based on IEE RS485. The proposal is part of the ISO/ANSI/ASHRAE BACnet work. This work builds on ideas from 6LoWPAN. They are proposing changes to MS/TP, which they are calling 6LoBAC. Backwards compatibility with existing MS/TP nodes is an important goal. The proposal extends the MS/TP frame, and uses COBS encoding to avoid frame header confusion. This uses 6LowPan without Mesh, broadcast, or fragmentation headers. It can be used with RFC 6282 IP Header Compression. There is a specific proposal to use the 8-bit MAC address to form the IPv6 Interface ID. Bob Hinden clarified that the point of the draft is to explain how to use IPv6 over this particular kind of data link. Jari indicated that he supports the work and would like to see it as a WG item. He checked, and only a modest number of people in the room had read the draft. Pascal emphasized the large number of MS/TP networks in use in the world. Kerry agreed on the importance. Commenter emphasized that we need this work, and we should not plan on a different working group for each media we want to support IPv6. Brian Haberman (remote co-chair) also spoke up in support. The poll of the room showed significant support for making this a WG draft, with no opposition. An Offset Indicating Option for IPv6, draft-zhang-6man-offset-option-01.txt , Brian Carpenter, 15 min. ================================================================ The proposal is intended to simplify the process of skipping the extension headers to find the payload. The approach is to add an option in a specific place in the IPv6 options header (or the hop-by-hop options header if one is present) to help the processor find the end of the header chain. This does not affect transport layer security, nor on the transport pseudo-header. IPSec implementations MUST NOT use this information and skip headers. Erik Nordmark asked whether there is a potential attack vector because some folks (like the firewall) follow the skip instructions while another party like the end host follows the full header chain. Brian responded that the firewall can not use this for skipping. Rather, it is other devices such as classifiers or load balancers which may be able to use this skipping information. Mark Townsley asked how this would interact with IPv4 in IPv6. Brian clarified that it would point at the IPv4 header, which is what IPv6 thinks is the payload. Lorenzo pointed out that extension headers do not survive in the wild anyway, so what is the value? Further, he said that you want to help the middle-boxes, not the hosts. There is agreement from Brian. Finally, Lorenzo is concerned that having two sources of truth about the header structure increases fragility. Brian agreed that it is important that implementations need to be careful about buffer overflows. Brian noted that there is an IPR disclosure. There is a serious security issue if the firewall does not understand this, and the host does. Questioner and Brian agreed that this must not be used in conjunction with fragmentation. Benedikt Stockebrand asked about what the tradeoff is. Are we spending bandwidth and protocol complexity to save processing in a few boxes? Particularly since the devices which might see a savings would still need to be able to handle packets without this option. Could this mean that we end up being less efficient instead of more efficient? Brian indicated that the bandwidth effect is not a big deal, but agreed that the other issues need to be thought about. Claudio raised another case, namely mobile IPv6 where this seems not to apply. Clarification was provided that this option is added by the original packet source. Enhanced Duplicate Address Detection, draft-hsingh-6man-enhanced-dad-02.txt , Hemant Singh, 15 min. ============================================================= This is an enhancement to cope with the case where DAD messages are accidentally looped back to a source, currently misleading the source about address collision. This problem has been observed in real networks. There are also some cases with two cable modems and a hub where there also be spurious collisions. Available mitigations are to turn off DAD, or to use something like PPP that can detect loopback. But we would like to be able to use DAD. So add a nonce option to the non-SEND DAD probe. Side-note that SEND should note that it's nonce can be used to detect loopback. And in mixed networks the SEND and non-SEND nodes MUST use the same length nonces. The proposal clarifies the collision and loopback detection behaviors. The presenter then asked that this become a working group document. Lee Howard agreed that there is a real problem that needs to be solved. He then asked for clarifications on some of the use cases where this comes up. Erik Nordmark indicated that from his perspective it doesn't matter what the exact cause of the loopback. The point is that there are cases of loopback that are not known to the upper layer. This improvement seems like a no brainer and should be done. Suresh Krishnan asked what the scope of this is. Which devices need to do this. The answer is that they mean all 4861 routers must do this. There is agreement that there needs to be clarification that routers need to do this on all interfaces even if they send RAs on only some interfaces. Stuart Cheshire indicated support for this direction. He raised another case, namely the use of sleep proxies, where the host would receive the proxied advertisement and shut down. So he agrees this is important. Bob Hinden agreed that we can send a call for adoption when the authors indicate it is ready. =========================== Meeting Adjourned ===========================