Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F72C1B2AAF; Mon, 8 Feb 2016 05:20:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.928 X-Spam-Level: X-Spam-Status: No, score=-5.928 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tC_bzOstvbR0; Mon, 8 Feb 2016 05:20:11 -0800 (PST) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7AA91B2AA4; Mon, 8 Feb 2016 05:20:10 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.22,416,1449529200"; d="scan'208,217";a="202063322" Received: from mail-wm0-f44.google.com ([74.125.82.44]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 08 Feb 2016 14:20:09 +0100 Received: by mail-wm0-f44.google.com with SMTP id 128so154693156wmz.1; Mon, 08 Feb 2016 05:20:09 -0800 (PST) X-Gm-Message-State: AG10YOTQjdq2ZzxFh4qh2tZIPIqP2eytluIEleSjZ+6EQ9rlpyItMQw8RTnj1U437enXGxLAYZbUYTvBDbyr0A== X-Received: by 10.28.224.84 with SMTP id x81mr49357481wmg.62.1454937609011; Mon, 08 Feb 2016 05:20:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.103.14 with HTTP; Mon, 8 Feb 2016 05:19:49 -0800 (PST) In-Reply-To: References: <7c82388e5ccd437fad8dab52e5e1541d@XCH-RCD-001.cisco.com> From: Thomas Watteyne Date: Mon, 8 Feb 2016 14:19:49 +0100 X-Gmail-Original-Message-ID: Message-ID: To: "Pascal Thubert (pthubert)" Content-Type: multipart/alternative; boundary=001a114c18465b1216052b420fb6 Archived-At: Cc: Simon Duquennoy , "6tisch@ietf.org" <6tisch@ietf.org>, Tengfei Chang , "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [6tisch] [6lo] Format inside of an RPL domain X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 13:20:16 -0000 --001a114c18465b1216052b420fb6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable [resending from the right e-mail address] On Mon, Feb 8, 2016 at 2:16 PM, Thomas Watteyne wrote= : > Pascal, > > I hope my comments don't come too late. Please find below some edits of > your suggested text. > > My biggest comment is about naming, as I think we are using "nicknames" > for things, which makes things very hard to follow. > > Thomas > > ## DODAG Root Address {#impl-comp-ref} > > > > With this specification, an optimal compression > > TW> I would drop the word "optimal", which implies you can prove it. > Replace by "efficient"? > > of IP-in-IP encapsulation can be > > achieved if an endpoint of the packet is the root of the RPL DODAG > associated to > > the Instance > > TW> please make sure that you use the capital "I" on purpose > > that is used to forward the packet, and the root address is known > > implicitly as opposed to signaled explicitly in the data packets. > > > > With RPL {{RFC6550}}, the address of > > TW> add "the" > > DODAG root is known from the DODAGID field > > of the DIO messages. For a Global Instance, the RPLInstanceID that is > present in > > the RPI > > TW> where does the term RPI come from? According to RFC6553, the full nam= e > is "RPL Option", no? > > is enough information to identify the DODAG that this node participates > > to and its associated root. But for a Local Instance, the address of the > root > > MUST be explicit, either in some device configuration or signaled in the > packet, > > as the source or the destination address, respectively. > > > > When implicit, the address of the DODAG root MUST be determined as follow= s: > > > > If the whole network is a single DODAG then the root can be well-known an= d > does > > not need to be signaled in the packets. But > > TW> "if" missing? > > RPL does not expose that property > > and it can only be known by a configuration applied to all nodes. > > > > Else, the router that encapsulates the packet and compresses it with this > > specification MUST also place an RPI in the packet as prescribed by > {{RFC6550}} > > to enable the identification of the DODAG. The RPI must be present even i= n > the > > case when the router also places an RH3 header in the packet. > > > > It is expected that the RPL implementation provides an abstract context > table, > > indexed by Global RPLInstanceID, that provides the address of the root of > the > > DODAG that this nodes participates to for that particular Instance. > > > > > > ## Compression Reference {#sig-comp-ref} > > > > In order to optimize the compression of IP addresses present in the RH3 > headers, > > this specification requires that the 6LoWPAN layer identifies an address > that is > > used as reference for the compression. With this specification, the > Compression > > Reference for addresses found in an RH3 header is the source of the IPv6 > packet. > > > > With RPL {{RFC6550}}, an RH3 > > > In the same vain as my comment about RPI, we should really force > ourselves to use the same terminology, or else it gets really really > confusing. > > > I understand that RH3 stands for > the-Routing-header-with-IPv6-routing-type-3, but according to RFC6554, th= is > is called "RPL Source Route Header". Let's please use that name... > > > header may only be present in Non-Storing mode, and > > it may only be placed in the packet by the root of the DODAG, which must > be the > > source of the resulting IPv6 packet {{RFC2460}}. In this case, the addres= s > used > > as Compression Reference is that the address of the root, and it can be > implicit > > when the address of the root is. > > > > The Compression Reference MUST be determined as follows: > > > > The reference address may be obtained by configuration. The configuration > may > > indicate either the address in full, or the identifier of a 6LoWPAN > Context that > > carries the address {{RFC6775}}, for instance one of the 16 Context > Identifiers > > used in LOWPAN-IPHC {{RFC6282}}. > > > > Else, and if there is no IP-in-IP encapsulation, the source address in th= e > IPv6 > > header that is compressed with LOWPAN-IPHC is the reference for the > compression. > > > > Else, and if the IP-in-IP compression specified in this document is used > and the > > Encapsulator Address is provided, then the Encapsulator Address is the > reference. > > > > (note that this means that the specification does not expect > IP-in-IP-in-IP and > > does not enforce any order in 6LoRH ... should it???). > > On Wed, Jan 20, 2016 at 4:14 PM, Pascal Thubert (pthubert) < > pthubert@cisco.com> wrote: > >> Hello Tengfei and Simon (and all): >> >> >> >> I=E2=80=99ll need some more help from you. >> >> >> >> I=E2=80=99m in the process of refining the text that indicates how the r= oot >> address is obtained and how to compute the Compression Reference for the >> RH3. >> >> >> >> I came up with the following, which indicates that the source of the >> packet (which should always be the root for now but who knows) is the >> reference for RH3 compression. >> >> >> >> Is that what we want? Is it clear enough? >> >> >> >> >> >> ## DODAG Root Address {#impl-comp-ref} >> >> >> >> With this specification, an optimal compression of IP-in-IP encapsulatio= n >> can be >> >> achieved if an endpoint of the packet is the root of the RPL DODAG >> associated to >> >> the Instance that is used to forward the packet, and the root address is >> known >> >> implicitly as opposed to signaled explicitly in the data packets. >> >> >> >> With RPL {{RFC6550}}, the address of DODAG root is known from the DODAGI= D >> field >> >> of the DIO messages. For a Global Instance, the RPLInstanceID that is >> present in >> >> the RPI is enough information to identify the DODAG that this node >> participates >> >> to and its associated root. But for a Local Instance, the address of the >> root >> >> MUST be explicit, either in some device configuration or signaled in the >> packet, >> >> as the source or the destination address, respectively. >> >> >> >> When implicit, the address of the DODAG root MUST be determined as >> follows: >> >> >> >> If the whole network is a single DODAG then the root can be well-known >> and does >> >> not need to be signaled in the packets. But RPL does not expose that >> property >> >> and it can only be known by a configuration applied to all nodes. >> >> >> >> Else, the router that encapsulates the packet and compresses it with thi= s >> >> specification MUST also place an RPI in the packet as prescribed by >> {{RFC6550}} >> >> to enable the identification of the DODAG. The RPI must be present even >> in the >> >> case when the router also places an RH3 header in the packet. >> >> >> >> It is expected that the RPL implementation provides an abstract context >> table, >> >> indexed by Global RPLInstanceID, that provides the address of the root o= f >> the >> >> DODAG that this nodes participates to for that particular Instance. >> >> >> >> >> >> ## Compression Reference {#sig-comp-ref} >> >> >> >> In order to optimize the compression of IP addresses present in the RH3 >> headers, >> >> this specification requires that the 6LoWPAN layer identifies an address >> that is >> >> used as reference for the compression. With this specification, the >> Compression >> >> Reference for addresses found in an RH3 header is the source of the IPv6 >> packet. >> >> >> >> With RPL {{RFC6550}}, an RH3 header may only be present in Non-Storing >> mode, and >> >> it may only be placed in the packet by the root of the DODAG, which must >> be the >> >> source of the resulting IPv6 packet {{RFC2460}}. In this case, the >> address used >> >> as Compression Reference is that the address of the root, and it can be >> implicit >> >> when the address of the root is. >> >> >> >> The Compression Reference MUST be determined as follows: >> >> >> >> The reference address may be obtained by configuration. The configuratio= n >> may >> >> indicate either the address in full, or the identifier of a 6LoWPAN >> Context that >> >> carries the address {{RFC6775}}, for instance one of the 16 Context >> Identifiers >> >> used in LOWPAN-IPHC {{RFC6282}}. >> >> >> >> Else, and if there is no IP-in-IP encapsulation, the source address in >> the IPv6 >> >> header that is compressed with LOWPAN-IPHC is the reference for the >> compression. >> >> >> >> Else, and if the IP-in-IP compression specified in this document is used >> and the >> >> Encapsulator Address is provided, then the Encapsulator Address is the >> reference. >> >> >> >> (note that this means that the specification does not expect >> IP-in-IP-in-IP and >> >> does not enforce any order in 6LoRH ... should it???). >> >> >> >> >> >> Cheers, >> >> >> >> Pascal >> >> >> >> *From:* Tengfei Chang [mailto:tengfei.chang@gmail.com] >> *Sent:* lundi 18 janvier 2016 14:26 >> *To:* Pascal Thubert (pthubert) >> *Cc:* 6lo@ietf.org; 6tisch@ietf.org >> *Subject:* Re: [6lo] Format inside of an RPL domain >> >> >> >> I agree with this format! +1 >> >> >> >> Tengfei >> >> >> >> On Mon, Jan 18, 2016 at 9:41 AM, Pascal Thubert (pthubert) < >> pthubert@cisco.com> wrote: >> >> Dear TengFei: >> >> >> >> I agree that the draft is lacking description when there is no IP in IP. >> I=E2=80=99ll create a ticket. >> >> >> >> When there is no IP in IP present in the 6LoRH, then the headers >> compressed by 6LoRH are considered placed right after the IP header >> compressed by IPHC, and considered as compressed. It results that the NH >> bit in the IPHC really indicates how the compression is done for the hea= der >> that is after the headers compressed by 6LoRH. >> >> >> >> For an ICMP message I=E2=80=99d think that you=E2=80=99ll be using: >> >> >> >> +- ... -+- ... -+-+-+- ... -+-+-+-+-+ ... -+-+-+-+-+-+-+-+-+-+-+... >> >> |11110001| RPI | NH =3D 0 | NH =3D 58 | ICMP message >> >> |Page 1 | 6LoRH | 6LOWPAN-IPHC | (ICMP) | (no compression) >> >> +- ... -+- ... +-+-+-+- ... -+-+-+-+-+ ... -+-+-+-+-+-+-+-+-+-+-+... >> >> <- RFC 6282 -> >> >> No RPL artifact >> >> >> >> Does that make sense? >> >> >> >> Pascal >> >> >> >> *From:* 6lo [mailto:6lo-bounces@ietf.org] *On Behalf Of *Tengfei Chang >> *Sent:* lundi 18 janvier 2016 09:18 >> *To:* 6lo@ietf.org >> *Subject:* [6lo] Format inside of an RPL domain >> >> >> >> Dear All, >> >> >> >> Currently I have a question about the format of packet inside of an RPL >> domain when using 6LoRH. >> >> >> >> For example when ping a mote inside an RPL domain, will the format of >> echo request and reply look like this? >> >> >> >> PAGE DISPATCH (page 1) + IPHC + 6LoRH RH3 + ICMPv6 >> >> PAGE DISPATCH (page 1) + IPHC + 6LoRH RPI + ICMPv6 >> >> >> >> If so, there is no next header field in 6LoRH to indicate the following >> field is ICMP. >> >> What's the right format for this case? >> >> >> >> Thanks a lot! >> >> Tengfei >> >> >> >> _______________________________________________ >> 6lo mailing list >> 6lo@ietf.org >> https://www.ietf.org/mailman/listinfo/6lo >> >> > --001a114c18465b1216052b420fb6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
[resending from the right e-mail address]

