Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in ARO]

Behcet Sarikaya <behcetsarikaya@yahoo.com> Tue, 26 April 2011 17:01 UTC

Return-Path: <behcetsarikaya@yahoo.com>
X-Original-To: 6lowpan@ietfa.amsl.com
Delivered-To: 6lowpan@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2AF6E076E for <6lowpan@ietfa.amsl.com>; Tue, 26 Apr 2011 10:01:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.689
X-Spam-Level:
X-Spam-Status: No, score=-1.689 tagged_above=-999 required=5 tests=[AWL=0.910, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dv6tk4NVZGs2 for <6lowpan@ietfa.amsl.com>; Tue, 26 Apr 2011 10:01:11 -0700 (PDT)
Received: from nm26-vm1.bullet.mail.sp2.yahoo.com (nm26-vm1.bullet.mail.sp2.yahoo.com [98.139.91.231]) by ietfa.amsl.com (Postfix) with SMTP id 5E332E07BB for <6lowpan@ietf.org>; Tue, 26 Apr 2011 10:01:06 -0700 (PDT)
Received: from [98.139.91.67] by nm26.bullet.mail.sp2.yahoo.com with NNFMP; 26 Apr 2011 17:01:03 -0000
Received: from [98.139.91.27] by tm7.bullet.mail.sp2.yahoo.com with NNFMP; 26 Apr 2011 17:01:03 -0000
Received: from [127.0.0.1] by omp1027.mail.sp2.yahoo.com with NNFMP; 26 Apr 2011 17:01:03 -0000
X-Yahoo-Newman-Property: ymail-5
X-Yahoo-Newman-Id: 594967.77437.bm@omp1027.mail.sp2.yahoo.com
Received: (qmail 11117 invoked by uid 60001); 26 Apr 2011 17:01:03 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1303837263; bh=uNENozqii04nE6fk5ce0WYfvVW/lUbkj3fr3F++1LX0=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=J3L1nXDgaimqDGtu1YebjuGDyAJOhnK5d/r7YAd7UoqcnaVJfKZJ0FB4IdwrLy/Wn8BYo59hmtimE9pWVAdnFsvYaUVWgAN7D+yQKlkV3xSag0ZK/f5mCuhciW14bidmzQ8ZSnThxg8V8a0N2Uk8gbfkIxeyNdSlCiHdSf0M5UI=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=5/9rpqRaMGfIvam9/oY8Krg7HQqt/75rpxy93sM+ppScFdiUpO65u6IWaKUosTGtMlHPFtneifxN6HdV4De9XFOl7CwZBplKIVjxOKUo5XCn+RqI8yNbT6KJFYVUIERz3HLVxPvNNnEdoJUecWvihy4W9cN0Zji1/Pn6hmqV660=;
Message-ID: <205310.2728.qm@web111414.mail.gq1.yahoo.com>
X-YMail-OSG: eu0gA1cVM1kd5cGOYQGdGjTY9zgHtLGyCrWW31_WahnIteV fDD2yfOgbgEBosl..5_bErGvzRQFtsTzoMVTeDZwPNinx.oA6hp7wmXjIZBX qsIEgyLJy.SHB_Eg0bUeOSwg234oLlt381FCjfdFBI9q3NiU2VJhIbqLrGcr ll5tEZMao.kfT4MgymZ8m9ZOYh_yj9GcTo4PjyjPLKAIqHW0DOssVrpd1oWw ay.rtJiRjlShPZh2wp7lRYBT9lZ2Dh2DDjbQuSNFKjAnCY2fL6Fn1Qvqa.Ea XmqYHVJMzKezQ9sKffXJMkpxaHE5jcMD2qyvwRZRm7IvXhTYbb8GAKOmA2Kj J3ReUXYZK6AgLNqtxNHyI_w_A5MxLuaat7SQnNRbL0f1PuvcoXFWywg.3yID s8ldicAHoPnAq_w--
Received: from [206.16.17.212] by web111414.mail.gq1.yahoo.com via HTTP; Tue, 26 Apr 2011 10:01:03 PDT
X-Mailer: YahooMailRC/559 YahooMailWebService/0.8.110.299900
References: <OF05FC8EC8.E2C545F7-ONC1257878.002DC800-C1257878.002DE486@Schneider-Electric.com> <4DAF6B38.7000604@acm.org> <6A2A459175DABE4BB11DE2026AA50A5D046502D9@XMB-AMS-107.cisco.com> <1303400445.1671.1576.camel@d430> <6A2A459175DABE4BB11DE2026AA50A5D0470FA00@XMB-AMS-107.cisco.com> <1303414920.1671.1849.camel@d430>
Date: Tue, 26 Apr 2011 10:01:03 -0700
From: Behcet Sarikaya <behcetsarikaya@yahoo.com>
To: Geoff Mulligan <geoff@proto6.com>
In-Reply-To: <1303414920.1671.1849.camel@d430>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: 6lowpan@ietf.org
Subject: Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in ARO]
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Behcet Sarikaya <sarikaya@ieee.org>
List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6lowpan>
List-Post: <mailto:6lowpan@ietf.org>
List-Help: <mailto:6lowpan-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Apr 2011 17:01:13 -0000

