Re: [6lo] New I-D draft-delcarpio-6lo-wlanah-00.txt

[Alexandru Petrescu <[e-mail]>]

Dear Felipe,

Le 18/06/2015 12:28, Felipe Del Carpio a écrit :
> Dear Alexandru,
>
> Thank you very much for your comments, please find answers inline in
> [FDC].
>
> Best regards, Felipe
>
>> -----Original Message----- From: 6lo [mailto:[e-mail]]
>> On Behalf Of Alexandru Petrescu Sent: Wednesday, June 17, 2015 8:05
>> PM To: [e-mail] Subject: Re: [6lo] New I-D
>> draft-delcarpio-6lo-wlanah-00.txt
>>
>> Hi,
>>
>> Le 17/06/2015 11:02, Felipe Del Carpio a écrit :
>>> Dear all,
>>>
>>> We present how 6LoWPAN can be used to efficiently transport IPv6
>>> over 802.11ah, this is a first version.
>>
>> Will subGhz 802.11ah be the same in each country?  Or not?
>>
>> We know for example that 802.11a is not deployed, not marketed, and
>> not important at all in the country where I live; yet it is
>> important in other countries.
>>
>> Is 802.11ah specific to a particular country?  We know that some
>> 802.11"letter" works in only one particular country.
>>
>
>
> [FDC] 802.11 standards work on ISM bands

Well, not all 802.11 are on ISM bands.  802.11p is not on an ISM band.
(5.9GHz).

> and indeed different regions in the world have defined ISM bands in
> slightly different frequencies and have imposed different regulations
> for each ISM band. 802.11ah is no exception to this rule, it will use
> an ISM band below 1Ghz. The exact frequency depends on the region. In
> a reference document from IEEE
> (https://mentor.ieee.org/802.11/dcn/11/11-11-1296-03-00ah-potential-channelization-for-11ah.pptx)

That ppt tells 863-868,6MHz for Europe.  In France that is 25mW (like 
WiFi).  It is not forbidden.  So I guess it can work.

But I dont think running at 863MHz will save any much energy, instead of 
running at 2.4GHz.

It will offer a much lower bandwidth than WiFi, for much simpler 
applications (i.e. alarm on/off, window open/close rather than video 
stream at 11ad's 1GBps at 60GHz).  And because the amount of data 
transmitted is much lower that there will be energy savings.

In that sense, I dont think there is anything to do to modify IPv6 to 
work on it.  (and yes, IPv6 must work ok on 11ah, as it works on WiFi, 
and it is worth documenting in a document).

 >>> you can see potential channelization for different regions.
>>> Some of our concerns in study:
>>>
>>> 1) At the end of section 6, this text was written " For
>>> non-link-local addresses a 64-bit IID MAY be formed by utilizing
>>> the 48-bit MAC device address.  Random IID can be generated for
>>> 6LN using alternative methods such as
>>> [I-D.ietf-6man-default-iids]." Is this sufficient?
>>
>> I think that "MAY" is good - it is good to refer to any I-D or RFC
>> in this privacy space, to make the tracking based on MAC addresses
>> more difficult to attackers.  The default-iids draft is good, and
>> there is also RFC7217.
>>
>> Further along the lines of a "MAY" I would like to suggest that not
>> only utilisation of MAC be a "MAY" but also the 64bit length of an
>> IID be a MAY, let me explain why.
>>
>> I think link-local addresses are not necessarily an issue with the
>> /64 bit limit, because their prefix is a constant fe80.
>>
>> But the globally unique, and ULAs, addresses may have some issue if
>> auto- configured with SLAAC.
>>
>> Will an 802.11ah interface be built-in into a cellular phone,
>> smartphone? Because 802.11ah energy savings may be very relevant
>> for cellular phones more than for any other routers.
>
> [FDC] Indeed, the energy saving mechanisms are useful for battery
> operated devices like a Smartphone. Also connected sensors such as
> temperature sensors could be connected to internet through an
> 802.11ah link.

If you agree this is for a smartphone, it would be good to note that a 
smartphone can not get a shorter-than-64 prefix from a cellular 
operator, and as such can not send an RA containing a /64 on its 11ah 
interface - it will have to send a /65 in that RA.  Because of that an 
11ah sensor connecting to the 11ah interface of the smartphone and 
forming an IID of length 64 will lead to IPv6 address of length 129. 
That can not work.

Also, an 11ah sensor would like to be able to talk using IPv6 to its 
11b-only neighbor, both one the same hotspot emitted by a smartphone 
equipped of one single interface featuring all 11b/g/n/ac/ad/ah 
characteristics.  Right?

>> But cellular phones (smartphones) are not able to run
>> statelessautoconf/Ethernet on the 802.11ah interface, because the
>> interface ID is 64bit length.
>>
>> In that case, it may be possible to use an Interface ID of length
>> 48bit (the MAC address on 802.11ah).
>>
>
> [FDC] The 48bits MAC address can be converted to a 64bit format by
> standard means. I think if there is a need a Smartphone can implement
> all necessary procedures to work this out.

Yes, there is.

What I mean is to allow the smartphone to form an IID of length 48 out 
of the 48bit MAC address.  This will allow SLAAC to form 128bit IPv6 
addresses when the RA contains a prefix of length 65.

If the RA contains a prefix of length 65 and the IID is of length 64 
then the SLAAC will form addresses of length 129.

>>> 2) How to use 6CO option along with Router advertisements for
>>> compression context?
>>>
>>> 3) Section 8
>>
>> The section 8 is about HC.
>>
>> I would like to ask whether HC means to eliminate the IPv6 Base
>> Header and if yes then the subsequent question is whether we can
>> still consider this to be "IPv6 over..." when there is no IPv6.
>>
>> Because RFC2460 says that the IPv6 Base Header is mandatory.
>>
>
> [FDC] Please note that the proposed stack include IPv6 layer, what we
> propose is to compress its transport using 6LoWPAN.