On Mon, Feb 8, 2016 at 2:16 PM, Th= omas Watteyne <twatteyne@gmail.com> wrote:
Pascal,

I hope my co= mments don't come too late. Please find below some edits of your sugges= ted text.

My biggest comment is about naming, as I= think we are using "nicknames" for things, which makes things ve= ry hard to follow.

Thomas

## DODAG Root Address= {#impl-comp-ref}

=C2=A0=

With this specification, an optimal compression

TW> I would drop the word "optimal"= , which implies you can prove it. Replace by "efficient"?<= /p>

of IP-in-IP encapsulation can be=

achieved if an endpoint of the packet is the ro= ot of the RPL DODAG associated to

the = Instance

TW> please make sure that you use= the capital "I" on purpose

that is used to forward the packet, and the root address is known

implicitly as opposed to signaled explicit= ly in the data packets.

=C2=A0<= u>

With RPL {{RFC6550}}, the address of

TW> add "the"

DODAG root is known from the DODAGID field

of the DIO messages. For a Global Instance, the RPLInsta= nceID that is present in

the RPI

TW> where does the term RPI come from? Accordin= g to RFC6553, the full name is "RPL Option", no?

is enough information to identify the DODAG that th= is node participates

to and its associ= ated root. But for a Local Instance, the address of the root<= /span>

