Subject: Re: [ipwave] IPWAVE Side Meeting

From: Chris Shen <[email-masked]>
Date: Wed, 4 Dec 2019 14:23:49 +0900

Hi Alex,

Here I share wireshark packet dump file from the experiment of the
hackathon.
These packet information were collected during webcam streaming between two
DSRC-enabled laptops.

If you have any questions, please let me know.

BTW, when you setup your experiment platform, how did the IPv6 neighbor
discovery work?
Was it automatically running, or you need to manually configure it?

Thanks!
Chris.

On Wed, Nov 27, 2019 at 6:41 PM Chris Shen <[email-masked]> wrote:

> Hi Alex,
>
> I answer your questions as follows:
>
> - is the manual available? ("Made a new manual for running OCB mode")
>>
> Yes, it is in the following github link:
>
> https://github.com/ipwave-hackathon-ietf/ipwave-hackathon-ietf-106/blob/master/IPWAVE-Manual-Hackathon-IETF106-v0.2.pdf
>
>
>
>> - have you made a patch file?
>>
> I didn't make patch file for this implementation.
> Based on existing resources, there are some patch work to enable
> OCB mode in the Linux kernel.
> One of them is much concrete, which was made by Czech Technical University
> in Prague and Volkswagen.
> The resource link is as follows:
> https://ctu-iig.github.io/802.11p-linux/
> But when I follow their instructions to configure OCB mode, there
> are some unclear steps and some compiling errors coming out,
> so I have modified the Makefile and explored other ways to configure
> OCB mode, which is shown in the manual.
>
>
>
>> - did you use a notion of QoS?  For example, can you send us a wireshark
>
>    packet dump made in monitor mode, of the IPv6 packets used for video
>>    streaming between the two laptops?  These packets have 802.11 QoS Data
>>    headers or just 802.11 Data headers?
>>
> I didn't use QoS. For the current webcam streaming, I use gst-launch
> from Gstreamer. This gst-launch uses UDP and RTP to stream webcam.
>
> I checked packet dump, there is no QoS information, so I believe the
> packets
> just use 802.11 Data headers.
> I will send you the packet dump later, since I didn't save them.
>
>
>
>> - the wifi card wilocity is on USB or is it internal to the laptop?
>
> For the current test, we replaced the original wifi card inside a laptop
> with an Athero wifi card using ath9k driver. This wifi card uses PCIe-mini
> interface to connect with the laptop.
> We also use the laptop internal antennas for 5.9GHz band. Initially,
> we are not sure if the antennas of the testing laptop can support 5.9GHz
> band, so we connect the wifi card with external antennas that support
> 5.9GHz.
> After testing, we found that the laptop internal antennas can also support
> 5.9GHz band, so we just use them.
> If you have a USB dongle that has PCIe-mini interface, I believe an
> Atheros wifi
> card can work as well, but you need to have external antennas to connect
> with
> the wifi card on the USB dongle.
>
> Thanks!
> Chris.
>
>
> On Tue, Nov 26, 2019 at 9:56 PM Alexandre Petrescu <
> [email-masked]> wrote:
>
>> Hi Chris,
>>
>> With respect to the Hackathon slides, my colleague and I would like to
>> ask you:
>>
>> - is the manual available? ("Made a new manual for running OCB mode")
>> - have you made a patch file?
>> - did you use a notion of QoS?  For example, can you send us a wireshark
>>    packet dump made in monitor mode, of the IPv6 packets used for video
>>    streaming between the two laptops?  These packets have 802.11 QoS Data
>>    headers or just 802.11 Data headers?
>> - the wifi card wilocity is on USB or is it internal to the laptop?
>>
>> Yours,
>>
>> Alex
>>
>> Le 21/11/2019 à 08:13, Chris Shen a écrit :
>> > Hi its,
>> >
>> > Here I share side meeting slides for IPWAVE WG.
>> >
>> > Please join us to give your opinions and suggestions about the work in
>> > IPWAVE WG.
>> >
>> > We really need your input! ^_^
>> >
>> > Thanks!
>> > Chris.
>> >
>> >
>> >
>> > On Thu, Nov 21, 2019 at 11:12 AM Mr. Jaehoon Paul Jeong
>> > <[email-masked] <mailto:[email-masked]>> wrote:
>> >
>> >     Hi IPWAVE WG,
>> >
>> >     There will be a side meeting for I2NSF WG's next steps from 3:30PM
>> >     to 4:30PM today
>> >     at Bras Basah.
>> >     https://datatracker.ietf.
>> .org/meeting/106/floor-plan?room=bras-basah#raffles-city-convention-center
>> >     <
>> https://datatracker.ietf.org/meeting/106/floor-plan?room=bras-basah#raffles-city-convention-center
>> >
>> >
>> >
>> >     The agenda for IPWAVE side meeting is as follows:
>> >
>> >     - IPWAVE Hackathon Project (Yiwen Chris Shen, 5 min)
>> >     - IPWAVE Problem Statement Draft (Jaehoon Paul Jeong, 5 min)
>> >     - Vehicular Neighbor Discovery Draft (Yiwen Chris Shen, 5 min)
>> >     - Vehicular Mobility Management Draft (Yiwen Chris Shen, 5 min)
>> >     - Security and Privacy Draft (Jaehoon Paul Jeong, 5 min)
>> >     - Context-Aware Navigator Draft (Yiwen Chris Shen, 5 min)
>> >     - Open Discussion for IPWAVE WG Progress (30 min)
>> >
>> >     The main purpose of this side meeting is to share the progress of
>> >     IPWAVE PS draft and the IPWAVE hackathon project using the video
>> >     delivery in the Linux system for IPv6 over IEEE 802.11-OCB.
>> >
>> >     I would like to explain the status of our WG and the importance of
>> >     the IPWAVE PS draft for the next step of our WG.
>> >
>> >     Welcome your engagement and feedback.
>> >
>> >     Thanks.
>> >
>> >     Best Regards,
>> >     Paul
>> >
>> >     --
>> >     You received this message because you are subscribed to the Google
>> >     Groups "skku-iotlab-members" group.
>> >     To unsubscribe from this group and stop receiving emails from it,
>> >     send an email to [email-masked]
>> >     <mailto:[email-masked]>.
>> >     To post to this group, send email to
>> >     [email-masked]
>> >     <mailto:[email-masked]>.
>> >     To view this discussion on the web visit
>> >
>> https://groups.google.com/d/msgid/skku-iotlab-members/CAPK2DeyAWKbA0jZmpSdvJVwG3RsqVd5c15r-wxTjEsH3uGbk0w%40mail.gmail.com
>> >     <
>> https://groups.google.com/d/msgid/skku-iotlab-members/CAPK2DeyAWKbA0jZmpSdvJVwG3RsqVd5c15r-wxTjEsH3uGbk0w%40mail.gmail.com?utm_medium=email&utm_source=footer
>> >.
>> >     For more options, visit https://groups.google.com/d/optout.
>> >
>> >
>> >
>> > --
>> > Yiwen (Chris) Shen, Ph.D. Candidate
>> >
>> > Homepage: https://chrisshen.github.io
>> > IoT Lab: _http://iotlab.skku.edu <http://iotlab.skku.edu/>_
>> > Sungkyunkwan University, Suwon, South Korea
>> > Mobile:+82-(0)10-6871-8103
>> > Email: [email-masked]
>> > <mailto:[email-masked]>
>> >
>> > _______________________________________________
>> > its mailing list
>> > [email-masked]
>> > https://www.ietf.org/mailman/listinfo/its
>> >
>>
>
>
> --
> Yiwen (Chris) Shen, Ph.D. Candidate
>
> Homepage: https://chrisshen.github.io
> IoT Lab: *http://iotlab.skku.edu <http://iotlab.skku.edu/>*
> Sungkyunkwan University, Suwon, South Korea
> Mobile:+82-(0)10-6871-8103
> Email: [email-masked]
>

