Samita,

Thanks for message.

I write some comments below, just two cents worth.

Le 07/07/2011 02:20, Samita Chakrabarti a écrit :
> 6lowpan-nd has 6lowpan specific assumptions - or low power and lossy
>  network assumptions.

ND tailored in the 6lowpan WG has indeed specific modifications.

But, I am not sure what is meant by low power.  I suppose it is not as
if non-6lowpan networks were high-power(?)  It is not as if only
Personal Area Networks (pan in 6lowpan) need low power.  There exist
short radio range low-power networks which are not worn by person.

> It has got some support for 16bit addresses to support 802.15.4
> devices but that part is optional.

This support of 16bit addresses in draft-ietf-6lowpan-nd-17 is
motivated, I believe, by 802.15.4, which is good because it can be
understood.

But, its use in this draft seems strange.

I looked for it.

"16bit" appears precisely once - more should be.
"16 bit" does not appear.
"MAC16" is well defined on page 45 but is never shown in a message
format.  I guess this is because there are too many terms used in this
document about this 16bit address.
"GP16" is well used much throughout the document.  However
its definition is ambiguous because it says:
> GP16: Global Address based on the 802.15.4 Short Address.  This
> address may not be unique.

Is it the GP16 address which may not be unique?  Or is it the 802.15.4
Short Address which may not be unique?

(GP16 must be unique, and IETF has no say about uniqueness of MAC
addresses be them 16bit or 48bit).

Then.

RFC4944 defines an Interface Identifier using the 16 bit PAN ID and the
16 bit short MAC address.  It does _not_ define any Interface Identifier
_not_ using the PAN ID.

In this sense, there may be a conflict between RFC4944 and 6lowpan-nd.

At this point, one may say that the "lowpan" is different than 802.15.4
in that lowpan does not use PAN ID.  Which brings us back to what is a
"lowpan" and, as you say:
> What is the real definition of LLN ?  I suppose, whatever we do,
> RFC4944 and the 6lowpan-nd or lowpan-nd would be tied together.

Tied or exclusive?

Then.

> When a host has configured a non-link-local IPv6 address

Is that a globally-unique address?  Or is it a "GP16" i.e. a global
address which may not be unique? (derived from the 16bit MAC address in
a non-RFC4944 way).

> EUI-64:        64 bits.  This field is used to uniquely identify the
> interface of the registered address by including the EUI-64
> identifier [EUI64] assigned to it unmodified.

I am not sure that reference [EUI64] allows to form EUI64 from a 16bit
short MAC address.  I think that reference recommends to form EUI64 only
from the 48bit MAC addresses.  It says often "MAC-48" and never
"MAC-16".  In this sense, should I believe that 6lowpan-ND Address
Registration Option _never_ registers a IPv6 address derived from a
16bit short MAC address?  I guess I may be wrong, but clarification is
needed.

Moreover, RFC4944 says:
> All 802.15.4 devices have an IEEE EUI-64 address, but 16-bit short
> addresses (Section 3 and Section 12) are also possible.

this "but" further suggesting that 16-bit short addresses are _not_
EUI-64 addresses.

> Address configuration follows [RFC4862].  For an address not derived
> from an EUI-64, the M flag of the RA determines how the address can
> be configured.

This is so complex to understand.

The M flag of RA tells DHCP-vs-RA regardless of the existence of the
term EUI-64.  One could use DHCP to form addresses whose Interface
Identifier is based on EUI-64.

An address _not_ derived from an EUI-64 could be an address using the
16bit short MAC address?  If so, then you mean that only in that
specific case (16bit short MAC addresses) the M flag tells
DHCP-vs-SLAAC?  But the M flag should always tell so, regardless of the
way the Interface Identifier is formed, or even more regardless of how
the EUI-64 is formed (IETF does not define EUI-64).

Are you sure you don't mean "Interface Identifier" when you say
"EUI-64"?  Interface Identifier is extensively used in rfc2464, 4291,
4944, 4861 which are classical for IPv6 implementations.

Or does one mean that when an address is formed from the 16bit short
address then one MUST use DHCP?  I do not agree with this either.  One
could use SLAAC (not DHCP) and short 16-bit addresses very well, as
rfc4944 describes but with PAN-ID.

Does one mean that when an IPv6 address does _not_ use PAN-ID (non
rfc4944) but _does_ use short IPv6 MAC addresses then one MUST use DHCP?
  In that case too, I believe one could still use SLAAC (not necessarily
DHCP) provided one defines a way to form Interface Identifier from the
short 16bit MAC address only (and not use the the PAN ID as RFC4944
does).  I do not know why would one _not_ use PAN ID, and if you do then
please say.

> If the M flag is set in the RA, then DHCPv6 MUST be used to assign
> the address.  If the M flag is not set, then the address can be
> configured by any other means (and duplicate detection is performed
> as part of the registration process).