MUST be explicit, either in some device configuratio= n or signaled in the packet,

as the so= urce or the destination address, respectively.

=C2=A0

When implicit, the ad= dress of the DODAG root MUST be determined as follows:=

=C2=A0

If the whole n= etwork is a single DODAG then the root can be well-known and does=

not need to be signaled in the packets. But

TW> "if" missing?

RPL does not expose that property

and it can only be known by a configuration applied to a= ll nodes.

=C2=A0<= /p>

Else, the router that encapsulates the packet and compresse= s it with this

specification MUST al= so place an RPI in the packet as prescribed by {{RFC6550}}

to enable the identification of the DODAG. The RPI mus= t be present even in the

case when the= router also places an RH3 header in the packet.

=C2=A0

It is expected that = the RPL implementation provides an abstract context table,

indexed by Global RPLInstanceID, that provides the add= ress of the root of the

DODAG that thi= s nodes participates to for that particular Instance.<= /p>

=C2=A0

=C2=A0

## Compression Reference {#sig-comp-ref}

=C2=A0

In order to optimize the compression of IP addresses present in the RH3 he= aders,

this specification requires tha= t the 6LoWPAN layer identifies an address that is

<= p class=3D"MsoNormal">used as reference for the compression. With this specification,= the Compression

Reference for address= es found in an RH3 header is the source of the IPv6 packet.