-- 
Yiwen (Chris) Shen, Ph.D. Candidate

Homepage: https://chrisshen.github.io
IoT Lab: *http://iotlab.skku.edu <http://iotlab.skku.edu/>*
Sungkyunkwan University, Suwon, South Korea
Mobile:+82-(0)10-6871-8103
Email: [email-masked]

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 4 Dec 2019 11:28:49 +0100

Hi Chris,

Le 04/12/2019 à 06:23, Chris Shen a écrit :
> These packet information were collected during webcam streaming between 
> two DSRC-enabled laptops.

Thank you for the packet dumps.

In the dumps I can see indeed UDP/IPv6 packets, supposedly for video stream.

However, I can not see the link layer headers, like 802.11 headers; I 
only see EthernetII headers.  The link layer headers can be captured in 
monitor mode, not in normal mode.  For that, there might be a need to 
create a special interface (like wlan0 or so) with a command (maybe iw) 
and capture on that interface, instead of capturing on the normal interface.

> Was it automatically running, or you need to manually configure it?

ND worked fine.

We do configure manually a few things for the initial connectivity: the 
channels, the link-local addresses and some routing table entries.

'ND' has many parts: DAD, SLAAC, NS/NA, and others.

I am not sure which part of ND you doubt it might not work.

The part that I doubt very much is the following: when the card comes up 
it must send an NA for its own address, to a multicast group;  but has 
this router, and the others, joined that group already? (MLD REPORT), or 
probably not.  If yes, then that initial NA has the right effect.  If 
not (the group is not yet formed), then the effect of that NA is lost - 
another computer might form same LL address and DAD be nullified.