It is strange to hear 'transport' because for me 'transport' is above IP 
not below it.  But be it.

>>> We would appreciate your comments and suggestion on this draft.
>>
>> I would to like to comment to ask whether you have packet dumps of
>> IPv6/802.11ah?  And wireshark dissectors?
>>
>
> [FDC] As far as we know, there are no existing devices in the market
> that implement 802.11ah to this date.

Ok, maybe it is a good start.  Let us hope for the best.

>> About the security considerations section: Is e2e IPsec security
>> still afforded even though an intermediary router must hold keys
>> for eliminated/reinserted IPv6 base header?
>>
>
> [FDC] Please note that there is no intermediary routers in 802.11ah.

Ok.

> However we believe that IPsec can be implemented in this kind of
> networks following
> [https://tools.ietf.org/html/draft-raza-6lowpan-ipsec-01]

I will comment separately on HC and end2end security.  BAsically, if the 
IPv6 base header is eliminated and reconstructed by some intermediary 
then there is a risk of attack unless the keys are shared with some 
entity in the network - that sharing breaks e2e security: one doesnt 
want to share keys with any intermediary (MiTM) than the other end of 
the communication.

Alex

>
>
>> Thanks,
>>
>> Alex
>>
>>>
>>> Thank you very much in advance,
>>>
>>> Felipe, Ines and Roberto
>>>
>>> --------------------------------------------------------
>>>
>>> A new version of I-D, draft-delcarpio-6lo-wlanah-00.txt has been
>>> successfully submitted by Maria Ines Robles and posted to the
>>> IETF repository.
>>>
>>> Name:		draft-delcarpio-6lo-wlanah Revision:	00 Title:
>> IPv6 over
>>> 802.11ah Document date:	2015-06-17 Group:		Individual
>> Submission
>>> Pages:		15
>>> URL:https://www.ietf.org/internet-drafts/draft-delcarpio-6lo-wlanah-00
>>>
>>>
.txt
>>>
>>>
>> Status:https://datatracker.ietf.org/doc/draft-delcarpio-6lo-wlanah/
>>>
>>
Htmlized:https://tools.ietf.org/html/draft-delcarpio-6lo-wlanah-00
>>>
>>>
>>> Abstract: IEEE 802.11 is an established Wireless LAN (WLAN)
>>> technology which provides radio connectivity to a wide range of
>>> devices.  The IEEE 802.11ah amendment defines a WLAN system
>>> operating at sub 1 GHz license-exempt bands designed to operate
>>> with low-rate/low-power consumption.  This amendment supports
>>> large number of stations and extends the radio coverage to
>>> several hundreds of meters.  This document describes how IPv6 is
>>> transported over 802.11ah using 6LoWPAN techniques.
>>>
>>> _______________________________________________ 6lo mailing list
>>> [e-mail] https://www.ietf.org/mailman/listinfo/6lo
>>>
>>>
>>
>> _______________________________________________ 6lo mailing list
>> [e-mail] https://www.ietf.org/mailman/listinfo/6lo
>
>