=C2=A0

With RPL = {{RFC6550}}, an RH3

> In the same vain as = my comment about RPI, we should really force ourselves to use the same term= inology, or else it gets really really confusing.

&g= t; I understand that RH3 stands for the-Routing-header-with-IPv6-routing-ty= pe-3, but according to RFC6554, this is called "RPL Source Route Heade= r". Let's please use that name...


header may only be present in Non-Stori= ng mode, and

it may only be placed in = the packet by the root of the DODAG, which must be the=

source of the resulting IPv6 packet {{RFC2460}}. In this c= ase, the address used

as Compression R= eference is that the address of the root, and it can be implicit<= /u>

when the address of the root is.

=C2=A0

The Compr= ession Reference MUST be determined as follows:

=C2=A0

The reference address= may be obtained by configuration. The configuration may

indicate either the address in full, or the identifier o= f a 6LoWPAN Context that

carries the a= ddress {{RFC6775}}, for instance one of the 16 Context Identifiers

used in LOWPAN-IPHC {{RFC6282}}.=

=C2=A0

Else, a= nd if there is no IP-in-IP encapsulation, the source address in the IPv6=

header that is compressed with LOWPAN-IP= HC is the reference for the compression.

=C2=A0

Else, and if the IP-in-IP = compression specified in this document is used and the=

Encapsulator Address is provided, then the Encapsulator Ad= dress is the reference.

=C2=A0<= u>

(note that this means that the specification = does not expect IP-in-IP-in-IP and

doe= s not enforce any order in 6LoRH ... should it???).

=

On Wed, Jan 20, 2016 at 4:14 PM, Pascal Thubert (pthubert) <pthub= ert@cisco.com> wrote:

Hello Tengfei and Simon (and all):=

=C2=A0

I=E2=80=99ll need some more help from you.

=C2=A0

I=E2=80=99m in the process of refining the t= ext that indicates how the root address is obtained and how to compute the = Compression Reference for the RH3.

=C2=A0

I came up with the following, which indicate= s that the source of the packet (which should always be the root for now bu= t who knows) is the reference for RH3 compression.

=C2=A0

Is that what we want? Is it clear enough?=

=C2=A0

=C2=A0

## DODAG Root Address {#impl-comp-ref}

=C2=A0

With this specification, an optimal compression of IP-in-IP en= capsulation can be

achieved if an endpoint of the packet is the root of the RPL D= ODAG associated to

the Instance that is used to forward the packet, and the root = address is known

implicitly as opposed to signaled explicitly in the data packe= ts.

=C2=A0

With RPL {{RFC6550}}, the address of DODAG root is known from = the DODAGID field

of the DIO messages. For a Global Instance, the RPLInstanceID = that is present in

the RPI is enough information to identify the DODAG that this = node participates

to and its associated root. But for a Local Instance, the addr= ess of the root

MUST be explicit, either in some device configuration or signa= led in the packet,

as the source or the destination address, respectively.=

=C2=A0

When implicit, the address of the DODAG root MUST be determine= d as follows:

=C2=A0