Is one sure one means so?

First, the M flag mentioned above seems to be the one in RFC4861 (and
not RFC4862 that is cited - rfc4862 says it does not use the M flag page
27).

Second, rfc4862 says "When [M] set, it indicates that addresses are
available via Dynamic Host Configuration Protocol".

Or, what this draft says is "MUST" DHCP, which is much stronger.

Third, rfc4862 says that when M is not set then no information is
available via DHCPv6.  Or, what this draft says is that if M is not set
then the address _can_ be configured by any other means.  This opening
is what this draft says, and not what the rfc4862 says.

I personally disagree with a proposal to use any other dynamic mechanism
than DHCPv6-SLAAC-PPP methods to configure addresses.

> Once an address has been configured it will be registered by
> unicasting a Neighbor Solicitation with the Address Registration
> option to one or more routers.

Does this mean that a node could use SLAAC to configure an address and
then register it to its router with NS?  I do not see why should it use
Address Registration option to achieve that registration.  NA should be
sufficient.  Even a simple RS is often enough.

> A host should choose a sleep time appropriate for its energy
> characteristics, and set a registration lifetime larger than the
> sleep time to ensure the registration is renewed successfully
> (considering e.g. clock drift and additional time for potential
> retransmissions of the re-registration).

But why is not the prefix lifetime used?  I think one could use the
existing prefix lifetime for the purposes of energy saving, instead of
defining new lifetime fields.

Lifetime and in general time is difficult to implement.  We already have
good implementations of ND and all time values are there to be used for
cases such as energy saving and more other cases.

> A host should also consider the stability of the network (how quickly
> the topology changes) when choosing its sleep time (and thus
> registration lifetime).

Yes, the host should consider the stability of the network when choosing
its sleep time.  And the stability of the network could be expressed by
the prefix lifetime, because the prefix is a network prefix; the
lifetime draft proposes is an address lifetime and that is not the
stability of the network but the stability of the address.

> (the maximum Router Lifetime is about 18 hours whereas the maximum
> Registration lifetime is about 45.5 days)

And the maximum reachable/retrans timer, and prefix lifetime are 136years...

In the entire Address Registration discussion - I think existing ND
lifetime fields could be used to achieve the kinds of sleep modes one
needs.  I do not see the necessity of ARO and the registration process.

Alex

