IETF 77 6lowpan WG Minutes Monday March 22 2010 1300-1500 ---------- Agenda: Introduction - Chairs Milestones - Chairs HC Draft - Jonathan Hui ND Draft - Zach Shelby Erik Nordmark/Samita Chakabarti Chairs IEEE 802.15.4 2006 - Rene Struik DHCP - Jonathan Hui ---------- Meeting Discussion: -- Introduction Carsten provided an introduction to 6lowpan and the agenda as well as an overview of the WG milestones Review Milestones --6 deliverables --2 are mostly done --header compression with a view to solve --routing requirements --use cases finished last call; waiting for new document from authors -- HC Draft Jonathan Hui presented the current status of the 6lowpan HC draft draft-ietf-6lowpan-hc-06. There were no updates since the last IETF in Hiroshima. Fragmentation: In WGLC there were a number of comments related to fragmentation handling. The issue relates to the offset and length values. In 4944 these values reference the uncompressed values. If the fragmented information is not in the first fragment reassembly doesn't know proper sizes. TWO Options: (1) No Change to 4944 - requires compressed fields MUST NOT be included in subsequent fragments; drop datagram when need to expand unsupport headers. (2) Change 4944 - change offset/length to compressed values; create new fragment header. Consensus on list - "no change to 4944" SLAAC with Short Addresses: Problems: 80-bit prefix uniqueness requires link-layer management; collision when PANIDs differ only U/L bit; IPv6 address changes when PAN ID changes Proposal: Define IID to 17bits -- ND Draft Draft-ietf-6lowpan-nd-08 Working on this since Dublin Hiroshima - had some roadblocks Concensus separate the document into: Base ND Optional backend solutions as separate drafts make address detection optional when address formed from an EUI-64 when address assigned using DHCPv6 What is nd-08? Just the base mechanism Optimizes the host-router interface Node Registration mechamism with NR/NC DAD performced when needed by default router Incorporates the new autoconf addressing model Current Issues Nits from Richard Kelsey & Robert Cragie Fix the integration of DHCPv6 return lease info to the host somehow or host implements dhcp Clarification on prefixes and context ID assignment Simplification & optimization still possible How to support DAD? What kind of registration message do we need? Simple Neighbor Discovery WG push back in Hiroshima on complexity Took approach to start from nothing and add a minimal set What is missing in RFC4861? issues arise in route-over when a single subnet spans mult. links performance issues around ND multicasts DAD assumes link-local multicast packets can be used to find duplicates For EUI-64 derived, we can skip DAD Where is the host? implies a need for registration host might switch to a different router Distribute prefixes from edge all the routers and hosts need to know the prefix assume the prefix(es) configured in 6lowpan border routers Reduce Multicast Highlight of draft --concepts of 6LBR, 6LR and host --ND options --clarifies prefix Approach --configuration same as nd-08 --registration uses new node lifetime option --A new Authoratative Router option in RA Loosing the default router --NUD can be used (unicast NS/NA) What's missing from current draft? carry the compression contexts with the prefixes select router closer to the edge Security Can secure ND be used in the future? Open issues short address support: is DHCPv6 on host what we want? NUD vs L2 acknowledgements Avoid multicast RS 802.15.4 update 2003 vs 2006 --more generout payload size --security overhaul 802.15.4 TG4e --overhead reduction DHCP 6lowpan networks need configuration --application; network; vendor-specific why DHCPv6? --stateless & stateful --relay agents fit well for route over --general & extensible --take minimal pieces of dhcpv6 6lowpan edge routers --must implement dhcp server or relay agent --must subscribe to 6lowpan routers --must implement relay agent (simple/stateless) overall affect eliminate binding to a specific DHCP server no server discovery no state about servers dhcpv6 compaction assume eui-64 for client id summary of messages solicit / resent (58 octets) reply (52)