I'm in, too. As I said before I already worked to profile it for 6LoWPAN nodes. It must be good to exchange more specific idea. :) If you are in Vancouver, i'd love to meet and discuss. Let me know.
-eunah On 12/4/07, Zach Shelby <[EMAIL PROTECTED]> wrote: > Pascal, > > I am on the same line with you here, and would love to see an RFC coming > from the WG effort defining a minimum profile of lowpan and IPv6 > features. Jonathan and I wrote an interop ID, presented in Chicago, > which could actually be used as a base for writing a 6lowpan profile ID. > I would be willing to work on this. Could you guys please discuss this > during the WG meeting.. > > I know that 802.15.4+lowpan+IPv6+UDP can be implemented on minimal 8-bit > uCs, we can achieve interoperability (in vendor groups right now), and > other standards bodies would be smart to use 6lowpan; but we have to > communicate that clearly outside the WG. RFC 4944 is too cryptic for > this purpose, and a lot of information needs to be gathered from many > places. > > - Zach > > Pascal Thubert (pthubert) wrote: > > 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 > > > > > -- > Zach Shelby | CTO | +358 40 7796297 > Sensinode Ltd. www.sensinode.com > > _______________________________________________ > 6lowpan mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/6lowpan > _______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