In our settings, such a situation could be provoked: start a car remote 
from this car, and then bring it closer.  But we never faced it, because 
we always start the cars at the same time and place.

Another part of ND that might not work as appropriate is the use of RIO 
in the RA.  We rely on these RIOs to establish IP paths between cars. 
These some times was failing in our initial tests, but we improved it, 
with some pre-learned manually configured data, and other 
pre-conditions.  We wrote software to achieve that.

SO, I am not sure which ND part you think about.

What kind of ND proble do you foresee?

Alex

> 
> 
> Thanks!
> Chris.
> 
> 
> On Wed, Nov 27, 2019 at 6:41 PM Chris Shen <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Hi Alex,
> 
>     band, so we connect the wifi card with external antennas that
>     support 5.9GHz.
>     card can work as well, but you need to have external antennas to
>     connect with
>     On Tue, Nov 26, 2019 at 9:56 PM Alexandre Petrescu
>     <[email-masked] <mailto:[email-masked]>>
>     wrote:
> 
>         Hi Chris,
> 
>          > <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>
>         wrote:
>          >
>          >     Hi IPWAVE WG,
>          >
>         https://datatracker.ietf..org/meeting/106/floor-plan?room=bras-basah#raffles-city-convention-center
>          >   
>           <https://datatracker.ietf.org/meeting/106/floor-plan?room=bras-basah#raffles-city-convention-center>
>          >
>          >
>          >     send an email to
>         [email-masked]
>         <mailto:[email-masked]>
>          >     <mailto:[email-masked]
>         <mailto:[email-masked]>>.
>         <mailto:[email-masked]>
>          >     <mailto:[email-masked]
>         <mailto:[email-masked]>>.
>           <https://groups.google.com/d/msgid/skku-iotlab-members/CAPK2DeyAWKbA0jZmpSdvJVwG3RsqVd5c15r-wxTjEsH3uGbk0w%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>          > Email: [email-masked] <mailto:[email-masked]>
>          > <mailto:[email-masked] <mailto:[email-masked]>>
>          >
>          > [email-masked] <mailto:[email-masked]>

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 4 Dec 2019 12:04:18 +0100