If the whole network is a single DODAG then the root can be we= ll-known and does

not need to be signaled in the packets. But RPL does not expos= e that property

and it can only be known by a configuration applied to all nod= es.

=C2=A0

Else, the router that encapsulates the packet and compresses i= t with this

specification MUST also place an RPI in the packet as prescrib= ed by {{RFC6550}}

to enable the identification of the DODAG. The RPI must be pre= sent even in the

case when the router also places an RH3 header in the packet.<= u>

=C2=A0

It is expected that the RPL implementation provides an abstrac= t context table,

indexed by Global RPLInstanceID, that provides the address of = the root of the

DODAG that this nodes participates to for that particular Inst= ance.

=C2=A0

=C2=A0

## Compression Reference {#sig-comp-ref}<= /p>

=C2=A0

In order to optimize the compression of IP addresses present i= n the RH3 headers,

this specification requires that the 6LoWPAN layer identifies = an address that is

used as reference for the compression. With this specification= , the Compression

Reference for addresses found in an RH3 header is the source o= f the IPv6 packet.

=C2=A0

With RPL {{RFC6550}}, an RH3 header may only be present in Non= -Storing mode, and

it may only be placed in the packet by the root of the DODAG, = which must be the

source of the resulting IPv6 packet {{RFC2460}}. In this case,= the address used

as Compression Reference is that the address of the root, and = it can be implicit

when the address of the root is.

=C2=A0

The Compression Reference MUST be determined as follows:

=C2=A0

The reference address may be obtained by configuration. The co= nfiguration may

indicate either the address in full, or the identifier of a 6L= oWPAN Context that

carries the address {{RFC6775}}, for instance one of the 16 Co= ntext Identifiers

used in LOWPAN-IPHC {{RFC6282}}.

=C2=A0

Else, and if there is no IP-in-IP encapsulation, the source ad= dress in the IPv6

header that is compressed with LOWPAN-IPHC is the reference fo= r the compression.

=C2=A0

Else, and if the IP-in-IP compression specified in this docume= nt is used and the

Encapsulator Address is provided, then the Encapsulator Addres= s is the reference.

=C2=A0

(note that this means that the specification does not expect I= P-in-IP-in-IP and

does not enforce any order in 6LoRH ... should it???).<= u>

=C2=A0

=C2=A0

Cheers,

=C2=A0

Pascal

=C2=A0

From: Tengfei Chang [mailto:tengfei.chang@gmail.com]
Sent: lundi 18 janvier 2016 14:26
To: Pascal Thubert (pthubert) <pthubert@cisco.com>
Cc: 6lo@ietf.org; 6tisch@ietf.org
Subject: Re: [6lo] Format inside of an RPL domain

=C2=A0

I agree with this format! +1

=C2=A0

Tengfei

=C2=A0

On Mon, Jan 18, 2016 at 9:41 AM, Pascal Thubert (pth= ubert) <pthubert= @cisco.com> wrote:

Dear TengFei:

=C2=A0

I agree that the draft is lacking descriptio= n when there is no IP in IP. I=E2=80=99ll create a ticket.=

=C2=A0

When there is no IP in IP present in the 6Lo= RH, then the headers compressed by 6LoRH are considered placed right after the IP header compressed by IPHC, and considered as com= pressed. It results that the NH bit in the IPHC really indicates how the co= mpression is done for the header that is after the headers compressed by 6L= oRH.

=C2=A0

For an ICMP message I=E2=80=99d think that y= ou=E2=80=99ll be using:

=C2=A0

=C2=A0=C2=A0 +- ...=C2=A0 -+- ...=C2=A0 -= +-+-+- ... -+-+-+-+-+ ... -+-+-+-+-+-+-+-+-+-+-+...

=C2=A0=C2=A0 |11110001|=C2=A0 RPI=C2=A0= =C2=A0 |=C2=A0 NH =3D 0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | NH =3D 58=C2= =A0 |=C2=A0 ICMP message

=C2=A0=C2=A0 |Page 1=C2=A0 | 6LoRH=C2=A0 = | 6LOWPAN-IPHC=C2=A0 | (ICMP)=C2=A0=C2=A0 |=C2=A0 (no compression)

=C2=A0=C2=A0=C2=A0+- ...=C2=A0 -+- ... +-= +-+-+- ... -+-+-+-+-+ ... -+-+-+-+-+-+-+-+-+-+-+...

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 <-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RFC 6282=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ->

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0No RPL artifact<= /u>

=C2=A0

Does that make sense?

=C2=A0

Pascal

=C2=A0

=C2=A0


_______________________________________________
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo



--001a114c18465b1216052b420fb6--