Hi Geoff: It's not just about IPSec though:
There are a number of companies out there designing and integrating silicon for LoWPANs. IPv6 is not necessarily a target for them when it does not mean immediate sales. Also, they do not necessarily know what supporting IPv6 means for their devices and what the associated cost will be. They could use some help and we can provide it in the form of an RFC that summarizes a LoWPAN profile for IPv6. That profile should not include IPSec; that profile should include 6LoWPAN - RFC 4944 is not listed in RFC 4294 for obvious reasons-, and the ND solution we will come up with. That profile should be designed to enable very low end embedded systems (an 8-bit processor in my Mc D's toy) to run IPv6. Once we have that published with IETF stamp of approval, it becomes possible for people out there to: - guarantee interoperability - develop and distribute an opensource stack - publish actual numbers for footprint and performance on various implementations - go to standard bodies such as ISA SP100 and present those numbers to support IPv6 adoption. I do think it is worth the effort. If 6MAN is the place, so be it. Pascal >-----Original Message----- >From: Geoff Mulligan [mailto:[EMAIL PROTECTED] >Sent: Friday, November 30, 2007 5:01 AM >To: gabriel montenegro >Cc: 6lowpan >Subject: Re: [6lowpan] RE: [RSN] Here is the new RL2N Proposed Working Charter > >I will search back, but m recollection was that we (you) did argue with >the IESG that devices such as these (small 8bit micro sensors) would not >be capable of IPsec and after a few emails back a forth we were told >that 6lowpan devices did not need to support IPsec. > >Again I will look back and see if I can find the email exchange and I'll >ask Russ. > > geoff > >On Thu, 2007-11-29 at 17:13 -0800, gabriel montenegro wrote: >> Geoff, >> >> Could you please provide a pointer to the message or document with >> that exception? >> This is an important item and it should be added to the group's Wiki >> page. >> >> My recollection is different, but I may have just forgotten. What I >> recollect is that back when we >> were starting the working group and initiating work on the problem >> statement draft, was that the recommendation >> was to stay away from issuing our own IPv6 profile, precisely because >> saying things like ("IPsec is not recommended in lowpan >> environments") was a sure-fire way to invite controversy at the IESG. >> E.g., IPv6 mandates IPsec, so how could >> we ever claim to support IPv6.... This debate probably is better had >> in 6man in terms of a revision of the hosts >> requirements, rather than in any particular WG. >> >> -gabriel >> >> ----- Original Message ---- >> From: Geoff Mulligan <[EMAIL PROTECTED]> >> To: Kris Pister <[EMAIL PROTECTED]> >> Cc: 6lowpan <[EMAIL PROTECTED]> >> Sent: Thursday, November 29, 2007 11:09:02 AM >> Subject: Re: [6lowpan] RE: [RSN] Here is the new RL2N Proposed Working >> Charter >> >> We did not try to get an exception to UDP checksums. >> >> geoff >> >> On Thu, 2007-11-29 at 10:59 -0800, Kris Pister wrote: >> > Geoff - ooh, I like exceptions. >> > Did we try to get an exception on the UDP checksum? It's painful >> to >> > leave that in the compressed header if we have L2 message integrity. >> > >> > ksjp >> > >> > Geoff Mulligan wrote: >> > > We have already received an exception from the IESG to IPsec on >> 6lowpan >> > > devices. >> > > >> > > geoff >> > > >> > > On Thu, 2007-11-29 at 16:09 +0100, Pascal Thubert (pthubert) >> wrote: >> > > >> > >> Hum... >> > >> >> > >> I had missed that; Seems that we have to make an exception :) If >> you consider ISA100.11a, they already have security at L2 and L5, it >> makes little sense to MUST IPSec on top of that. >> > >> >> > >> Pascal >> > >> >> > >> >> > >>> -----Original Message----- >> > >>> From: Kris Pister [mailto:[EMAIL PROTECTED] >> > >>> Sent: Wednesday, November 28, 2007 8:03 PM >> > >>> To: Pascal Thubert (pthubert) >> > >>> Cc: 6lowpan >> > >>> Subject: Re: [RSN] Here is the new RL2N Proposed Working Charter >> > >>> >> > >>> Hmm. From 4294: >> > >>> >> > >>> "However, while authentication and encryption can each be NULL, >> they >> > >>> MUST NOT both be NULL." >> > >>> >> > >>> ksjp >> > >>> >> > >>> Pascal Thubert (pthubert) wrote: >> > >>> >> > >>>> Hi Kris: >> > >>>> >> > >>>> For your question on ESP, AFAIK, RFC 4294 only mandates NULL >> encryption and authentication for >> > >>>> >> > >>> interoperability reasons. >> > >>> >> > >>>> On the general question of RFC 4294 itself: I'm not sure the >> work was ever done. I hope someone >> > >>>> >> > >> >from the list can help? >> > >> >> > >>>> If the answer is unclear, and considering that we are >> re-chartering the group, maybe we could have >> > >>>> >> > >>> a work item to specify the instantiation of RFC 4294 for LoWPAN >> nodes? >> > >>> >> > >>>> Pascal >> > >>>> ________________________________________ >> > >>>> From: Kris Pister [mailto:[EMAIL PROTECTED] >> > >>>> Sent: Wednesday, November 28, 2007 5:42 PM >> > >>>> To: Pascal Thubert (pthubert) >> > >>>> Cc: 6lowpan >> > >>>> Subject: Re: [RSN] Here is the new RL2N Proposed Working >> Charter >> > >>>> >> > >>>> Is there an email thread somewhere that discusses the impact on >> 6LoWPAN of the security >> > >>>> >> > >>> requirements of 4294 and 4303? >> > >>> >> > >>>> My first quick readthrough makes me very uncomfortable that >> some of the mandates are going to be >> > >>>> >> > >>> ugly from a header standpoint. >> > >>> >> > >>>> ksjp >> > >>>> >> > >>>> Pascal Thubert (pthubert) wrote: >> > >>>> Hi JP: >> > >>>> >> > >>>> Thanks a bunch for this charter. I'll try not to rephrase what >> was already discussed with Christian, >> > >>>> >> > >>> Anders, Philip and Misha. >> > >>> >> > >>>> There's an additional item I'd wish to see either in ROLL or >> 6LoWPAN and I do not know exactly >> > >>>> >> > >>> where it belongs, maybe both. The question is whether we need to >> and can document how RFC 4294 >> > >>> applies for sensors, and M2M devices in general, whether they >> act as hosts or as routers. >> > >>> >> > >>>> I've seen IPv6 presented as a Pandora box that drags just too >> much stuff to be incorporated in a >> > >>>> >> > >>> sensory device. For instance, at the moment, SP100.11a endorses >> 6LoWPAN formats but it's not so clear >> > >>> at all that IPv6 itself is mandated. A clear spec with >> well-documented implementation could be a >> > >>> formidable tool to despond to Fear, Uncertainty and Defiance. >> > >>> >> > >>>> So maybe we do not need DHCP (a MAY in RFC 4294) and maybe can >> do without multicast at all if ND is >> > >>>> >> > >>> supported some other way (such as suggested in: >> http://www.ietf.org/internet-drafts/draft-thubert- >> > >>> lowpan-backbone-router-00.txt). Maybe NULL encryption and >> authentication is enough etc, etc... >> > >>> >> > >>>> Being able to define one minimum set and maybe a few other >> profiles for the use cases that we >> > >>>> >> > >>> selected could help tremendously. >> > >>> >> > >>>> Otherwise I find the charter real well written and easy to >> digest. >>From the MANEMO experience, I >> > >>>> >> > >>> expect that some arguments about the relative applicability of >> existing MANET protocols will be >> > >>> difficult to prove without some good simulation work running >> agreed-upon scenarios. >> > >>> >> > >>>> Finally, I'm a bit confused that it seems that both IPv4 and >> IPv6 seem supported. Ipv4 comes with a >> > >>>> >> > >>> lot of overhead like DHCP. I suggest that when trouble comes and >> things can not be done in a common >> > >>> fashion for both IP protocols, hen we prioritize IPv6. >> > >>> >> > >>>> Unfortunately, I can not make it to Vancouver, but I do feel >> that the work is really needed so >> > >>>> >> > >>> please count my vote in for the adoption of the WG. >> > >>> >> > >>>> Cheers, >> > >>>> >> > >>>> Pascal >> > >>>> >> > >>>> >> > >>>> -----Original Message----- >> > >>>> From: Jean Philippe Vasseur (jvasseur) >> > >>>> Sent: Wednesday, November 21, 2007 9:19 PM >> > >>>> To: [EMAIL PROTECTED] >> > >>>> Subject: [RSN] Here is the new RL2N Proposed Working Charter >> > >>>> >> > >>>> Dear all, >> > >>>> >> > >>>> As promised, here is the new proposed Working Group, which >> reflects the >> > >>>> number of comments/suggestions that we received, the pre-WG >> consensus, ... >> > >>>> >> > >>>> Thanks to Dave Ward (RTD AD) for his input. >> > >>>> >> > >>>> Proposed RL2N WG Charter >> > >>>> >> > >>>> Description of Working Group >> > >>>> >> > >>>> L2Ns (Low power and Lossy networks) are typically composed of >> many embedded >> > >>>> devices with limited power, memory, and processing resources >> interconnected >> > >>>> by a variety of wireless links, such as IEEE 802.15.4, >> Bluetooth, Low Power >> > >>>> WiFi. >> > >>>> >> > >>>> L2Ns are transitioning to an end-to-end IP-based solution to >> avoid the >> > >>>> problems of non-interoperable networks interconnected by >> protocol >> > >>>> translation gateways and proxies. In addition, L2Ns have >> specific routing >> > >>>> requirements that are not currently met by existing routing >> protocols, such >> > >>>> as OSPF, IS-IS, AODV, and OLSR. L2N path selection must be >> designed to take >> > >>>> into consideration the specific power, capabilities, attributes >> and >> > >>>> functional characteristics of the links and nodes in the >> network. >> > >>>> >> > >>>> >> > >>>> There is a wide scope of application areas for L2Ns, including >> industrial >> > >>>> monitoring, building automation (HVAC, lighting/access >> control), connected >> > >>>> home, healthcare, environmental monitoring, agricultural, smart >> cities, >> > >>>> logistics, assets tracking, and refrigeration. The L2N WG will >> focus on >> > >>>> routing solutions for a subset of these deployment scenarios, >> namely >> > >>>> industrial, connected home/building and urban applications. The >> Working >> > >>>> Group will determine the routing requirements for these >> scenarios. >> > >>>> >> > >>>> >> > >>>> The Working Group will provide a routing framework for these >> application >> > >>>> scenarios that provides high reliability in the presence of >> time varying >> > >>>> loss characteristics and connectivity while permitting >> low-power operation >> > >>>> with very modest memory and CPU pressure. >> > >>>> >> > >>>> >> > >>>> The Working Group will pay a particular attention to routing >> security and >> > >>>> manageability (e.g self managing/configuration) issues, which >> are >> > >>>> particularly critical for L2Ns. >> > >>>> >> > >>>> Work Items: >> > >>>> >> > >>>> - Produce use cases documents for Industrial, Connected Home, >> Building and >> > >>>> urban application networks. Each document will describe the use >> case and the >> > >>>> associated routing protocol requirements. The documents will >> progress in >> > >>>> collaboration with the 6lowpan Working Group (INT area). >> > >>>> >> > >>>> >> > >>>> - Survey the applicability of existing protocols to L2Ns. The >> aim of this >> > >>>> document will be to analyze the scaling and characteristics of >> existing >> > >>>> protocols and identify whether or not they meet the routing >> requirements of >> > >>>> the L2Ns applications identified above. Existing IGPs, MANET, >> NEMO, DTN >> > >>>> routing protocols will be part of evaluation. >> > >>>> >> > >>>> - Specification of routing metrics used in path calculation. >> This includes >> > >>>> static and dynamic link/nodes attributes required for routing >> in L2Ns. >> > >>>> >> > >>>> - Provide an architectural framework for routing and path >> selection at Layer >> > >>>> 3 (Routing for L2N Architecture) >> > >>>> * Decide whether the L2Ns routing protocol require a >> distributed, >> > >>>> centralized path computation models or both. >> > >>>> * Decide whether the L2N routing protocol requires a >> hierarchical routing >> > >>>> approach. >> > >>>> >> > >>>> - Produce a security framework for routing in L2Ns. >> > >>>> >> > >>>> Goals And Milestones: >> > >>>> >> > >>>> >> > >>>> April 2008 Submit Use case/Routing requirements for Industrial, >> Connected >> > >>>> Home, Building and Urban networks applications to the IESG to >> be considered >> > >>>> as an Informational RFC. >> > >>>> >> > >>>> August 2008: Submit Routing metrics for L2Ns document to the >> IESG to be >> > >>>> considered as an Informational RFC. >> > >>>> >> > >>>> September 2008: Submit first draft of the Routing for L2Ns >> Architecture >> > >>>> document (summary of requirements, path computation model, >> > >>>> flat/hierarchy,Š). >> > >>>> >> > >>>> November 2008: Submit Protocol Survey to the IESG to be >> considered as an >> > >>>> Informational RFC. >> > >>>> >> > >>>> January 2009 Submit Security Framework for L2Ns to the IESG to >> be considered >> > >>>> as an Informational RFC >> > >>>> >> > >>>> February 2009: Submit the Routing for L2Ns Architecture >> document (summary >> > >>>> of requirements, metrics and attributes, path selection model) >> to the IESG >> > >>>> as an Informational RFC. >> > >>>> >> > >>>> March 2009: Recharter. >> > >>>> >> > >>>> >> > >>>> Please comment/suggest/... >> > >>>> >> > >>>> See you in Vancouver. >> > >>>> >> > >>>> JP and David. >> > >>>> >> > >>>> >> > >>>> _______________________________________________ >> > >>>> RSN mailing list >> > >>>> [EMAIL PROTECTED] >> > >>>> https://www1.ietf.org/mailman/listinfo/rsn >> > >>>> >> > >>>> >> > >>>> >> > >>>> _______________________________________________ >> > >>>> RSN mailing list >> > >>>> [EMAIL PROTECTED] >> > >>>> https://www1.ietf.org/mailman/listinfo/rsn >> > >>>> >> > >>>> >> > >>>> >> > >> _______________________________________________ >> > >> 6lowpan mailing list >> > >> [email protected] >> > >> https://www1.ietf.org/mailman/listinfo/6lowpan >> > >> >> > > >> > > >> >> >> _______________________________________________ >> 6lowpan mailing list >> [email protected] >> https://www1.ietf.org/mailman/listinfo/6lowpan >> >> >> > > >_______________________________________________ >6lowpan mailing list >[email protected] >https://www1.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