I would like to make an additional remark, even though it might not be 
targeted to IPWAVE in particular, but more generally related to IPv6 
experimentation in general.

The 2001:db8:: addresses should not be used on computers, but on paper.

In order to use something quickly on computers, I rather suggest 
addresses like 1::1 and 1::2.  Other purists may suggest the ULA 
prefixes, like fd00::1 and fd00::2.

But certainly not the 2001:db8::, which is called the 'Documentation 
Prefix' for a reason.

Alex

Le 04/12/2019 à 11:28, Alexandre Petrescu a écrit :
>> These packet information were collected during webcam streaming 
>> between two DSRC-enabled laptops.
> 
>> BTW, when you setup your experiment platform, how did the IPv6 
>> neighbor discovery work?
>>          > Hi its,
>>          >
>>          > Here I share side meeting slides for IPWAVE WG.
>>          >
>>          > Please join us to give your opinions and suggestions about
>>         the work in
>>          > IPWAVE WG.
>>          >
>>          > We really need your input! ^_^
>>          >
>>          > Thanks!
>>          > Chris.
>>          >
>>          >
>>          >
>>          > On Thu, Nov 21, 2019 at 11:12 AM Mr. Jaehoon Paul Jeong
>>          > <[email-masked] <mailto:[email-masked]>
>>          >
>>          >     Hi IPWAVE WG,
>>          >
>>          >     There will be a side meeting for I2NSF WG's next steps
>>         from 3:30PM
>>          >     to 4:30PM today
>>          >     at Bras Basah.
>>          >
>>         
>>          >          
>>          >
>>          >
>>          >     The agenda for IPWAVE side meeting is as follows:
>>          >
>>          >     - IPWAVE Hackathon Project (Yiwen Chris Shen, 5 min)
>>          >     - IPWAVE Problem Statement Draft (Jaehoon Paul Jeong, 5 
>> min)
>>          >     - Vehicular Neighbor Discovery Draft (Yiwen Chris Shen, 5
>>         min)
>>          >     - Vehicular Mobility Management Draft (Yiwen Chris Shen,
>>         5 min)
>>          >     - Security and Privacy Draft (Jaehoon Paul Jeong, 5 min)
>>          >     - Context-Aware Navigator Draft (Yiwen Chris Shen, 5 min)
>>          >     - Open Discussion for IPWAVE WG Progress (30 min)
>>          >
>>          >     The main purpose of this side meeting is to share the
>>         progress of
>>          >     IPWAVE PS draft and the IPWAVE hackathon project using
>>         the video
>>          >     delivery in the Linux system for IPv6 over IEEE 
>> 802.11-OCB.
>>          >
>>          >     I would like to explain the status of our WG and the
>>         importance of
>>          >     the IPWAVE PS draft for the next step of our WG.
>>          >
>>          >     Welcome your engagement and feedback.
>>          >
>>          >     Thanks.
>>          >
>>          >     Best Regards,
>>          >     Paul
>>          >
>>          >     --
>>          >     You received this message because you are subscribed to
>>         the Google
>>          >     Groups "skku-iotlab-members" group.
>>          >     To unsubscribe from this group and stop receiving emails
>>         from it,
>>          >     send an email to
>>          >     <mailto:[email-masked]
>>          >     To post to this group, send email to
>>          > [email-masked]
>>          >     <mailto:[email-masked]
>>          >     To view this discussion on the web visit
>>          >
>>         
>>          >          
>>          >     For more options, visit 
>> https://groups.google.com/d/optout.
>>          >
>>          >
>>          >
>>          > --
>>          > Yiwen (Chris) Shen, Ph.D. Candidate
>>          >
>>          > Homepage: https://chrisshen.github.io
>>          > IoT Lab: _http://iotlab.skku.edu <http://iotlab.skku.edu/>_
>>          > Sungkyunkwan University, Suwon, South Korea
>>          > Mobile:+82-(0)10-6871-8103
>>          > Email: [email-masked] <mailto:[email-masked]>
>>          > <mailto:[email-masked] <mailto:[email-masked]>>
>>          >
>>          > _______________________________________________
>>          > its mailing list
>>          > [email-masked] <mailto:[email-masked]>
>>          > https://www.ietf.org/mailman/listinfo/its
>>          >
>>
>>
>>
>>     --     Yiwen (Chris) Shen, Ph.D. Candidate
>>

