Dear all :
I am an assigned INT directorate reviewer for draft-ietf-6lo-dect-ule-05. These
comments were written primarily for the benefit of the Internet Area Directors.
Document editors and shepherd(s) should treat these comments just like they
would treat comments from any other IETF contributors and resolve them along
with any other Last Call comments that have been received. For more details on
the INT Directorate, see http://www.ietf.org/iesg/directorate.html.
Document: draft-ietf-6lo-dect-ule
Transmission of IPv6 Packets over DECT Ultra Low Energy
Reviewer: Pascal Thubert
Review Date: Sept 27, 2016
IETF Last Call Date: TBD
Summary: Issues concerning the subnet model that needs to be explicited.
Major issues:
- Reference to draft-ietf-6lo-privacy-considerations and privacy of addresses
should be addressed (related to lifespan of IEEE EUI48 addresses, random but
permanent is still not too good)
- Subnet model (Section 3.3) should be described in more details, indicating
NBMA Multi-Link SubNet (MLSN). Suggestion to review/emulate RFC 7668 (section
3.2.1 and last paragraph of 3.2.2)
- Reference to draft-ietf-6lo-backbone-router could be made to address the L3
perspective of node mobility
- Some IMPERATIVE is extraneous. (RFC2119: "Imperatives of the type defined in
this memo must be used with care and sparingly. In particular, they MUST only
be used where it is actually required for interoperation or to limit behavior
which has potential for causing harm")
Minor issues:
- inline on the right of the original text, with a "<<" prefix
---
6Lo Working Group P. Mariager
Internet-Draft J. Petersen, Ed.
Intended status: Standards Track RTX A/S
Expires: November 17, 2016 Z. Shelby
ARM
M. Van de Logt
Gigaset Communications GmbH
D. Barthel
Orange Labs
May 16, 2016
Transmission of IPv6 Packets over DECT Ultra Low Energy
< snip>
1. Introduction
DECT Ultra Low Energy (DECT ULE or just ULE) is an air interface <<<
spell DECT on first use
technology building on the key fundamentals of traditional DECT /
CAT-iq but with specific changes to significantly reduce the power
consumption at the expense of data throughput. DECT (Digital <<<
DECT spelling
Enhanced Cordless Telecommunications) is a standard series
[EN300.175-part1-7] specified by ETSI and CAT-iq (Cordless Advanced
Technology - internet and quality) is a set of product certication
and interoperability profiles [CAT-iq] defined by DECT Forum. DECT
< snip>
In its generic network topology, DECT is defined as a cellular
network technology. However, the most common configuration is a star
network with a single FP defining the network with a number of PP
attached. The MAC layer supports both traditional DECT as this is
<< "both" is unclear, can you rephrase?
used for services like discovery, pairing, security features etc.
All these features have been reused from DECT.
< snip>
[DECT ULE PP]-----\ /-----[DECT ULE PP]
\ /
[DECT ULE PP]-------+[DECT ULE FP]+-------[DECT ULE PP]
/ \
[DECT ULE PP]-----/ \-----[DECT ULE PP]
Figure 2: DECT ULE star topology <<
suggestion to place a forward reference to section 3.3 on how IP uses that
(MLSN)
A significant difference between IEEE 802.15.4 and DECT ULE is that
the former supports both star and mesh topology (and requires a
routing protocol), whereas DECT ULE in it's primary configuration
does not support the formation of multihop networks at the link
layer. In consequence, the mesh header defined in [RFC4944] for mesh
< snip>
When bound to a FP, a PP is assigned a 20 bit TPUI which is unique <<
in reference to draft-ietf-6lo-privacy-considerations it would be good to
indicate whether this is short lived or long lived, so as to figure if an IPv6
address can be derived or not.
within the FP. This TPUI is used for addressing (layer 2) in
messages between FP and PP.
< snip>
Optionally each DECT PP and DECT FP can be assigned a unique (IEEE)
MAC-48 address additionally to the DECT identities to be used by the <<
same as above, it would be good to indicate whether this is short lived or long
lived, so as to figure if an IPv6 address can be derived or not.
6LoWPAN. During the address registration of non-link-local addresses
as specified by this document, the FP and PP can use such MAC-48 to
construct the IID.
< snip>
support complete IP packets, the DLC layer of DECT ULE SHALL per this <<
there is a MUST later in the document, no need to uppercase here; whether this
setting is needed is debatable
specification be configured with a MTU size that fits the
requirements from IPv6 data packets, hence [RFC4944] fragmentation/
reassembly is not required. <<
unclear. .. since DLC supports fragmentation there is no need for 6LoWPAN
fragmentation is there? The adaptation described here only provides value if
the DLC fragmentation is armful. Is that the case ?
It is expected that the LOWPAN_IPHC packet will fulfil all the
requirements for header compression without spending unnecessary
overhead for mesh addressing.
It is important to realize that the usage of larger packets will be
at the expense of battery life, as a large packet inside the DECT ULE
stack will be fragmented into several or many MAC layer packets, each
consuming power to transmit / receive. <<
proof? fragments increase reliability and reduce the size of retried pieces. is
there a paper showing pros vs cons or is this the author intuition ?
2.5. Additional Considerations
The DECT ULE standard allows PP to be registered (bind) to multiple
FP and roaming between these FP. This draft does not consider the <<
Why ?? this is where the backbone router becomes handy. If the subnet model is
clarified to NBMA / MLSN then it is possible to assign the same prefix to
multiple 6LBRs and connect them through a 6lo backbone router
scenarios of PP roaming between multiple FP. The use of repeater
functionality is also not considered in this draft.
< snip>
3.1. Protocol Stack
In order to enable transmission of IPv6 packets over DECT ULE, a
Permanent Virtual Circuit (PVC) has to be opened between FP and PP.
This MUST be done by setting up a service call from PP to FP. The PP <<
is this MUST coming from this spec or from DECT? if the latter then just say
"this is done by..."
SHALL specify the <<IWU-ATTRIBUTES>> in a service-change (other)
message before sending a service-change (resume) message as defined
in [TS102.939-1]. The <<IWU-ATTRIBTES>> SHALL define the ULE
Application Protocol Identifier to 0x06 and the MTU size to 1280
octets or larger. The FP MUST send a service-change-accept (resume)
containing a valid paging descriptor. The PP MUST be pageable.
< snip>
3.2. Link Model
The general model is that IPv6 is layer 3 and DECT ULE MAC+DLC is
layer 2. The DECT ULE implements already fragmentation and
reassembly functionality, hence [RFC4944] fragmentation and <<
this is repeating and sight contradictory. suggestions to keep the text
starting at RFC4944, dropping the beginning of the sentence
reassembly function MUST NOT be used. The DECT ULE DLC link (PVC)
MUST be configured with a minimum MTU size of at least 1280 octets in <<
Not sure this is needed
order to meet the size requirements of IPv6.
< snip>
compression context if any, and from address registration information
(see Section 3.2.2).
Due to DECT ULE star topology, each branch of the star is considered
to be an individual link and thus the PPs cannot directly hear one <<
indicate that this is NBMA, multilink subnet. See related text in 6LoWPAN BTLE
RFC 7668
another and cannot talk to one another with link-local addresses.
However, the FP acts as a 6LBR for communication between the PPs.
After the FP and PPs have connected at the DECT ULE level, the link
can be considered up and IPv6 address configuration and transmission
can begin. The FP ensures address collisions do not occur.
3.2.1. Stateless Address Autoconfiguration
At network interface initialization, both 6LN and 6LBR SHALL generate
and assign to the DECT ULE network interface IPv6 link-local
addresses [RFC4862] based on the DECT device addresses (see
Section 2.3) that were used for establishing the underlying DECT ULE
connection.
The DECT device addresses IPEI and RFPI MUST be used to derive the <<
SHOULD vs. MUST: with a MUST, this means that the 6LoWPAN code does never
expect a link local that is not fully elided (3.2.4.1.)?
IPv6 link-local 64 bit Interface Identifiers (IID) for 6LN and 6LBR,
respectively.
< snip>
see [RFC7136]. For example from RFPI=11.22.33.44.55 the derived IID
is 80:11:22:ff:fe:33:44:55 and from IPEI=01.23.45.67.89 the derived
IID is 00:01:23:ff:fe:45:67:89. <<
This seems to be setting permanent addresses (admittedly Link local), and the
privacy properties of such addresses should be addressed, eg addresses do not
(lust not) leak in app layer in any fashion
As defined in [RFC4291], the IPv6 link-local address is formed by
appending the IID, to the prefix FE80::/64, as shown in Figure 4.
< snip>
(CGAs) [RFC3972], privacy extensions [RFC4941], Hash-Based Addresses
(HBAs) [RFC5535], DHCPv6 [RFC3315], or static, semantically opaque <<
This seems to be setting permanent addresses; discussion on renewing addresses
would be good, ref to draft-ietf-6lo-privacy-considerations would help, and the
security section could just point here as opposed to use IMPERATIVE
addresses [RFC7217] SHOULD be used by default. In situations where
< snip>
2. A DECT ULE 6LN MUST NOT register its link-local address. A DECT << the
registration has 2 roles, DAD (which can be avoided for globally unique
addresses) and SLLA mapping. This seems to indicate that SLLA is deduced from
the LL so there's special code to avoid using an ND cache?
ULE 6LN MUST register its non-link-local addresses with the 6LBR by
< snip>
accordingly. The NS with the ARO option MUST be sent irrespective of
the method used to generate the IID. The 6LN MUST register only one << why
can't a device form more than one address?
IPv6 address per available IPv6 prefix.
< snip>
the DAM field of the compressed IPv6 header as CID=1, DAC=1 and
DAM=01 or DAM=11. Note that when a context is defined for the IPv6 <<
considering the rest of the optimizations, why don't you have a /128 context
for the 6LBR?
destination address, the 6LBR can infer the elided destination prefix
by using the context.
< snip>
3.3. Subnets and Internet Connectivity Scenarios << Missing scenario
below, same /64, with backbone router
6LN 6LN
\ /
\ /
6LN --- 6LBR ------ 6LBR --- 6LN
/ \
/ \
6LN 6LN
<DECT ULE> <Backbone> <DECT ULE>
< snip>
_______________________________________________
6lo mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lo
