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

[Felipe Del Carpio <[e-mail]>]

Dear Alexandru, 

Thank you very much, I appreciate your comments. Please see my answers inline with mark [FDC].

Best regards, 
Felipe

> -----Original Message-----
> From: Alexandru Petrescu [mailto:[e-mail]]
> Sent: Thursday, June 18, 2015 3:35 PM
> To: Felipe Del Carpio; [e-mail]
> Cc: Roberto Morabito; MARIA INES ROBLES
> Subject: Re: [6lo] New I-D draft-delcarpio-6lo-wlanah-00.txt
> 
> 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).

[FDC] Thanks for the comments. I haven't study much the V2V  amendment yet.
> 
> > 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-ch
> > annelization-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.
[FDC] Indeed lower frequencies do not alone reduce battery consumption. However, the propagation
at lower frequencies for a radio signal is better meaning that less transmit power at the device's antenna
 is needed to yield the same distance/range/coverage. 
The 802.11ah saves energy by allowing devices to sleep (doze) as mentioned in the draft. These techniques 
which allow devices to sleep are key power saving mechanisms.

> 
> 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.
[FDC] High bitrate systems e.g. 802.11ac/ad may be over-dimensioned for simpler applications. Here, allowing
devices to sleep save energy.

> 
> 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).
[FDC] In the draft it is clearly stated that LLC allows 802.11ah to use IPv6 by default. You have a point in the lower bitrate of 802.11ah.
Actually, this makes 802.11ah a perfect candidate for IPv6 header compression.
If packets are expected to be small, why we would like to send a large IPv6/UDP/whatever headers?. We want IPv6 
enabled devices, but with compressed headers.

> 
>  >>> 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.
[FDC] We need to study further this point. Do you have references that could enlighten us more with this respect? Maybe,
implementation documentation?

> 
> 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?
> 
[FDC] I think IPv6 will be this interface. 11ah talks IPv6 and other 11b device in the subnet talks IPv6, then they interoperate.
We are discussing the 6LoWPAN which is the adaptation layer before IPv6 in 11ah devices. 

> >> 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.
[FDC] We need to study further this point as mentioned above.

> 
> >>> 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.
> 
[FDC] Thank you for your comments. They are very welcomed.

> 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
> >
> >