---

From: Chris Shen <[email-masked]>
Date: Thu, 5 Dec 2019 15:09:34 +0900

Hi Alex,

Thanks for the information.

I will configure a monitor mode to capture the packet information again.

For the ND, when we turn the OCB mode on, the IPv6 ND was not automatically
running.
Here what I mean is the SLAAC (link-local address) is not autoconfigured by
EUI-64 or other methods.
Because of no link-local address, the NS/NA were not sent and neighbor
cache could not
been built either.

What I did is that I manually configured an IPv6 address for the interface,
and then the link-local address was automatically generated based on MAC
address. However,
the NS/NA messages were still not transmitted, so I manually added a
neighbor for the
interface. After this step, the interface started periodically sending NS
messages to
the neighbor what I added, which to make sure the neighbor is alive.

Since there is no router in our experiment, the DAD process was not
triggered.

Regarding the 2001:db8:: address, I just selected it based on our drafts. I
may select other IPv6 addresses for experiments in the
future. Thanks for the information.

Thanks!
Chris.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 5 Dec 2019 16:45:57 +0100

Hi Chris,

Thank you for the detail about how ND messages are missing when OCB mode
is set, and that necessitates manually setting an IP address first.

I would like to ask you a clarification question: if you set the OCB
mode and then put the interface up (ifconfig eth0 up), without manually
adding an address, will it form by itself a link-local address?  Or no?

The sequence that works in some places is this:
- iw command to set up the OCB mode and channel
- ifconfig eth0 up
After these two commands, the interface self-forms an IPv6 link-local
address and then sends NA for it.
If, on the other hand, we dont do 'ifconfig eth0 up' then there is
indeed no IPv6 link-local address on it, and no NA.

I am asking this clarification question in order to better identify the
ND issues.

Alex

