Minutes 6LoWPAN Working Group - IETF 72 Dublin Ireland - July 2008 ================================================================== Thanks to David Culler and Paul Chilton for taking notes. Agenda: * Intro (Admin and Status) (20m) * 6LoWPAN Bootstrapping and 6LoWPAN IPv6 ND Optimizations (65m) * 6LoWPAN Improved Header Compression (20m) * 6LoWPAN Architecture (10m) * 6LoWPAN Routing Requirements (10m) * Use Cases for 6LoWPAN (10m) * 6LoWPAN Security Analysis (10m) * Other work (15m) Discussion: ---- Intro ---- Carsten introduced 6LP WG to newcomers Status - charter in place, existing 2 RFC for Ipv6 over 15.4. Lot of industry activity in this space. Charter 6 items, two areas for standards, 4 areas for informational, implementers guider/interop no timeframe 1) Bootstrapping and 6LP IPv6 ND optimisation – drafts discussing available. Try to do without multicast 2) Improved header compression 3) Architecture discussion doc 4) Routing requirements – also ROLL 5) Use cases – benchmarks/scenarios on use of 6LP 6) Security – analysis of 6LP for which exisiting stds can be used, whats needed ---- Bootstrapping and ND ---- 5 drafts Terms introduced by Carsten Commissioning – telling device what it is meant to do in network – outside lowpan chater Bootstrapping – how network forms after devices know what they are going to do, also when new node enters exisiting network, security authentication etc.-in charter. How to bootstrap Where is information, use ND, DHCPv6 or invent new proto eg LBP. Charter has strong bias to reuse existing How expensive – messages and code size Stability – how stable is existing protocol in new usage? Can it cope with more dynamic network -- KH Kim: Commissioning in 6LP Presentation -- - Not discuss protocol, just open issues and ask opinions of community - Need to define Bootstrapping architecture from requirement in 6LP use cases - What Bootstrapping info needed - Different from Wifi as no keyboard etc – does this need new protocol? - If Multiple 6LP – how to choose pan to join - Is Bootstrapping differenting in open/closed pans? allow bs traffic from unauth devices? - What is necessary protocol – reuse ND/DHCP or use lightweight bootstrap protocol – LBP - Draft proposal LP Bootstrap Info Base LIB, bootsrap procedure vs beacon structure? LIB explanation – pan specific and device specific PAN – can be given by routers, device is downloaded LBP agent like DHCP agent Proxy with existing protocol server – authentication LBP frame Summary – define BS operation, then protocol Discussion: Zach Shelby – Think nd dhcp better way to do. Don’t define new proto, maybe use ideas with nd Dave Culler – think of it as steps to do before Geoff M – think of which channel for radio, what panid, where does this come from – arch doc – don’t think dhcp can do this – as need to get on network in first place – cant be hand-tooled manually – needs to happen automattically – between comm and bootstrap Jonathon – parameters – ch hopping – sequence, time for link specific – how to define info base? Kim – agree need to find what info needed Emanuel Bert? Inria – autoconf – no consensus on dhcp – very interested what is happening in 6LP -- Chakrabarti: ND option udpate (draft 05) with Erick Nordmark -- - Main goals: minimize multicast msgs in RA, RS, NS and NUDs reduce or avoid DAD - Application to other non-multicast networks - Supports star and mesh topologies - Changes added experimental values for ND variables maxRAadvtime = 1500s, RouterAdvLife=7200s section on fault tolerance used nrodmark-reg-00 to sne backup on-link sequence of typical operation sin 6lowpan net - Bootstrapping info assignemnt of IPv6 prefix and default router auto-conf and optional node reg additional ipv6 router ingo key derived by some other mechanism - Next handle short addresses use anycast for router solicitation remove PAN coord assumption cleanup finalize default values - Can this do full mesh topology – difficult to support L2 full mesh, but L3 is easier -- E. Nordmark: ND registration -- - design to avoid multicasts in DAD, NS for hosts, for non-existing hots - can avoid if routers know all the IP addresses on the link - may have applicability outside 6LoWPAN - add option to RA to ask host to register periodically to address set - add registration message (periodic, unacked) set of IP addresses provides redundancy - might be able to use secure ND extensions to reduce messages open issues if registry is not on the router it doesn't knwo the registration period should there be a lifetime? should the be in 6man - this is changing the way the message flow works in ND should we look at everything initiated from the host? Discussion: Vint Cerf – new to 6LP, running nwk in house – Nodes at endpoints are not forwarders, or can every device forward? Geoff– it depends, some nwks all nodes same, but 15.4 give ffd and rfd, 6lp allows both type of model. VC – distinctions necessary, detect and report is distinct from routing – to gather topology info many ways. Geoff – 15.4 says rfd cannot talk to anything other than ffd D. Culler - if "heartbeat" is going to be architected in would we want to use it as broadly as possible Choi - how does a node know to send registration messages would need to have RS to triger the registration mechanism - hard state would obviate need for DAD softstate sufficient if registry keeps a record - but need NACK when duplicate appears Thubert - would not tie registration with heartbeat, example in mobile situation registration rate may be best as a node decision -- P. Thubert: Whiteboarding -- - 6 LoWPAN backbone router - ISA example with backbone router - backbone link federates a bunch of routers - impractical to register with all the BB routers - ND registration with 1-2 routers, Proxy ND between BBRs raises core question of "What is a link?" what is the scope of a link? What is my link local scope? - change of BB router is supposed to be transparent, so cannot - define LL as all node registered with BBR - mapping of PANs is unclear - natural unit of uniqueness is entire thing - eliminate ND mcast avoid RAs: rely on ANYCAST functional address, mapped by default coord/AP avoid NS/NA new unicast reg. mechn from anycast (or optimistic) address to a WB (BBR) that performans proxy ND - ND is a reactive protocol scoped on a link - vs. stateful registration (like mobile IP home agent) hardstate on BB router - version 2 new binding ICMP msg: binding solicitation, binding ack, well known anycast addresses 6LOWPAN_BBR for the routers 6LOWPAN_NODE for the nodes reserved link local unicast addresses - binding solicitation (node => BBR to set up hard state) inspired by mobileIP - binding confirmation (BBR acks that it is responsible for registration) proxy ND Discussion: Culler: wouldn't it be advantageous to recognize a border rotuer that is not specific to the backbone organiation with a single egress point called a gateway PT – mobility is the thing trying to deal with Chakrabarti: clarify that BBR forward link local addresses PT - yes, through ND proxy Chakrabarti: Is binding solicitation part of ND options PT - no it was wierd to trick NS to do this, so new ICMP message Chakrabarti: Is HA in the scenario somewhere? PT - yes, ND proxy layer with registration agent behind it Shelby: if proxy ND is optional, this simplifies to Border router PT - yes, we should do that Baccelli: can we have a link model on ad hoc networks E. Nordmark: can we decouple ND optimization and ND proxy or do they need to be tied together PT - what if you register in two places Baynum: are you assuming that on lowpan devices are only mobile. Can BBR be mobile. Razelli: does proxyND consider address timeout PT - yes, there is a binding lifetime -- Jonathon Hui: ND and autoconf -- - every 6LoWPAN node could be a IP router - border router connects to other type of networks - provides IP level visibility into radio connectivity - Define ND protocol based on 4861 - bare minimum - border rotuer as minimal configuration point, eg. prefixes - discover routers (regardless of routing protocol) - configure nodes - Addressing model - IID MUST be derived from 15.4 addrs - global scoe EUI-64, local scope - shortaddress - Uniqueness maintained by other mechanisms - manual, DHCP, registrarion, DHCPv6, ... - IPv6 addresses form a common set of prefix - ND summary - nodes disseminate in using RA messages - prefix ingformation in RA with sequence number - manage RA transmission using trickle algorithm (NSDI 2004) - ability for Router to solicit additional information - router is using ND to configure itself - DHCPv6 - 6lowpan routers act as DHCP relays Discussion: Shelby - love ND optimiziation - not positive about DHCPv6, too much overhead JH: All fits in 32k device. Centralised server vs whiteboard – same thing? Cerf: reinvented packet radio network on middle 80s. regarding whiteboard, once anycast and multiple objects that represent same thing, need to have other mechanisms to make indistinguishable. Eric: link local address only in radio link? How to do routing on global and local addressing. LL useful for communicating between neighbours. DC – only route global addresses, LL cant be routed. PascalT: – loopless propagation needed- default with by seq. Propagation can cause problems. Broadcast and pruning? Hui - that is what sequence number is for: well established dissemination and state mechanism Sarikaya: how do you distinquish link local and global Hui: LL is well-known prefix (FE80) Kim: what is the RS proceedure Hui: common prefix is disseminate as required by context compression using link local all nodes multicast (at L2 it is implemented as a broadcast) Choi: if IPv6 address is formed from MAC address it disables SEND Hui: correct Baccelli: unaware of what trickle is. Is this naive broadcast? Hui: suppression based both on density and rate of change Satohi: draft looks very good from Hitachi implementation experience. it is practical Cartsen: What do we do with these five drafts? - four clearly distinct proposals, need to work on sorting out differences - not simply a matter of picking one at this stage - authors need to come together and find a common way forward Thubert: propose form a design team and bring them together. - charter for design team EricN: – get together and chat on ND opt and whiteboard -- J. Hui: Header compression -- Hop limit compression – 2 bits, multiple prefixes contexts, split traffic class, UDP checksum 2 bit address mode, 2 bit context info Check sum - separate LOWPAN_UDP afrm ISA100_UDP - deal with two headers if want to have option of compressing checksum Should HC become WG doc Deprecate HC1/HC2? Discussion: Eric: – compress UDP at border router. PascalT: ISA add new checksumn, bigger. EricN: Broken on ISA 100 – stronger checksum ok but not same UDP protocol number -- Carsten – context based HC -- Add into ND work, need to discuss ND still. Compress global prefixes, agree on what common state is. How to get agreement, who are part of agreement. Issues in outbound, inboud and node-node. Take this to the list, how to decide things have got context -- Carl Williams: Mobility -- - mobile node moving through PAN - mobile PANs - propose to consider up front => will it be in architecture document or in separate doc -- MIB for 6LoWPAN -- - is SNMP pull model the right approach - what is the information set and how do we get access to it?