Re: [ipwave] IPWAVE Side Meeting

[Alexandre Petrescu <[e-mail]>]

Chris,

Le 05/12/2019 à 07:09, Chris Shen a écrit :
[...]

> 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.
> 
> 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.
> 
> 
> 
> On Wed, Dec 4, 2019 at 7:28 PM Alexandre Petrescu 
> <[e-mail] <mailto:[e-mail]>>
> wrote:
> 
> Hi Chris,
> 
> Le 04/12/2019 à 06:23, Chris Shen a écrit :
>> 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.
> 
> 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.
> 
>> 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?
> 
> 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 <[e-mail]
> <mailto:[e-mail]>
>> <mailto:[e-mail] <mailto:[e-mail]>>>
>> 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 
>> <[e-mail]
> <mailto:[e-mail]> 
> <mailto:[e-mail] 
> <mailto:[e-mail]>>>
>> 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 
>>> <[e-mail]
> <mailto:[e-mail]> <mailto:[e-mail] 
> <mailto:[e-mail]>>
>> <mailto:[e-mail]
> <mailto:[e-mail]> <mailto:[e-mail] 
> <mailto:[e-mail]>>>>
>> 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
>> [e-mail]
> <mailto:[e-mail]>
>> 
> <mailto:[e-mail] 
> <mailto:[e-mail]>>
>>> 
> <mailto:[e-mail] 
> <mailto:[e-mail]>
>> 
> <mailto:[e-mail] 
> <mailto:[e-mail]>>>.
>>> To post to this group, send email to 
>>> [e-mail]
> <mailto:[e-mail]>
>> <mailto:[e-mail]
> <mailto:[e-mail]>>
>>> <mailto:[e-mail]
> <mailto:[e-mail]>
>> <mailto:[e-mail]
> <mailto:[e-mail]>>>.
>>> 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:[phone] Email: [e-mail]
>>> <mailto:[e-mail]>
> <mailto:[e-mail] <mailto:[e-mail]>>
>>> <mailto:[e-mail] <mailto:[e-mail]>
> <mailto:[e-mail] <mailto:[e-mail]>>>
>>> 
>>> _______________________________________________ its mailing list 
>>> [e-mail] <mailto:[e-mail]>
> <mailto:[e-mail] <mailto:[e-mail]>>
>>> 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:[phone] Email:
>> [e-mail] <mailto:[e-mail]> 
>> <mailto:[e-mail] <mailto:[e-mail]>>
>> 
>> 
>> 
>> -- 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:[phone] Email:
>> [e-mail] <mailto:[e-mail]> 
>> <mailto:[e-mail] <mailto:[e-mail]>>
> 
> 
> 
> -- 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:[phone] Email:
> [e-mail] <mailto:[e-mail]>