Le 05/12/2019 à 07:09, Chris Shen a écrit :
> For the ND, when we turn the OCB mode on, the IPv6 ND was not 
> automatically running. Here what I mean is the SLAAC (link-local
> address) is not autoconfigured by EUI-64 or other methods. Because of
> no link-local address, the NS/NA were not sent and neighbor cache
> could not been built either.
> 
> What I did is that I manually configured an IPv6 address for the
> interface, and then the link-local address was automatically
> generated based on MAC address. However, the NS/NA messages were
> still not transmitted, so I manually added a neighbor for the 
> interface. After this step, the interface started periodically
> sending NS messages to the neighbor what I added, which to make sure
> the neighbor is alive.
> 
> Regarding the 2001:db8:: address, I just selected it based on our 
> drafts. I may select other IPv6 addresses for experiments in the 
> Thanks! Chris.
> On Wed, Dec 4, 2019 at 7:28 PM Alexandre Petrescu 
>> hackathon. These packet information were collected during webcam
>> streaming
> between
> However, I can not see the link layer headers, like 802.11 headers;
> I only see EthernetII headers.  The link layer headers can be
> captured in monitor mode, not in normal mode.  For that, there might
> be a need to create a special interface (like wlan0 or so) with a
> command (maybe iw) and capture on that interface, instead of
> capturing on the normal interface.
> 
> neighbor
>> discovery work? Was it automatically running, or you need to
>> manually configure it?
> 
> ND worked fine.
> 
> We do configure manually a few things for the initial connectivity:
> the channels, the link-local addresses and some routing table
> entries.
> 
> The part that I doubt very much is the following: when the card comes
> up it must send an NA for its own address, to a multicast group;  but
> has this router, and the others, joined that group already? (MLD 
> REPORT), or probably not.  If yes, then that initial NA has the right
> effect.  If not (the group is not yet formed), then the effect of
> that NA is lost - another computer might form same LL address and DAD
> be nullified.
> 
> In our settings, such a situation could be provoked: start a car
> remote from this car, and then bring it closer.  But we never faced
> it, because we always start the cars at the same time and place.
> 
> Another part of ND that might not work as appropriate is the use of
> RIO in the RA.  We rely on these RIOs to establish IP paths between
> cars. These some times was failing in our initial tests, but we
> improved it, with some pre-learned manually configured data, and
> other pre-conditions.  We wrote software to achieve that.
> 
>> Thanks! Chris.
> <mailto:[email-masked]>
>> <mailto:[email-masked] <mailto:[email-masked]>>>
>> wrote:
>> 
>> Hi Alex,
>> 
>> - is the manual available? ("Made a new manual for
> running OCB
>> mode")
>> 
>> I didn't make patch file for this implementation. Based on existing
>> resources, there are some patch work to enable OCB mode in the
>> Linux kernel. One of them is much concrete, which was made by Czech
>> Technical University in Prague and Volkswagen. The resource link is
>> as follows: https://ctu-iig.github.io/802.11p-linux/ But when I
>> follow their instructions to configure OCB mode, there are some
>> unclear steps and some compiling errors coming out, so I have
>> modified the Makefile and explored other ways to
> configure
>> - did you use a notion of QoS?  For example, can you send
> us a
>> wireshark
>> 
>> packet dump made in monitor mode, of the IPv6 packets
> used
>> for video streaming between the two laptops?  These packets have 
>> 802.11 QoS Data headers or just 802.11 Data headers?
>> 
>> packets just use 802.11 Data headers. I will send you the packet
>> dump later, since I didn't save them.
>> 
>> For the current test, we replaced the original wifi card inside a 
>> laptop with an Athero wifi card using ath9k driver. This wifi card
>> uses PCIe-mini interface to connect with the laptop. We also use
>> the laptop internal antennas for 5.9GHz band.
> Initially,
>> we are not sure if the antennas of the testing laptop can support 
>> 5.9GHz band, so we connect the wifi card with external antennas
>> that support 5.9GHz. After testing, we found that the laptop
>> internal antennas can
> also
>> support 5.9GHz band, so we just use them. If you have a USB dongle
>> that has PCIe-mini interface, I
> believe an
>> Atheros wifi card can work as well, but you need to have external
>> antennas to connect with the wifi card on the USB dongle.
>> 
>> Thanks! Chris.
>> 
>> 
>> <[email-masked]
> <mailto:[email-masked]> 
> <mailto:[email-masked] 
> <mailto:[email-masked]>>>
>> wrote:
>> 
>> Hi Chris,
>> 
>> With respect to the Hackathon slides, my colleague and I
> would
>> like to ask you:
>> 
>> - is the manual available? ("Made a new manual for
> running OCB
>> mode") - have you made a patch file? - did you use a notion of QoS?
>> For example, can you send
> us a
>> wireshark packet dump made in monitor mode, of the IPv6 packets
> used
>> for video streaming between the two laptops?  These packets have 
>> 802.11 QoS Data headers or just 802.11 Data headers? - the wifi
>> card wilocity is on USB or is it internal to
> the laptop?
>> 
>> Yours,
>> 
>> Alex
>> 
>>> Thanks! Chris.
>>> <[email-masked]
> <mailto:[email-masked]> <mailto:[email-masked] 
> <mailto:[email-masked]>>
>> <mailto:[email-masked]
> <mailto:[email-masked]> <mailto:[email-masked] 
> <mailto:[email-masked]>>>>
>> wrote:
>>> 
>>> Hi IPWAVE WG,
>>> 
>>> to 4:30PM today at Bras Basah.
>>> 
>> 
>>> - IPWAVE Hackathon Project (Yiwen Chris Shen, 5 min) - IPWAVE
>>> Problem Statement Draft (Jaehoon Paul
> Jeong, 5 min)
>>> - Vehicular Neighbor Discovery Draft (Yiwen Chris
> Shen, 5
>> min)
>>> - Vehicular Mobility Management Draft (Yiwen Chris
> Shen,
>> 5 min)
>>> Best Regards, Paul
>>> -- You received this message because you are
> subscribed to
>> the Google
>>> Groups "skku-iotlab-members" group. To unsubscribe from this
>>> group and stop receiving
> emails
>> from it,
>>> send an email to
> <mailto:[email-masked] 
> <mailto:[email-masked]>>
>>> 
> <mailto:[email-masked] 
> <mailto:[email-masked]>>>.
> <mailto:[email-masked]>>
> <mailto:[email-masked]>>>.
>>> Homepage: https://chrisshen.github.io IoT Lab:
>>> _http://iotlab.skku.edu
> <http://iotlab.skku.edu/>_
>>> Mobile:+82-(0)10-6871-8103 Email: [email-masked]
>>> <mailto:[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>>>
>>> 
>>> _______________________________________________ its mailing list 
> <mailto:[email-masked] <mailto:[email-masked]>>
>> Homepage: https://chrisshen.github.io IoT Lab:
>> _http://iotlab.skku.edu <http://iotlab.skku.edu/>_ Sungkyunkwan
>> University, Suwon, South Korea Mobile:+82-(0)10-6871-8103 Email:
>> [email-masked] <mailto:[email-masked]> 
>> Homepage: https://chrisshen.github.io IoT Lab:
>> _http://iotlab.skku.edu <http://iotlab.skku.edu/>_ Sungkyunkwan
>> University, Suwon, South Korea Mobile:+82-(0)10-6871-8103 Email:
>> [email-masked] <mailto:[email-masked]> 
> Homepage: https://chrisshen.github.io IoT Lab:
> _http://iotlab.skku.edu <http://iotlab.skku.edu/>_ Sungkyunkwan
> University, Suwon, South Korea Mobile:+82-(0)10-6871-8103 Email:
> [email-masked] <mailto:[email-masked]>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 12 Dec 2019 15:05:44 +0100

Chris,

[...]

> Here what I mean is the SLAAC (link-local address) is not
> autoconfigured by EUI-64 or other methods.

I think I have seen this problem elsewhere as well.  One puts the
interface up and there is no link-local address on it.

I wonder how do you think one could proceed with this problem?

Which solution do you think a solution might exist for this problem?

To me, the problem stems from the fact that RFC4291 mandates that every
interface must have at least one link-local address:
> All interfaces are required to have at least one Link-Local unicast 
> address (see Section 2.8 for additional required addresses).

Some computers do not form a link-local address when the interface is 
put up.

That could be because of a software glitch: the programmer simply forgot 
to implement it.  So we should remind her.

Or it could be a more complex problem:

Maybe the programmer is fed up with too many specifications, sometimes 
contradictory, about how to form a link-local address (RFC2464 with 
EUI-64 IID, RFC7217 with semantically opaque IIDs, fixed length vs 
not-specified length, stable vs changing in time, etc.)

Maybe the interface could not form a link-local address because it 
thinks that if tried, the lack of reception of NA (for DAD) might not 
mean somebody is really absent; because OCB mode has not a delimited 
link, and a presumed owner of that address would be absent at a given 
time, so impossible to respond to DAD.

There might be solutions to this problem that one might imagine:
- clarify the specifications; a new spec would tell the right thing to
   do.
- form a link-local address out of an identifier that is required by
   legislation to be public, and not from the MAC address; in this way
   the user would not fear privacy concerns for this LL address.
- distribute link-local addresses by DHCPv6, by modifying DHCPv6 to
   accept working with the unspecified src address (::).

Others?

Alex

> Because of no link-local address, the NS/NA were not sent and
> neighbor cache could not been built either.
>