>
> Thanks, -Samita
>
> -----Original Message----- From: 6lowpan-bounces@ietf.org
> [mailto:6lowpan-bounces@ietf.org] On Behalf Of Alexandru Petrescu
> Sent: Friday, July 01, 2011 9:27 AM To: 6lowpan@ietf.org Subject: Re:
> [6lowpan] Titles of 6LoWPAN RFCs
>
> Le 29/06/2011 13:45, Pascal Thubert (pthubert) a écrit :
>> Hi Carsten:
>>
>> Maybe the answer depends on the draft. HC depends on the 802.15.4
>> for some of the compression procedure and it makes sense that this
>>  appears in the title.
>>
>> ND does not have such a strong link to the MAC so there is no
>> point pinpointing 802.15.4 or any specific IEEE.
>
> This is so wrong (sorry).
>
> ND is fundamentally related to IEEE stuff, at least in the way it
> forms addresses.
>
> An ND for 802.15.4 could, for example, tell that Routers must MLD
> REPORT and then 802.15.4-join (a kind of MAC message).
>
>> Rather, ND makes sense because of the NBMA nature of the network,
>> and the desire to save multicast operation, which is common to
>> LLNs.
>
> Yes, and the conceptual NBMA nature is illustrated in practical terms
> of ND when an RS is sent to ff02::2 (an IP address) which is 33:33::2
> (an IEEE MAC address).
>
> Multicast operation is a common link-layer operation in all Ethernet
>  and its family, not necessarily LLN.
>
> Alex
>
>> So I do not think we need to change ND.
>>
>> Finally, 6LoWPAN as a name as become a lot more than what the
>> acronym could initially stand for. I do not think the drafts should
>> use 6LoWPAN for what it expands to, but rather as the name of the
>> WG that defined all those drafts.
>>
>> Cheers,
>>
>> Pascal
>>
>>
>>> -----Original Message----- From: 6lowpan-bounces@ietf.org
>>> [mailto:6lowpan-bounces@ietf.org] On Behalf Of Carsten Bormann
>>> Sent: Wednesday, June 29, 2011 1:20 PM To: 6lowpan WG Subject:
>>> [6lowpan] Titles of 6LoWPAN RFCs
>>>
>>> While completing the RFC editor work for 6LoWPAN-HC, the issue
>>> of supplying correct and useful titles for our RFCs came up
>>> again. You may recall that we went through a little bit of
>>> discussion already for 6LoWPAN-ND, which has the same problem.
>>>
>>> The exposition of the problem takes a couple of paragraphs, so
>>> bear with me, please.
>>>
>>> Superficially, one part of the problem is that the marker that
>>> people are using to find our work, 6LoWPAN, was built out of the
>>>  WPAN abbreviation invented by IEEE.
>>>
>>> One issue with that is that, strictly speaking, 6LoWPAN would
>>> require a double expansion in an RFC title as in
>>>
>>> 6LoWPAN (IPv6 over Low Power WPAN (Wireless Personal Area
>>> Networks))
>>>
>>> WPAN also is a bad short-term politically motivated term -- it
>>> was needed in IEEE to get the 802.15.4 radio accepted under
>>> 802.15. WPAN ("Wireless Personal Area Networks") is highly
>>> misleading, as there is nothing at all "Personal Area" about
>>> 802.15.4 WPANs. The deciding characteristic is the low-power,
>>> limited-range design (which, as a consequence, also causes the
>>> additional characteristic of lossiness that ROLL has chosen for
>>> its "Low-Power/Lossy" moniker).
>>>
>>> Still, the misleading four letters WPAN are part of the now
>>> well-known "6LoWPAN" acronym, and we may need to use this acronym
>>> to make sure the document is perceived in the right scope.
>>>
>>> In the recent history of 6LoWPAN-HC being fixed up to address
>>> WGLC comments, there was a silent title change.
>>>
>>> HC-13 used the title: (September 27, 2010) Compression Format
>>> for IPv6 Datagrams in 6LoWPAN Networks HC-14 changed this to:
>>> (February 14, 2011) Compression Format for IPv6 Datagrams in Low
>>> Power and Lossy Networks (6LoWPAN)
>>>
>>> This borrows ROLL's term "Low-Power and Lossy Networks", which
>>> may seem natural to the authors, who have done a lot of work in
>>> ROLL. Note that the ROLL WG has a wider scope than the 6LoWPAN WG
>>> (it is at layer three, connecting different link layer
>>> technologies), so it may be useful to retain a distinction
>>> between 6LoWPANs and LLNs.
>>>
>>> Specifically, 6LoWPAN-HC as defined has a lot of dependencies on
>>>  RFC 4944 and IEEE 802.15.4, so using it as-is in generic "LLNs"
>>>  would be inappropriate.  (It sure can be adapted for many
>>> non-6LoWPAN LLNs, but that would be a separate draft.)
>>>
>>> 6LoWPAN-ND has a similar problem.  Indeed, some of the concepts
>>> of 6LoWPAN-ND may be applicable to a lot of networks that benefit
>>> from relying less on multicast.  In an attempt to widen the
>>> scope, there was a title change when we rebooted the ND work to
>>> simplify it:
>>>
>>> ND-08: (February 1, 2010) 6LoWPAN Neighbor Discovery ND-09:
>>> (April 27, 2010) Neighbor Discovery Optimization for Low-power
>>> and Lossy Networks
>>>
>>> However, the document as it passed WGLC still is focused on
>>> 6LoWPANs (e.g., it contains specific support for 6COs).
>>>
>>> For both HC and ND, I don't think we properly discussed the
>>> attempted title changes in the WG.
>>>
>>> So what are the specific issues to be decided? I see at least:
>>>
>>> -- Should we drop the 6LoWPAN marker from our documents? (Note
>>> that RFC 4944 doesn't have it, but in the 4 years since, the term
>>> has gained some recognition.) Should there be another common
>>> marker? -- E.g., should we change over the whole documents (HC,
>>> ND) to LLN? -- Should we just refer to IEEE 802.15.4 in the title
>>> (no 6LoWPAN)? HC = Compression Format for IPv6 Datagrams over
>>> IEEE 802.15.4
>> Networks
>>> ND = Neighbor Discovery Optimization for IEEE 802.15.4 Networks
>>> -- Or should we stick with 6LoWPAN in both title and body? -- If
>>>  the latter, what is an appropriate expansion of 6LoWPAN? Can we
>>>  get rid of the "Personal" in the expansion? -- IPv6 over Low
>>> power Wireless Personal Area Networks [RFC4944] -- IPv6-based Low
>>> power Wireless Personal Area Networks [RFC4944] -- IPv6 over
>>> Low-Power Wireless Area Networks -- IPv6-based Low-power WPANs --
>>> Other ideas? -- Whatever we decide about the above: What is the
>>> relationship between the well-known term 6LoWPAN and ROLL LLNs?
>>>
>>> Since 6LoWPAN-HC is waiting in the RFC editor queue, blocked for
>>>  just this title issue, I'd like to resolve these questions
>>> quickly. Please provide your reasoned opinion to this mailing
>>> list by July 1.
>>>
>>> Gruesse, Carsten
>>>
>>> _______________________________________________ 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
>