I also think that we must move on.

We must move on and start looking into securing 6lowpan ND?

Regards,

Behcet




> Pascal,
>   I couple of people supporting the TID is not group  consensus.  We have
> had many presentations and discussions about  multiple LBRs, backbone
> LBRs and more and none have met with the support of  the working group.
> 
> In your opinions we are crashing, but I fail to see  that this is the
> opinion of the working group.
> 
> If there are other in  the working group that strongly advocate this TID
> idea or the work on  multiple and backbone LBRs then they need to speak
> up now en masse or we must  move on.
> 
>     geoff
> 
> 
> On Thu, 2011-04-21 at 21:32  +0200, Pascal Thubert (pthubert) wrote:
> > Geoff:
> > 
> > There is  twice as much support for restoring the TID than there is for  not 
>doing  it.
> > Before we drop the TID, I'd like to see a proposal that allows a  6LoWPAN ND 
>subnet to scale with multiple LBRs, allows nodes to move from a  router to the 
>next, and that does not need a TID.
> > Otherwise, we are not  speeding towards the wall, we're already crashing.
> > 
> >  Pascal
> > http://www.xtranormal.com/watch/7011357/
> > 
> > >  -----Original Message-----
> > > From: Geoff Mulligan [mailto:geoff.ietf@mulligan.com]
> > >  Sent: Thursday, April 21, 2011 5:41 PM
> > > To: Pascal Thubert  (pthubert)
> > > Cc: Erik Nordmark; nicolas.riou@schneider-electric.com; 6lowpan@ietf.org
> > > Subject: Re:  [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in
> > >  ARO]
> > > 
> > > Pascal,
> > >   We need to close on  this discussion.
> > > 
> > > Back in Hiroshima the Working Group  decided that Backbone router stuff 
and
> > > "address defense" across  backbone routers was not going to be part of ND
> > > draft.  It  appeared that the draft was getting way to complicated and the
> > >  Working Group decided to simplify things.
> > > 
> > > I have not  seen much support on the list for making these changes to 
>include
> > >  the TID in ND.
> > > 
> > > We need to get this draft  completed.  If there is a large "unheard from"
> > > support group  for these changes, please speak up or we shall move forward
> > > with  the draft as it is.
> > > 
> > >     geoff
> >  > 
> > > 
> > > 
> > > 
> > > On Thu, 2011-04-21  at 09:27 +0200, Pascal Thubert (pthubert) wrote:
> > > > Hi  Erik
> > > >
> > > > The TID is not a strong coupling  between the H2R and the R2R 
operations,
> > > and it is not a coupling  with a RPL version  explicitly.
> > > > It is an abstract  information that if defined properly can be used by 
>many
> > > forms or  R2R interactions.
> > > > As demonstrated by older versions of the ND  spec (Backbone Router), 
RPL,
> > > and MIP.
> > > >
> >  > > 6LoWPAN ND cannot scale if the node needs to register to all  LBRs.
> > > 6LoWPAN ND does not define anymore any LBR  interaction.
> > > > IOW, 6LoPWAN ND lost the capability to scale when  the backbone router
> > > piece was removed from the draft.
> > >  > Which means that it lost its capability to apply in the domains I'm 
>looking  at
> > > (industrial and metering).
> > > >
> > > >  With the TID, we know that we can restore scalability in the future, and  
>we
> > > know how. I do not know of a plan B.
> > > >
> >  > > Pascal
> > > > http://www.xtranormal.com/watch/7011357/
> > > >
> > >  >
> > > > > -----Original Message-----
> > > > >  From: Erik Nordmark [mailto:nordmark@acm.org]
> > > > >  Sent: Thursday, April 21, 2011 1:25 AM
> > > > > To: nicolas.riou@schneider-electric.com
> >  > > > Cc: Pascal Thubert (pthubert); 6lowpan@ietf.org; Dijk, Esko
> > >  > > Subject: Re: [6lowpan] FW: TID in ARO [was: "Advertize on  Behalf"
> > > > > flag in ARO]
> > > > >
> > >  > > On 4/20/11 1:21 AM, nicolas.riou@schneider-electric.com wrote:
> > > > > >
> > > > > > Dear Pascal and  al,
> > > > > >
> > > > > > I support the idea  of reviving the TID in ARO and DAR/DAC.
> > > > > > Supporting a  TID directly in the node initiating the initial NS
> > > > > >  appears much simpler than time stamping in the parent router.
> > > >  >
> > > > > How would you make this work if the protocol between  the routers is
> > > > > not RPLv1, but some future version of RPL  or a completely different
> > > > > routing protocol?
> > >  > >
> > > > > The decoupling of the host-router interaction  from router-router
> > > > > interaction has served us well in the  history of the Internet.
> > > > >
> > > > >        Erik
> > > > >
> > > > > > A simple  and efficient method to detect mobility of hosts along a
> > > > >  > backbone of Edge Routers is an important feature to deploy
> > >  > > > backbones of Edge Routers in Buildings and should be  clarified
> > > > > > before closing 6LoWPAN WG.
> > >  > > >
> > > > > > Cheers,
> > > > > >  Nicolas
> > > > > >
> > > > > >
> > >  > > >
> > > > > >
> > > > > >
> >  > > > >
> > > > > > *"Pascal Thubert (pthubert)"  <pthubert@cisco.com>* Envoyé par  :
> > > > > > 6lowpan-bounces@ietf.org
> > >  > > >
> > > > > > 18/04/2011 10:37
> > > >  > >
> > > > > >
> > > > > > A
> > >  > > >     "Dijk, Esko" <esko.dijk@philips.com>, "Erik  Nordmark"
> > > > > > <nordmark@acm.org> cc
> > > >  > >     6lowpan@ietf.org
> > > > > >  Objet
> > > > > >     Re: [6lowpan] FW: TID in  ARO [was: "Advertize on Behalf" flag 
in
> > > > > ARO]
> > >  > > >
> > > > > >
> > > > > >
> >  > > > >
> > > > > >
> > > > >  >
> > > > > >
> > > > > >
> > > >  > > Hi Esko, Erik
> > > > > >
> > > > > >  The discussion on RPL and hosts should happen on the RPL list
> > > >  > > under a different topic. The point being discussed here is  this:
> > > > > >
> > > > > > The reality is  also that those (LLN) networks will need to scale
> > > > > > to  large subnets in plants, building, etc... (see the requirement
> > > >  > > drafts in ROLL). Registering to all LBRS is totally  impractical.
> > > > > > 6LoWPAN ND requires a coordination  between LBRs but does not say
> > > how it happens.
> > > >  > > This problem was discussed in 6LoWPAN; the answer was in
> > >  > > > ND-01to07; and it requires a TID, for the same reason as  RPL.
> > > > > > Removing the backbone operation and the TID  from the draft is 
>ostrich
> > > policy.
> > > > >  >
> > > > > > BTW 6LoWPAN ND needs a TID to correlate the NS  and the NA as all
> > > > > > other registrations do when strict  ordering is not guaranteed (MIP
> > > > > > being an example).  Say that due to some config, a node registers a
> > > > > >  lifetime of X, then deregisters (lifetime 0), then reregisters
> > > >  > > (lifetime X) in a rapid sequence, but does not get an answer  yet.
> > > > > > Then it finally gets 2 AROs back, lifetime X  and 0. What's the final 
>state
> > > in the router?
> > > > >  >
> > > > > > I'd like to hear what others think.
> >  > > > >
> > > > > > Pascal
> > > > >  > http://www.xtranormal.com/watch/7011357/
> > > > >  >
> > > > > >
> > > > > >  >  -----Original Message-----
> > > > > >  > From: Dijk,  Esko [mailto:esko.dijk@philips.com]  >  Sent:
> > > > > > Monday, April 18, 2011 10:19 AM  > To:  Erik Nordmark; Pascal
> > > > > > Thubert
> > > > >  > (pthubert)  > Cc: 6lowpan@ietf.org  > Subject: RE:  [6lowpan] FW:
> > > > > > TID in ARO [was: "Advertize on Behalf"  flag in  > ARO]  >  > Hello
> > > > > >  Erik,
> > > > > > >  > taking the definition you  quoted:
> > > > > >  > 'host' refers to an LLN device  that can generate but does not
> > > > > > forward  >  RPL traffic  >  > the question may arise what is "RPL
> >  > > > > traffic"? It is not defined in the RPL draft  > it  seems. Pascal
> > > > > > clarified to me it is traffic  associated to a RPL instance, not  >
> > > > > >  necessarily RPL protocol messages. This means that a host could
> > >  > > > generate  > RPL traffic without being aware of the  existence of
> > > > > > RPL at all. So, _not_ all  >  hosts have to speak RPL?
> > > > > >  > The RPL draft  does not explicitly state if "hosts" in a RPL
> > > > > >  network always  > speak RPL, never speak RPL, or can be mixed
> >  > > > > RPL/non-RPL speakers.
> > > > > >   >
> > > > > >  > Taking the definition of 'node' in  the RPL draft:
> > > > > >  > 'node' refers to any RPL  device, either a host or a router  >
> > > > > > >  rules out (?) the option that all "hosts" are non-RPL speakers,
> > >  > > > since there  > may be a "RPL device" (i.e. RPL-speaking  device, I
> > > > > > assume) that is also a host.
> > >  > > >  >
> > > > > >  > I communicated  these perceived unclarities to Pascal and the
> > > > > > RFC  editor 2  > weeks ago. Once this is clear I think the present
> >  > > > > discussion can continue.
> > > > > >   > And then there is the related discussion of ND support for
> > >  > > > sleepy devices,  > the original topic of Anders ;)   >  > best
> > > > > > regards,  >  >  Esko  >  >  >  > -----Original  Message-----  > 
From:
> > > > > > 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On   >
> > > > > > Behalf Of Erik Nordmark  > Sent: Friday  15 April 2011 18:39  > To:
> > > > > > Pascal Thubert  (pthubert)  > Cc: 6lowpan@ietf.org  > Subject:  Re:
> > > > > > [6lowpan] FW: TID in ARO [was: "Advertize on  Behalf" flag in  >
> > > > > > ARO]
> > > >  > > >  > On 4/14/11 11:43 PM, Pascal Thubert (pthubert)  wrote:
> > > > > >  >
> > > > > >   > > RPL can do what all classical IGPs can do WRT hosts. That is
> >  > > > > as long  > > as the host address belongs to the  router's prefix
> > > > > > and stays attached  > >  to that router.
> > > > > >  >
> > > > >  >  > I just realized that we might be talking about a  different
> > > > > > definition of "host".
> > > >  > >  > What I mean by "host" is a node which does not participate  in a
> > > > > > routing  > protocol, and does not  forward packets (except packets
> > > > > > explicitly  addressed  > to itself using e.g., a routing header).
> > > >  > >  >
> > > > > >  > However, RPL has a  different definition:
> > > > > >  > 'host' refers to an  LLN device that can generate but does not
> > > > > >  forward  > RPL traffic  >  > Basically per the RPL  definition
> > > > > > there is no such thing as a node which  does  > not participate in
> > > > > > the RPL  protocol.
> > > > > >  > IMHO what is in RPL should have  been defined as a
> > > > > > non-forwarding node, so  >  that we can have a sane discussion
> > > > > > without getting  entangled in terminology  > issues.
> > > > > >   >
> > > > > >  > Which definition of "host" are you  using above?
> > > > > >  >
> > > > >  >  > Per the RPL definition there is no need for 6lowpan-nd,  since
> > > > > > all nodes will  > speak RPL. This is  rather confusing, don't you 
>think?
> > > > > >   >
> > > > > >  > Erik
> > > > >  >  >
> > > > > >  > > When the topology  becomes multilink subnet and mobility is
> > > > > >  required  > > then it is a new problem entirely, and NO, 4861  is
> > > > > > not a suitable  > > interaction with  the router to allow the
> > > > > > router to redistribute a  host route.
> > > > > >  > > Because the neighbor  cache that 4861 builds is not a of the
> > > > > > same
> >  > > > > > > nature as the binding table that 6LoWPAN ND  builds. Another
> > > > > > > > thing
> > > >  > > that  > > 6LoWPAN ND fails to express correctly. I proposed  text
> > > > > > to explain that  > > (attached) but  it was not considered,
> > > > > > contributing to the  illusion  > > that a cache is a table.
> > > > >  >  > >
> > > > > >  > > The reality is  also that those networks will need to scale to
> > > > > >  large  > > subnets in plants, building, etc... (see the
> > >  > > > requirement drafts in  > > ROLL). Registering to all  LBRS is 
>totally
> > > impractical.
> > > > > > 6LoWPAN  ND  > > requires a coordination between LBRs but does not
> >  > > > > say how it happens.
> > > > > >  >  > This problem was discussed in 6LoWPAN; the answer was in
> > > >  > > ND-01to07;  > > and it requires a TID, for the same reason  as RPL.
> > > > > > Removing the  > > backbone  operation and the TID from the draft is
> > > > > >  ostrich
> > > > > policy.
> > > > > >  >  >
> > > > > >  > > RPL already adapted to the new  reality of large multilink
> > > > > > subnet with  >  > inner mobility. Placing the blame on RPL is
> > > > > >  another illusionist trick.
> > > > > >  > > And this  is not RPL last call.
> > > > > >  > >
> > >  > > >  > > BTW 6LoWPAN ND needs a TID to correlate the NS  and the NA as
> > > > > > all other  > >  registrations do when strict ordering is not
> > > > > >  guaranteed (MIP being an  > > example). Say that due to some
> >  > > > > config, a node registers a lifetime of  > > X,  then deregisters
> > > > > > (lifetime 0), then reregisters  (lifetime X) in a  > > rapid
> > > > > > sequence,  but does not get an answer yet. Then it finally gets
> > > > > >  2
> > > > > >  > > AROs back, lifetime X and 0.  What's the final state in the 
>router?
> > > > > >  >  >
> > > > > >  > > It seems we can never agree on  any of this. I'd like to hear
> > > > > > what
> > > >  > > > > others think.
> > > > > >  >  >
> > > > > >  > > Pascal
> > > > >  >  > > http://www.xtranormal.com/watch/7011357/
> > > >  > >  > >
> > > > > >  > >
> >  > > > >  > >> -----Original Message-----
> > >  > > >  > >> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-
> > > > > bounces@ietf.org]
> > > > > >  On  > >> Behalf Of Erik Nordmark  > >> Sent: Friday,  April 15,
> > > > > > 2011
> > > > > > 1:30  AM  > >> To: 6lo>> '6lowpan'
> > > > >  >  > >> Subject: Re: [6lowpan] Fwd: Re: "Advertize on Behalf"  flag
> > > > > > in ARO  > >>  >  >>  > >> On 4/13/11 12:53 AM, Pascal Thubert
> > >  > > > (pthubert)
> > > > > > wrote:
> > > >  > >  > >>> Hi Erik:
> > > > > >   > >>>
> > > > > >  > >>> The RPL  (DAO) sequence number allows the node to increment
> > > > > >  rapidly  > >>> in case of rapid changes and then lazily when  the
> > > > > > situation is  > >>> stable and  DAO are scarce. The increase is
> > > > > > strictly monotonous  which  > >  > >>> is critical to us.
> > >  > > >  > >>>
> > > > > >  >  >>> A time stamp imposes a synchronization between the routers.
> >  > > > > We do  > >>> not have such mechanism in  RPL. A time unit (a
> > > > > > granularity) must be  >  >>> agreed upon. Within that unit,
> > > > > >  movements go undetected so the time  > >>> unit must be thin  
>grained
> > > to cover rapid changes.
> > > > > > Yet,  depending on  > >>> the medium, the time unit, and the  size
> > > > > > of the network, it is not  >  >>> necessarily easy/possible to
> > > > > > guarantee  a strictly monotonous value  > >>> with a thin grained
> >  > > > > time unit. And we have limited space (2
> > > >  > > octets)
> > > > > >  > >>> and have  to deal with wrap around, which divides the space
> > > > > > by  at  > > least 3.
> > > > > >  >  >>>
> > > > > >  > >>> So RPL went for  a sequence number.
> > > > > >  > >>
> > >  > > >  > >> But the unstated assumption that RPL made is  that all
> > > > > > host-to-router  > >>  protocols have to now be RPL aware. That
> > > > > > doesn't  sound like good  > > design.
> > > > > >  >  >> A host isn't aware of whether the routers speak IS-IS or
> > >  > > > OSPF, so why  > >> do the hosts need to be aware of  RPL by passing
> > > > > > some TID around?
> > > >  > >  > >>
> > > > > >  >  >>> I think ND has the same need as MIP for a TID == Sequence #  
>.
> > > > > > We  > >>> know of MIP; We know of  RPL. We know of the backbone
> > > > > > router
> > >  > > > > >>> operation. We know we'll need the TID and we  know exactly
> > > > > > > >>> why. I think we  should have it in the 6LowPAN ND spec right
> > > > > > >  >>> away to
> > > > > > avoid  > >>>  interop issues when we add RPL and BR operations.
> > > > >  >  > >>
> > > > > >  > >> I don't  see a need in 6lowpan-nd for a TID; the protocol
> > > > > >  works fine  > > without it.
> > > > > >  >  >> I think RPL needs to be improved to deal with reality. Isn't
> >  > > > > there a  > >> desire for RPL to handle 4861  hosts? Those would
> > > > > > never know about a  >  > TID.
> > > > > >  > >>
> > > > >  >  > >> Erik
> > > > > >  >  >>
> > > > > >  > >>  _______________________________________________
> > > > >  >  > >> 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
> > >  > > >  >
> > > > > >  > The information  contained in this message may be confidential
> > > > > > and  legally  > protected under applicable law. The message is
> > >  > > > intended solely for the  > addressee(s). If you are not  the
> > > > > > intended recipient, you are hereby  notified  > that any use,
> > > > > > forwarding,  dissemination, or reproduction of this message is  >
> > > >  > > strictly prohibited and may be unlawful. If you are not the
> >  > > > > intended recipient,  > please contact the sender by  return e-mail
> > > > > > and destroy all copies of the   > original message.
> > > > > >
> > > > > >  _______________________________________________
> > > > > >  6lowpan mailing list
> > > > > > 6lowpan@ietf.org
> > > > > > https://www.ietf.org/mailman/listinfo/6lowpan
> > > > >  >
> > > > > >
> > > > >
> > >  __________________________________________________________
> > > >  > ____________
> > > > > > This email has been scanned by the  MessageLabs Email Security
> > > System.
> > > > >  >
> > > > >
> > >  __________________________________________________________
> > > >  > ____________
> > > > > >
> > > >
> > >  > _______________________________________________
> > > > 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
>