below On 10 Jun 2008, at 08:33, Pascal Thubert (pthubert) wrote: > > Per RFC 4944: > "The UDP header's checksum field is not compressed and is therefore > carried in full." > > The UDP checksum is not the only way to protect the IP pseudo header, > the UDP header and the payload. > ISA 100.11a is defining a transport-level security that does all this > and more, since it has a larger signature and provides mutual > authentication at the same time.
The end-to-end principle tells us that that is not good enough if that is not implemented between endhosts across the entire path - this is like saying that we're going across an Ethernet link, Ethernet's CRC32 is stronger than the UDP checksum, therefore we'll just leave out the UDP checksum and recompute it once we're across the Ethernet link. RFC4944 deliberately leaves the UDP checksum alone to preserve an end- to-end integrity check - if it is altered (compressed) and then altered back, you cannot be sure that errors have not been introduced (more likely software bugs than transmission errors). Those errors cannot be easily detected by an endhost, because the checksum has been recomputed and is no longer a valid end-to-end check. A recomputed checksum is far less useful for protection - one reason why the IPv4 header checksum was simply removed in IPv6. > Also, the ISA100.11a transport-level security is usually > hardware-assisted, so it requires little power or CPU time on the > field > device, whereas UDP checksum will be a costly CPU operation. Sorry, false argument. google hardware-assisted UDP checksum. It's not computationally difficult or hard. When adding TLS and compressing the UDP header, is the UDP checksum verified across the entire payload and pseudo-header before this is done, to check that you're starting with good material? There's still an unavoidable need for a necessary UDP checksum computation there. If you're going to replace then recompute the checksum leaving the subnet, you need to compute it going in to check that what you're about to checksum across is good. > So ISA100.11a is an example where the UDP checksum could and actually > should be compressed over the LoWPAN, leaving it up to be > reconstructed > by a backbone router should the packet go any further than the LOWPAN > itself. > > Since bit 3 in the HC-UDP header is reserved anyway, it makes sense to > standardize it to mean that the UDP checksum is compressed, provided > that the headers and payload are equally or better protected than if > the > checksum was used. That misunderstands the end-to-end principle and the nature of protection across the entire path; it's really not equal, despite the weakness of the UDP checksum strength, because the UDP checksum is across the whole path between endhosts, and the TLS protection is not. Wait a bit, you'll probably want that reserved bit for something more useful in a while. (I am reminded of the furore over reusing the three MPLS experimental bits - that kept Stewart Bryant flying round the world for months.) > Then followed a thread entitled: > "[6lowpan] Compressing the UDP checksum" > > In short, there was a general agreement that this was doable under > circumstances; In particular, the current draft under review of > ISA100.11a transport section (under review) has the following text: > > " > 1.4.3 Eliding the UDP checksum > ISA100.11a uses both HC1 and HC2, and extends the UDP common > compressed > header encoding to compress the UDP upper layer checksum by relying on > the Transport layer security to provide the same service, and more. > For that purpose, the Transport layer builds an ISA100.11a pseudo- > header > by concatenating the UDP pseudo-header for IPv6 as described in the > previous section, the source UDP port and the destination UDP port: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + + > | | > + Source Address + > | | > + + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + + > | | > + Destination Address + > | | > + + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Upper-Layer Packet Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | zero | Next Header | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Source UDP port | Destination UDP port | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > The ISA100.11a pseudo-header is filled and placed before the UDP > payload > for the crypto process. If encryption is performed on the message, the > pseudo-header is not encrypted, but the pseudo-header is part of the > MIC > in any case. > Once the crypto process is completed, the pseudo-header is removed > from > the message, and the IP and UDP headers are put in its place for > transmission. On the receiving side, the transport layer will restore > the pseudo-header based on the received packet prior to the crypto > process to validate that none of the protected fields was tempered > with. spelling - tampered. > When HC2 is applied, bit 3 in the UDP common compressed header > encoding, > which is reserved in RFC 4944, is set to express whether the > checksum is > elided. When so, the 8 bytes of UDP header can be compressed down to a > single byte that contains the partially compressed ports, using 4 bits > each. > Note 1: When the packet is not protected by the Transport layer > security, the UDP checksum can not be compressed and must be carried > in > full as prescribed by RFC 4944. If Transport Layer Security is active > for a given packet, then the UDP checksum might be elided as > prescribed > above. > Note 2: If the UDP upper layer checksum field is elided, it is up to double space > > the other endpoint across the DLL subnet to recompute the UDP checksum > as part of the 6LoWPAN expansion, if necessary. This is required in > particular for a middlebox such as a backbone router that forwards the > uncompressed packet as opposed to terminating the transport. > Note 3: If the UDP checksum is not elided and security is applied, > then > the UDP checksum must be computed after the security operation is > complete and the security fields are filled. The UDP payload that is > used for the UDP checksum includes all data from the UDP header on, > including the security fields, application data and MIC fields, > whether > the application data is encrypted or not. > " > > This proposal provides better guarantees than the UDP checksum alone. > Part of it because the security signature is longer and the UDP > checksum, and part of it because that security authenticates the > data as > well. But it's only across the 6lowpan part of the path, not across the full path end-to-end, which is the UDP checksum's key feature. You're disobeying the spirit of the text in RFC2460. Do you really think that attention will be paid to the must in your Note 1? It's a slippery slope. > Would you agree that compressing the UDP checksum is valid in this > case? Sorry, it's not. I looked in vain for any mention of the end-to-end principle in the previous mailing list discussion. If you're only adding a header for tunnelling, UDP-Lite or something else can give you a sanity check across the tunnelling header alone, leaving protection of the tunnelled packet up to the checksum in that packet without the overhead of going over the entire paylaod. (IPv6 needs some sort of pseudo-header check from every transport protocol, and the IPv6 header doesn't have it, so UDP-Lite/IPv6 seems attractive. Leaving this up to transport layer designers seems a poor design choice.) But messing with payload integrity checks has subtle and far-reaching consequences. L. > Pascal > >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On >> Behalf Of > Lloyd Wood >> Sent: lundi 9 juin 2008 21:28 >> To: Mark Townsley (townsley) >> Cc: Geoff Mulligan; [EMAIL PROTECTED]; Jay Werb; Polyzois,Christos A; > Chernoguzov,Alexander (PA35); >> 6lowpan@ietf.org >> Subject: Re: [Roll] [6lowpan] ISA100.11a status and requirements(was > RE: New charter for 6lowpan) >> >> >> On 9 Jun 2008, at 17:34, Mark Townsley wrote: >> >>> Geoff Mulligan wrote: >>>> Mark, >>>> this is interesting news. This can save another byte and if there >>>> would be no large push against this then compressing out another > byte >>>> would be good. >>>> >>> I can't promise anything, but 6lowpan certainly isn't the only place >>> where the UDP checksum mandate in IPv6 is seen as unworkable. Pretty >>> much any UDP-based tunneling protocol running on a router in >>> hardware at >>> high scale or speeds is running into the same problem. >> >> The pseudo-header checksum is the only thing preventing misdelivery; >> the header gets checked once at the endpoint (IPv6) as opposed to >> being checked and recomputed at every hop (IPv4). >> >> I'm not convinced that the IPv6 design choices here were right - I'd >> have gone for a header checksum across immutable fields, skipping >> TTL, >> CoS and the like, that wouldn't require recomputing, and which would >> have constrained misdelivery to a single link, rather than the path - >> this would be more useful for resends and diagnostics, while >> increasing the pain for NAT. Here, IPv6 assumes a tight application/ >> application control loop and path where the cost of resending a >> packet >> across the entire path is low. >> >> That raw IPv6 header tunnelling sans UDP header (or GRE sans optional >> checksum or MPLS) lacks any self-checking mechanism for reliability >> should be of some concern. >> >> RFC2460 p28 section 8.1 Upper-Layer Checksums: >> >> [..] >> o Unlike IPv4, when UDP packets are originated by an IPv6 node, the >> UDP checksum is not optional. That is, whenever originating a UDP >> packet, an IPv6 node must compute a UDP checksum over the packet and >> the pseudo-header, and, if that computation yields a result of zero, >> it must be changed to hex FFFF for placement in the UDP header. IPv6 >> receivers must discard UDP packets containing a zero checksum, and >> should log the error. ^^^^ >> [..] >> >> That 'must' is clear and unambiguous. The side-effects mean that this >> should NOT be thought of as an optimization. >> L. >> >>> I know of >>> implementations today that zero out the UDP checksum, and IMHO a >>> good >>> implementation that is "liberal in what it accepts" would not drop > the >>> packet with a zero UDP checksum arriving over IPv6 (in fact, its >>> annoying that one would even have to differentiate between IPv4 and >>> IPv6 >>> at all here if you ask me). >>>> This is currently in the HC1g draft and would allow consistency >>>> between >>>> 6lowpan and SP100. >>>> >>> I suppose that isn't a bad thing. >>> >>> - Mark >>>> geoff >>>> >>>> On Mon, 2008-06-09 at 17:25 +0200, Mark Townsley wrote: >>>> >>>>> Geoff Mulligan wrote: >>>>> >>>>>> Aren't both abstractions equally valid? I think that the biggest >>>>>> issue >>>>>> with a mesh under is that there is no one standard for it. >>>>>> ISA100 is >>>>>> one; I have done another using AODVtiny; I think Jennic has one >>>>>> using >>>>>> their mesh protocol and there are others. If IEEE had defined a >>>>>> multi-hop L2 mesh then we could point at that and define a >>>>>> solution for >>>>>> ND and bootstrapping and security and ... for it. >>>>>> >>>>>> The WG decided a couple of meetings ago that we would focus on >>>>>> solutions >>>>>> for the Route Over abstraction. [If while we are doing this we >>>>>> can keep >>>>>> in mind some of the issues w.r.t. mesh under that's good.] >>>>>> >>>>>> Somewhat independent from this is the HC1G draft that is >>>>>> important to >>>>>> deal with since we do need a way to efficiently handle non-local >>>>>> addresses. So as to remove the mesh under vs. route over issues >>>>>> from >>>>>> the HC1G draft I would like to see the draft updated to remove >>>>>> the UDP >>>>>> checksum optimization. >>>>>> >>>>>> >>>>> I'm more optimistic about keeping the UDP checksum optimization. >>>>> There >>>>> are other forces at work which may relax the UDP checksum >>>>> requirement in >>>>> IPv6 in certain cases. So as long as you have well thought out >>>>> reasoning, I wouldn't be afraid of keeping it in. >>>>> >>>>> - Mark >>>>> >>>>>> I would like to ask the WG if we should consider taking >>>>>> draft-hui-6lowpan-hc-00.txt on a a WG document, with the change >>>>>> of >>>>>> removing the UDP checksum compression. >>>>>> >>>>>> geoff >>>>>> >>>>>> On Thu, 2008-05-22 at 09:14 -0700, Jonathan Hui wrote: >>>>>> >>>>>> >>>>>>> Hi Pascal, >>>>>>> >>>>>>> So let's drop the mesh-under/route-over terminology for a >>>>>>> second, I >>>>>>> think they are confusing since everyone seems to have a >>>>>>> different >>>>>>> definition for those terms. >>>>>>> >>>>>>> What I am mainly concerned about is the kind of IP Link >>>>>>> abstraction >>>>>>> 6LoWPAN provides: (i) an IP Link is formed by multiple L2 hops >>>>>>> (e.g. >>>>>>> 802.15.4 and possible others through a BbR), what I've been >>>>>>> calling >>>>>>> mesh-under (ii) an IP Link is defined by a single L2 hop (e.g. > the >>>>>>> radio range of 802.15.4), what I've been calling route-over. My >>>>>>> point >>>>>>> to Mark's concern was that solutions to some work items within >>>>>>> 6LoWPAN >>>>>>> will be different depending on our IP Link abstraction. From >>>>>>> what I >>>>>>> understand, ISA100.11a has chosen option (i). But to your point >>>>>>> below, >>>>>>> using IP routing to provide connectivity between nodes within >>>>>>> the same >>>>>>> IP Link doesn't seem right to me, so it'd be great if you could >>>>>>> help >>>>>>> me see a path to get there. >>>>>>> >>>>>>> A lot of this confusion can be cleaned up within the 6LoWPAN >>>>>>> architecture document. But I think Mark's concern still stands: >>>>>>> whether or not we're focused on one or both of these IP Link >>>>>>> abstractions. >>>>>>> >>>>>>> -- >>>>>>> Jonathan Hui >>>>>>> >>>>>>> On May 22, 2008, at 12:47 AM, Pascal Thubert (pthubert) wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Hi: >>>>>>>> >>>>>>>> My understanding is that defining how mesh-under computes its >>>>>>>> routes >>>>>>>> is >>>>>>>> out of scope for the IETF overall. I'm not even sure we need to >>>>>>>> document >>>>>>>> requirements in that space. It's good that we push some >>>>>>>> requirements >>>>>>>> to >>>>>>>> ROLL on route-over, and that's certainly the right time to do > so. >>>>>>>> >>>>>>>> To Jonathan: I do not completely agree that ISA100 is mesh >>>>>>>> under. The >>>>>>>> routing is not specified and left to the system manager >>>>>>>> implementation. >>>>>>>> My personal hope is to promote a ROLL solution in ISA100.11a > next >>>>>>>> release. See >>>>>>>> http://tools.ietf.org/html/draft-ietf-roll-indus-routing-req . >>>>>>>> >>>>>>>> So the current release of ISA100.11a is at the same level as >>>>>>>> 6LoWPAN >>>>>>>> on >>>>>>>> the matter of routing. >>>>>>>> >>>>>>>> In a same fashion, ISA does not define the backbone operation, >>>>>>>> the >>>>>>>> fragment recovery mechanism or the Explicit Congestion >>>>>>>> Notification. >>>>>>>> For >>>>>>>> all those features, there's a hope at ISA that the IETF will >>>>>>>> come up >>>>>>>> with more generic solutions that they can apply. But time is >>>>>>>> running >>>>>>>> out. >>>>>>>> >>>>>>>> 6LoWPAN hasn't produced anything for the last 6 months. At this >>>>>>>> rate, >>>>>>>> ISA will have to define everything on its own and hopefully >>>>>>>> publish an >>>>>>>> informational to this group. >>>>>>>> >>>>>>>> At the moment, the first draft of ISA100.11a is in letter >>>>>>>> ballot. The >>>>>>>> current draft mostly applies 6loWPAN formats over ISA100.11a > DLL, >>>>>>>> which >>>>>>>> is an evolution from 802.15.4. But the formats are not exactly >>>>>>>> 6LoWPAN >>>>>>>> so ISA is using NaLP headers starting with b'00'. >>>>>>>> >>>>>>>> What ISA needs from 6LoWPAN in very short term is in that >>>>>>>> order: >>>>>>>> - promote Jonathan's draft as a convergence specification so >>>>>>>> ISA can >>>>>>>> at >>>>>>>> least use standard HC headers. >>>>>>>> This enables: non-Link-Local-Address compression >>>>>>>> Hops limit compression >>>>>>>> UDP checksum compression >>>>>>>> Better placement of HC2 >>>>>>>> Which are all mandatory for ISA100.11a >>>>>>>> - better define the NaLPs. >>>>>>>> There should be a way to indicate to a 6LoWPAN node whether a >>>>>>>> NaLP >>>>>>>> can >>>>>>>> be skipped and what its length is. >>>>>>>> - define IP ECN bits in a 6LoWPAN header for use by >>>>>>>> intermediate nodes >>>>>>>> to report congestion. >>>>>>>> - specify a fragment flow control and recovery protocol at the >>>>>>>> 6LoWPAN >>>>>>>> Shim layer >>>>>>>> There is no rocket science in any of this and it all could/ >>>>>>>> should be >>>>>>>> carried out swiftly. >>>>>>>> >>>>>>>> What ISA needs in longer term: >>>>>>>> - define backbone operation when the backbone federates >>>>>>>> multiple >>>>>>>> LoWPANs >>>>>>>> into a single link (or subnet, TBD). >>>>>>>> This is more theoretical work for us. Related to proxy ND, a >>>>>>>> new >>>>>>>> registration protocols, multilink subnet, etc... >>>>>>>> >>>>>>>> Pascal >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: [EMAIL PROTECTED] [mailto:6lowpan- >>>>>>>>> [EMAIL PROTECTED] On >>>>>>>>> >>>>>>>>> >>>>>>>> Behalf Of Jonathan Hui >>>>>>>> >>>>>>>> >>>>>>>>> Sent: jeudi 22 mai 2008 00:20 >>>>>>>>> To: Mark Townsley (townsley) >>>>>>>>> Cc: 6lowpan@ietf.org >>>>>>>>> Subject: Re: [6lowpan] New charter for 6lowpan >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi Mark: >>>>>>>>> >>>>>>>>> On May 20, 2008, at 8:24 AM, Mark Townsley wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>>> - To your point on ND, this is precisely why the >>>>>>>>>>> architecture draft >>>>>>>>>>> is so important. We haven't given it as much attention >>>>>>>>>>> lately, but >>>>>>>>>>> it will help resolve the question your raise and many other >>>>>>>>>>> questions in the future. For example, the architecture draft >>>>>>>>>>> identifies two modes of operation: mesh-under and route- >>>>>>>>>>> over. Both >>>>>>>>>>> of which may require different ND mechanisms. This doesn't >>>>>>>>>>> apply to >>>>>>>>>>> just ND, but may apply questions of fragmentation, header >>>>>>>>>>> compression, security, etc. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> I worry about the under/over debate. It seems that with all > the >>>>>>>>>> effort and enthusiasm in ROLL, we might be well-served at the >>>>>>>>>> moment >>>>>>>>>> by focusing on helping them be successful with route-over >>>>>>>>>> than >>>>>>>>>> spending too much of our time on route-under. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> I worry too, especially since it will pull the WG in different >>>>>>>>> directions. I'm with you on the preference for route-over, but >>>>>>>>> others >>>>>>>>> in this group feel strongly about mesh-under as well, > especially >>>>>>>>> since >>>>>>>>> ISA100.11a seems to have adopted a mesh-under approach. I've >>>>>>>>> personally been focused on developing route-over solutions > while >>>>>>>>> being >>>>>>>>> conscious of supporting mesh-under when possible (evident with >>>>>>>>> 6lowpan- >>>>>>>>> hc). However, things will start to diverge when we start to > talk >>>>>>>>> about >>>>>>>>> bootstrapping, ND, etc. So we should make a conscious decision >>>>>>>>> of >>>>>>>>> whether we're supporting one or both. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Jonathan Hui >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> - I hesitate a bit that we suggest possible solutions to ND >>>>>>>>>>> in the >>>>>>>>>>> charter ("reusing the 802.15.4 network structure (use the >>>>>>>>>>> coordinators)") especially since the definition of such link >>>>>>>>>>> mechanisms are still in motion within the IEEE. It seems >>>>>>>>>>> more >>>>>>>>>>> productive to me if we can develop mechanisms that are less >>>>>>>>>>> dependent on the specific structure of 802.15.4 mechanisms. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> I agree that we should develop mechanisms that could work >>>>>>>>>> generically whenever possible. >>>>>>>>>> >>>>>>>>>> - Mark >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Rest of the charter looks good to me. >>>>>>>>>>> >>>>>>>>>>> Thanks. >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Jonathan Hui >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On May 16, 2008, at 11:46 AM, Mark Townsley wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Pascal Thubert (pthubert) wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Hi Mark: >>>>>>>>>>>>> >>>>>>>>>>>>> I think we need a work item (usually implicit) around the >>>>>>>>>>>>> concept >>>>>>>>>>>>> of >>>>>>>>>>>>> improving existing WG RFCs. RFC 4944 can be improved in >>>>>>>>>>>>> several >>>>>>>>>>>>> aspects: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> - A major one is a better fit with ISA100.11a. Getting >>>>>>>>>>>>> ISA100.11a >>>>>>>>>>>>> to >>>>>>>>>>>>> conform to 6LoWPAN would be a major win, but is certainly >>>>>>>>>>>>> not a >>>>>>>>>>>>> given. >>>>>>>>>>>>> At the moment, the ISA100.11a documents expose >>>>>>>>>>>>> discrepencies with >>>>>>>>>>>>> RFC >>>>>>>>>>>>> 4944 that http://www.tools.ietf.org/html/draft- >>>>>>>>>>>>> hui-6lowpan- >>>>>>>>>>>>> hc >>>>>>>>>>>>> resolve >>>>>>>>>>>>> for the most part. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> Are the resolutions backwards compatible with RFC 4944? I'm >>>>>>>>>>>> eager >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> to >>>>>>>> >>>>>>>> >>>>>>>>>>>> improve RFC 4944, but not eager to endorse changes that >>>>>>>>>>>> inhibit >>>>>>>>>>>> interoperability. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> - The issue of fragmentation. Applying RFC 4944 over a >>>>>>>>>>>>> multihop >>>>>>>>>>>>> radio >>>>>>>>>>>>> mesh exposes the network to congestion collapse, as >>>>>>>>>>>>> described in >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>> > http://www.tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-rec >>>>>>>> >>>>>>>> >>>>>>>>>>>>> overy . I think that the WG should dedicate some >>>>>>>>>>>>> bandwitdth to >>>>>>>>>>>>> provide >>>>>>>>>>>>> additional functions that would improve the LoWPAN >>>>>>>>>>>>> operation WRT >>>>>>>>>>>>> flow >>>>>>>>>>>>> control and recovery of fragments. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> Fragmentation, OK, but why is flow control a network layer >>>>>>>>>>>> issue >>>>>>>>>>>> rather >>>>>>>>>>>> than a transport layer issue? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Another aspect of ISA100.11a is the concept of a backbone >>>>>>>>>>>>> router. >>>>>>>>>>>>> It >>>>>>>>>>>>> would be appropriate that the IETF comes up with a >>>>>>>>>>>>> proposal to >>>>>>>>>>>>> implement >>>>>>>>>>>>> the concept in the IPv6 world. This partially falls under >>>>>>>>>>>>> the >>>>>>>>>>>>> first work >>>>>>>>>>>>> item on ND but might also include ND proxy over the > backbone >>>>>>>>>>>>> which is a >>>>>>>>>>>>> stretch to the work item. More in >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>> > http://www.tools.ietf.org/html/draft-thubert-6lowpan-backbone-router >>>>>>>> >>>>>>>> >>>>>>>>>>>>> . >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> Well, don't we need to define what ND looks like on a >>>>>>>>>>>> lowpan >>>>>>>>>>>> before we >>>>>>>>>>>> decide whether it needs to be proxied or not? >>>>>>>>>>>> >>>>>>>>>>>> - Mark >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> What do you think? >>>>>>>>>>>>> >>>>>>>>>>>>> Pascal >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] >>>>>>>>>>>>>> ] >>>>>>>>>>>>>> On >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> Behalf Of Mark Townsley >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> (townsley) >>>>>>>>>>>>>> Sent: jeudi 15 mai 2008 23:02 >>>>>>>>>>>>>> To: 6lowpan@ietf.org >>>>>>>>>>>>>> Subject: [6lowpan] New charter for 6lowpan >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'd like to ask the group one final time for comments on >>>>>>>>>>>>>> the >>>>>>>>>>>>>> proposed >>>>>>>>>>>>>> new charter. I've also asked the ROLL WG chairs to > comment. >>>>>>>>>>>>>> >>>>>>>>>>>>>> As I said before, soon after the format document was >>>>>>>>>>>>>> published, >>>>>>>>>>>>>> there >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> is >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> nothing stopping the WG from discussing and working on >>>>>>>>>>>>>> new and >>>>>>>>>>>>>> existing >>>>>>>>>>>>>> items at this time. In fact, activity helps us to decide >>>>>>>>>>>>>> what >>>>>>>>>>>>>> should be >>>>>>>>>>>>>> in and out of the charter. Please do not construe not >>>>>>>>>>>>>> having a >>>>>>>>>>>>>> charter >>>>>>>>>>>>>> in place as a reason not to update drafts, or discuss >>>>>>>>>>>>>> topics >>>>>>>>>>>>>> that need >>>>>>>>>>>>>> to be discussed. Just as when we have BoF's and mailing >>>>>>>>>>>>>> lists >>>>>>>>>>>>>> before >>>>>>>>>>>>>> creating a new WG, it is good to have WG meetings and on- >>>>>>>>>>>>>> lists >>>>>>>>>>>>>> discussions when creating new WG charters. >>>>>>>>>>>>>> >>>>>>>>>>>>>> - Mark >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> 6lowpan mailing list >>>>>>>>>>>> 6lowpan@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 6lowpan mailing list >>>>>>>>> 6lowpan@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>>>>>>> >>>>>>>>> >>>>>>> _______________________________________________ >>>>>>> 6lowpan mailing list >>>>>>> 6lowpan@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> 6lowpan mailing list >>>>>> 6lowpan@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>>>> >>>>>> >>>>>> >>>> >>>> >>>> >>> >>> _______________________________________________ >>> Roll mailing list >>> [EMAIL PROTECTED] >>> https://www.ietf.org/mailman/listinfo/roll >> >> DTN work: http://info.surrey.ac.uk/Personal/L.Wood/saratoga/ >> >> <http://info.surrey.ac.uk/Personal/L.Wood/><[EMAIL PROTECTED]> >> >> >> >> >> _______________________________________________ >> Roll mailing list >> [EMAIL PROTECTED] >> https://www.ietf.org/mailman/listinfo/roll DTN work: http://info.surrey.ac.uk/Personal/L.Wood/saratoga/ <http://info.surrey.ac.uk/Personal/L.Wood/><[EMAIL PROTECTED]> _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan
