Subject: Re: [ipwave] Intdir early review of draft-ietf-ipwave-ipv6-over-80211ocb-34

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 5 Apr 2019 15:09:18 +0000

Dear all;

As promised I put together some words on using IPv6 ND and then RFC 8505 for OCB. Please find attached early text. This could become a section 4.7.
Note that RFC 8505 enables a DAD operation for both link local and global addresses, the associated global prefix being owned by either a car or a RSU. RSUs connected to the internet can advertise a default router preference to indicate they are willing to relay packets for global addresses.
The attached text impacts other sections in particular the discussion on global addresses which is somehow avoided in the current draft and could be reintroduced.

Comments welcome : )

Pascal

From: Pascal Thubert (pthubert)
Sent: jeudi 28 mars 2019 11:29
To: Alexandre Petrescu <[email-masked]>
Cc: [email-masked]
Subject: Re: Intdir early review of draft-ietf-ipwave-ipv6-over-80211ocb-34

Yes Alex. Also as an offer to help...

Regards,

Pascal

Le 28 mars 2019 à 11:08, Alexandre Petrescu <[email-masked]<mailto:[email-masked]>> a écrit :

Pascal,

Should we treat these two reviews (iotdir and intdir reviews) as just one?

The contents appear to me to be the same.

Alex
Le 04/03/2019 à 12:24, Pascal Thubert a écrit :

Reviewer: Pascal Thubert

Review result: Not Ready

Reviewer: Pascal Thubert

Review result: Not ready. Need to clarify IEEE relationship, IOW which SDO

defines the use of L2 fields, what this spec enforces vs. recognizes as being

used that way based on IEEE work. The use of IPv6 ND requires a lot more

thoughts, recommendation to use 6LoWPAN ND. The definition of a subnet is

unclear. It seems that RSUs would have prefixes but that is not discussed.

I am an assigned INT and IOT directorates reviewer for <

draft-ietf-ipwave-ipv6-over-80211ocb-34 >. These comments were written

primarily for the benefit of the Internet Area Directors. Document editors and

shepherd(s) should treat these comments just like they would treat comments

from any other IETF contributors and resolve them along with any other Last

Call comments that have been received. For more details on the INT Directorate,

see https://datatracker.ietf.org/group/intdir/about/

Majors issues

-----------------

“

o  Exceptions due to different operation of IPv6 network layer on

      802.11 than on Ethernet.

“

Is this doc scoped to OCB or 802.11 in general? Is there an expectation that an

implementer of IPv6 over Wi-Fi refers to this doc? Spelled as above, it seems

that you are defining the LLC. Figure 1 shows the proposed adaptation layer as

IEEE LLC work. Who defines those fields, IETF or IEEE, or mixed? Who defines

their use? If this spec defines a new LLC header (vs. how to use an IEEE field)

 then it should be very clear, and the newly defined fields should be isolated

from IEEE fields.

"

   The IPv6 packet transmitted on 802.11-OCB MUST be immediately

   preceded by a Logical Link Control (LLC) header and an 802.11 header.

"

Is there anything new or specific to OCB vs. classical 802.11 operations?

If/when this is echoing the IEEE specs then this text should not use uppercase

but say something like: 'Per IEEE Std 802.11, the IPv6 packet transmitted on

802.11-OCB is immediately  preceded by a Logical Link Control (LLC) header and

an 802.11 header ...'

different things? Why define both?

"   An 'adaptation' layer is inserted between a MAC layer and the

   Networking layer.  This is used to transform some parameters between

   their form expected by the IP stack and the form provided by the MAC

   layer.

"

Is this different from what an AP does when it bridges Wi-Fi to Ethernet? Is

this IETF business?

"

   The Receiver and Transmitter Address fields in the 802.11 header MUST

   contain the same values as the Destination and the Source Address

   fields in the Ethernet II Header, respectively.

"

Same,  this is IEEE game isn't it?

"

Solutions for these problems SHOULD

   consider the OCB mode of operation.

"

This is not specific enough to be actionable. I suggest to remove this sentence.

It would be of interest for the people defining those solutions to understand

the specific needs of OCB vs. Wi Fi, but I do not see text about that.

"

The method of forming IIDs

   described in section 4 of [RFC2464] MAY be used during transition

   time.

"

Contradicts section 4.3 that says

"

Among these types of

   addresses only the IPv6 link-local addresses MAY be formed using an

   EUI-64 identifier.

"

"

This

   subnet MUST use at least the link-local prefix fe80::/10 and the

   interfaces MUST be assigned IPv6 addresses of type link-local.

"

If this is conforming IPv6 then the MUST is not needed.

"

   A subnet is formed by the external 802.11-OCB interfaces of vehicles

   that are in close range (not by their in-vehicle interfaces).

"

Is the definition transitive? Do we really get a subnet?

 A is close to  B who is close to C .... to Z, makes Paris one subnet! Are you

 talking about a link, rather?

"

   The Neighbor Discovery protocol (ND) [RFC4861] MUST be used over

   802.11-OCB links.

"

IPv6 ND is not suited for a non-broadcast network. How does DAD work?

Maybe you could consider RFC 6775 / RFC 8505 instead.

"

In the moment the MAC address is changed

   on an 802.11-OCB interface all the Interface Identifiers of IPv6

   addresses assigned to that interface MUST change.

"

Why is that? This is unexpected, and hopefully wrong.

Minor issues

---------------

"   OCB (outside the context of a basic service set - BSS): A mode of

   operation in which a STA is not a member of a BSS and does not

   utilize IEEE Std 802.11 authentication, association, or data

   confidentiality.

   802.11-OCB: mode specified in IEEE Std 802.11-2016 when the MIB

   attribute dot11OCBActivited is true.  Note: compliance with standards

   and regulations set in different countries when using the 5.9GHz

   frequency band is required.

"

Are these 2 different things?

"

Among these types of

 addresses only the IPv6 link-local addresses MAY be formed using an

  EUI-64 identifier.

"

This text should not be in a LL specific section since it deals with the other

addresses. Maybe rename the section to "addressing" or something?

"

   For privacy, the link-local address MAY be formed according to the

   mechanisms described in Section 5.2.

"

The MAY is not helpful. I suggest to remove the sentence that does not bring

value vs. 5.2

Could you make sections 4.3 and 4.5 contiguous?

"

If semantically

   opaque Interface Identifiers are needed, a potential method for

   generating semantically opaque Interface Identifiers with IPv6

   Stateless Address Autoconfiguration is given in [RFC7217].

   Semantically opaque Interface Identifiers, instead of meaningful

   Interface Identifiers derived from a valid and meaningful MAC address

   ([RFC2464], section 4), MAY be needed in order to avoid certain

   privacy risks.

...

   In order to avoid these risks, opaque Interface Identifiers MAY be

   formed according to rules described in [RFC7217].  These opaque

   Interface Identifiers are formed starting from identifiers different

   than the MAC addresses, and from cryptographically strong material.

   Thus, privacy sensitive information is absent from Interface IDs, and

   it is impossible to calculate the initial value from which the

   Interface ID was calculated.

"

Duplicate and mis ordered text, isn't it?

" For this reason, an attacker may realize many

   attacks on privacy.

"

Do we attack privacy? Maybe say that privacy is a real concern, and maybe move

that text to security section?

"

   The way Interface Identifiers are used MAY involve risks to privacy,

   as described in Section 5.1.

"

Also duplicate

Nits

------

"

   IP packets MUST be transmitted over 802.11-OCB media as QoS Data

   frames whose format is specified in IEEE Std 802.11.

"

Please add link to the reference

" the 802.11 hidden node"

Do not use 802.11 standalone (multiple occurrences).

=> "the IEEE Std. 802.11 [ ref ] hidden node", or just "the hidden terminal".

BCP 14 text:

Suggest to use this text:

“

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and

   "OPTIONAL" in this document are to be interpreted as described in

   https://tools.ietf.org/html/bcp14 https://tools.ietf.org/html/bcp14

   [https://tools.ietf.org/html/rfc2119][RFC8174] when, and only when, they

   appear in all capitals, as shown here.

“

All the best

Pascal

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 5 Apr 2019 19:53:19 +0200

PAscal,
Thank you for the text.  We discussed about submitting text and text is 
what is needed.

The beginning sounds good.

But then it is very long.

We have to discuss further RFC 8505 before inclusion of that RECOMMENDED.

Alex

Le 05/04/2019 à 17:09, Pascal Thubert (pthubert) a écrit :
> Dear all;
> 
> As promised I put together some words on using IPv6 ND and then RFC 8505 
> for OCB. Please find attached early text. This could become a section 4.7.
> 
> Note that RFC 8505 enables a DAD operation for both link local and 
> global addresses, the associated global prefix being owned by either a 
> car or a RSU. RSUs connected to the internet can advertise a default 
> router preference to indicate they are willing to relay packets for 
> global addresses.
> 
> The attached text impacts other sections in particular the discussion on 
> global addresses which is somehow avoided in the current draft and could 
> be reintroduced.
> 
> Comments welcome : )
> 
> Pascal
> 
> *From:* Pascal Thubert (pthubert)
> *Sent:* jeudi 28 mars 2019 11:29
> *To:* Alexandre Petrescu <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: Intdir early review of 
> draft-ietf-ipwave-ipv6-over-80211ocb-34
> 
> Le 28 mars 2019 à 11:08, Alexandre Petrescu 
> <[email-masked] <mailto:[email-masked]>> a 
> écrit :
> 
>     Pascal,
> 
>         seehttps://datatracker.ietf.org/group/intdir/about/
> 
>         Majors issues
> 
>         -----------------
> 
>         “
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 5 Apr 2019 20:44:56 +0200

Pascal,

I do not understand some parts:
> For a link local address, the scope is the link, whereas for a
> global address the scope is the subnet from which the global address
> is derived.

For link local address the scope is the link - true.

For global address the scope is global (not a particular subnet nor a
prefix).

> The underlying assumption for DAD to operate correctly is that the 
> node that owns an IPv6 address can reach any other node within the 
> scope at the time it claims its address, which is done by sending a 
> DAD multicast message, and can hear any future claim for theat 
> address by another party within the scope for the duration of the 
> address ownership.

Yes.  The scope that you refer to is the link-local scope.  One uses DAD
to verify uniqueness of an IP address (link-local address, or
globally-scoped address, or ULA) on that link.  DAD cant be used to
verify uniqueness of an address beyond that link.

The uniqueness of a GUA or of a ULA beyond a link is ensured by other
means than DAD.  That is administrative means with some help from some
other tools.

Address ownership is not verified by DAD but by other things, including 
pings.

> In the case of OCB, there is a need to define a scope that is 
> compatible with DAD,

Well it sounds logic in a sense, but are you sure?  Is that need coming
from practice or from logic?  This is very important.  Without a
practical need it is not worth going to the trouble of adding new text.

Also, the only scope that is compatible with DAD is the link scope.

> and that [needed scope for DAD] cannot be the set of nodes that a 
> transmitter can reach at a particular time, because that set varies 
> all the time and does not meet the DAD requirements for a link local 
> address that could possibly be used anytime, anywhere.

This phrase is too long.

As I read it, it seems to have misunderstandings.

You say 'DAD reqs for a link local address that could possibly used
anytime anywhere' - what does it mean?  Some part of DAD (the initial
NAs) use the unspecified address (::) and dst a group.  None is an ll
address.

Or maybe you need a scope of a multicast group?

Again, the need of scope should come from practice to be worth considering.

> The generic expectation of a reliable multicast is not ensured, and 
> the operation of DAD and AR as specificed by RFC 4861 cannot be 
> guaranteed.

Please explain why DAD and address resolution cant be guaranteed.  In
practice.

I never seen DAD reporting problems of duplicates on OCB, or some
unreachability.

I did see DAD reporting problems in some other contexts, and I know what
these problems look like.

> Early experiences indicate that it should be possible to exchange 
> IPv6 packets over OCB while relying on IPv6 ND alone for DAD and AR.

YEs.  We did it even today.

> In the absence of a correct DAD operation, a node that relies only on
> IPv6 ND for AR and DAD over OCB MUST ensure that the addresses that
> it uses are unique by means others than DAD.

Means other than DAD, or DAD with a new scope as proposed earlier?

> It must be noted that deriving an IPv6 address from a globally
> unique MAC address has this property but yields privacy issues.

YEs, I agree, and we already recommend other more recent RFCs about the
forming of an Interface ID.

> RFC 8505 provides a more recent approach to IPv6 ND and in
> particular DAD.

RFC8505 "Registration Extensions for IPv6 over Low-Power Wireless
Personal Area Network (6LoWPAN) Neighbor Discovery"

OCB is not 6LoWPAN because cars have not LoW power, but relatively
higher.  Also, OCB is not PAN but more like LAN.

When OCB is used in a V2V manner it is very hard to say who should
register its address to whom.  It's different than
Sensor-to-BackboneRouter.  It is more like Peer-to-Peer.

> the [RFC8505] scope of uniqueness for a link local address is
> restricted to a pair of nodes that use it to communicate, and
> provides a method to assert the uniqueness and resolve the link-Layer
> address using a unicast exchange.

But look, in some of the V2V trials we did there was one leader and two 
followers, each immediately following the leader (not a chain, but more 
like a triangle formation).  In that there are three nodes needing DAD, 
not two.

Why should we discard the existing DAD that works and replace it with 
RFC8505 that only works for two nodes?

> RFC 8505 also enables a router (acting as a 6LR) to own a prefix and
> act as a registrar (acting as a 6LBR) for addresses within the
> associated subnet. A peer host (acting as a 6LN) registers an address
> derived from that prefix and can use it for the lifetime of the
> registration. The prefix is advertised as not onlink, which means that
> the 6LN uses the 6LR to relay its packets within the subnet, and
> participation to the subnet is constrained to the time of reachability
> to the 6LR. Note that RSU that provides internet connectivity MAY

It's an IP-RSU, not an RSU.

> announce a default router preference [RFC 4191], whereas a car that
> does not provide that connectivity MUST NOT do so. This operation
> presents similarities with that of an access point, but at
> Layer-3. This is why RFC 8505 well-suited for wireless in general.

Well, I think you make many logical extensions.

I think claiming RFC8505 to be well-suited for wireless in general is a 
very ambitious statement.

> Support of RFC 8505 is RECOMMENDED on OCB.

I disqgree.

> OCB nodes that support RFC
> 8505 

I am not sure there is any OCB node that supports RFC 8505.
Maybe you can point to one, or maybe how to make one?

> MUST support the 6LN operation in order to act as a host, and may
> support the 6LR and 6LBR operations in order to act as a router and in
> particular own a prefix that can be used by RFC 8505-complient hosts
> for address autoconfiguration and registration.

I think you have a particular view of what is an address architecture in 
the car networks, when you say 'own a prefix', or when you say Host and 
Router.

I will not oppose if you proposed an addressing architecture for 
vehicular networks, in a different draft.  I will comment to it and 
provide our view of addressing architecture for vehicular networks.

Alex

Le 05/04/2019 à 19:53, Alexandre Petrescu a écrit :
> PAscal, Thank you for the text.  We discussed about submitting text 
> and text is what is needed.
> 
>> As promised I put together some words on using IPv6 ND and then
>> RFC 8505 for OCB. Please find attached early text. This could
>> become a section 4.7.
>> 
>> global addresses, the associated global prefix being owned by 
>> either a car or a RSU. RSUs connected to the internet can
>> advertise a default router preference to indicate they are willing
>> to relay packets for global addresses.
>> 
>> The attached text impacts other sections in particular the 
>> discussion on global addresses which is somehow avoided in the 
>> current draft and could be reintroduced.
>> 
>> Comments welcome : )
>> 
>> Pascal
>> 
>> *From:* Pascal Thubert (pthubert) *Sent:* jeudi 28 mars 2019 11:29
>>  *To:* Alexandre Petrescu <[email-masked]> *Cc:* 
>> [email-masked] *Subject:* Re: Intdir early review of 
>> <[email-masked] 
>> <mailto:[email-masked]>> a écrit :
>> 
>> Pascal,
>> 
> _______________________________________________ its mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/its

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 5 Apr 2019 20:48:16 +0200

Pascal,

IP over 802.15.4 ('6lowpan' RFC 4944) uses a different adaptation layer 
than the Ethernet Adaptation Layer used by IP over OCB 
(draft-ietf-ipwave-ipv6-over-80211ocb-34)

Why do you want to use IP-over-802154?  It has nothing to do, right?

Alex

Le 05/04/2019 à 19:53, Alexandre Petrescu a écrit :
>> As promised I put together some words on using IPv6 ND and then RFC 
>> 8505 for OCB. Please find attached early text. This could become a 
>> section 4.7.
>>
>> The attached text impacts other sections in particular the discussion 
>> on global addresses which is somehow avoided in the current draft and 
>> could be reintroduced.
>>
>> Comments welcome : )
>>
>> Pascal
>>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its

---

From: Abdussalam Baryun <[email-masked]>
Date: Sat, 6 Apr 2019 11:11:26 +0200

On Mon, Mar 4, 2019 at 1:25 PM Pascal Thubert <[email-masked]> wrote:

> used that way based on IEEE work.

I think the IETF/IEEE already knows there relationships/business, this
issue is not related to the draft objectives. When the ITS is using
Internet then YES this WG in IETF is to define such technology for
Internet. IEEE is not doing definitions for Internet but we are, and we
tell the world what should be in L2 and even L1 if we need, also IEEE can
define what is in any layer if needed by their business.

> The use of IPv6 ND requires a lot more
> thoughts, recommendation to use 6LoWPAN ND.

Why you recommend that ? I think it is not needed but can be in separate
draft.

> The definition of a subnet is
> unclear.

the subnet is 80211ocb it is clear.

It seems that RSUs would have prefixes but that is not discussed.
> Is this doc scoped to OCB or 802.11 in general?

scoped for 802.11p which we are doing 80211ocb

Is there an expectation that an
>  then it should be very clear, and the newly defined fields should be

The definition is always both define, we are different Organisations/WGs,
so no doubt that both define, and this document agrees to use the IEEE
definition, but in future if we need to change definitions for some
reason we can amend this work (with mentioning our reasons for best
practice on Internet use) and the IEEE can amend and follow. Now we used
IEEE definitions and work in LLC.

> 802.11-OCB is immediately  preceded by a Logical Link Control (LLC) header

I don't support to use Per IEEE Std (did any WG use such in RFCs?), even if
we may be echoing, why we don't use what we believe is right in our
organisation and we can change in future when we need?

AB

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 8 Apr 2019 11:01:26 +0200

As a note: please improve the title of this.

It is not an early review.

It is a late review.

There have been several reviews of this document until here, and two 
shepherd reviews.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 8 Apr 2019 11:10:52 +0200

Le 04/03/2019 à 12:24, Pascal Thubert a écrit :
> Reviewer: Pascal Thubert Review result: Not Ready
[...]
> The method of forming IIDs described in section 4 of [RFC2464] MAY be
> used during transition time. " Contradicts section 4.3 that says " 
> Among these types of addresses only the IPv6 link-local addresses MAY
> be formed using an EUI-64 identifier. "

Thank you for pointing this.  I would not qualify it as a strong 
contradiction though.  It's not like one was MUST and the other MUST 
NOT.  They are both 'MAY'.

To clarify, I propose I add 'for lls' and 'during transition time':

NEW:
> The method of forming IIDs described in section 4 of [RFC2464] MAY be
> used during transition time, in particular for IPv6 link-local
> addresses.
[...]
> Among these types of addresses only the IPv6 link-local addresses MAY
> be formed using an EUI-64 identifier, in particular during transition
> time.

Do you disagree?

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 8 Apr 2019 11:18:42 +0200

[...]
> If this is conforming IPv6 then the MUST is not needed.

What do you mean by 'conforming IPv6'?

The above phrase is a clarification of existing IPv6 specs.

The spec in question is RFC 2464.  I consider that to be what we need to 
  conform to.  That spec says 'fe80::/64'.  But that 64 is wrong.  Hence 
the clarification.

Do you disagree with it?

(the reasons why I put there /10 and not /64 are the following: LLs work 
in linux with any length between 10 and 64, the ND spec does not 
restrict to 64, the IANA starts at 10, and probably other reasons; there 
is a recent I-D about this LL prefix length: 
draft-petrescu-6man-ll-prefix-len-07).

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 8 Apr 2019 11:27:23 +0200

[...]
> " A subnet is formed by the external 802.11-OCB interfaces of
> vehicles that are in close range (not by their in-vehicle
> interfaces). " Is the definition transitive? Do we really get a
> subnet? A is close to  B who is close to C .... to Z, makes Paris one
> subnet! Are you talking about a link, rather?

Allow me to clarify.

I do not know whether the definition mentioned above is transitive.  A
transitive characteristic is the following: A talks to B, and B talks to
C results in A talks to C.

In the V2V settings I use there does not seem to be any transitivity.
There is a convoy of cars; there are distinct subnets between each pair
of two  cars (or sometimes between triplets of cars).  Within these
subnets there does not seem to be transitivity.

If interested, yes, there is IP forwarding: one PC in Lead vehicle
receives replies to ICMP Echo Replies to its Echo Requests addressed to
another PC in the rearmost vehicle.  The ICMP messages are forwarded by
intermediary IP-OBUs (Routers) situated in each car.

In this setting, there are 2 or 3 EThernet and CAN links in each car,
and there are distinct IP subnets on OCB between each pair (or triplet
in some cases) of cars.

Each such subnet of IP-over-OCB is run on one of the 5 possible OCB
channels in the 5.9GHz range.  The selection of these channels is a
method that I will not describe here.

Does this clarify?

If not, would you like the text to say it is not transitive?

If yes, I propose:

NEW:
> that are in close range (not by their in-vehicle interfaces).  This
> definition is not transitive.

Do you agree with this text?

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 8 Apr 2019 11:32:32 +0200

[...]
> Why is that? This is unexpected, and hopefully wrong.

However, we discussed this text and it comes from WG discussion. I think 
I remember the person who suggested it, and it is a very knowledgeable
person who did or witnessed closely this operation, in a well known
smartphone.

I find it right: it ensures even more privacy.

It is implemented.

You realize I cant just remove that text.

I do not understand why do you think it is wrong?

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 8 Apr 2019 11:37:46 +0200

[...]
> Minor issues

Yes, they are two different things.

We use the term 'OCB' in the text to write at high-level about the OCB 
mode.  For example, searching ' OCB ' (remark spaces surronding OCB) 
issues high-level text like:
 > The OCB operation is stripped off of all existing [blah blah blah]

 > A subnet is formed by the external 802.11-OCB interfaces of vehicles

I hope this use of two terms 'OCB' and '802.11-OCB' is not wrong in your 
reading.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 8 Apr 2019 11:44:37 +0200

[...]
> " Among these types of addresses only the IPv6 link-local addresses 
> MAY be formed using an EUI-64 identifier. "
> 
> This text should not be in a LL specific section since it deals with
> the other addresses. Maybe rename the section to "addressing" or
> something?

The titles of these sections come directly from the RFC2464 
IPv6-over-Ethernet.

The title of this section is 'Link-Local Addresses' and as such it has 
the Address root in it.

The text deals indeed with other kinds of addresses, in that it says 
'There are several types of IPv6 addresses'.  But then it gets specific 
to LL addresses.  The 'MAY' keyword is only applied to LL addresses.

As such, I do not understand why do you think it deals with the other 
kinds of addresses (non LL)?

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 8 Apr 2019 11:48:45 +0200

[...]
> " For privacy, the link-local address MAY be formed according to the
>  mechanisms described in Section 5.2. "

> The MAY is not helpful. I suggest to remove the sentence that does
> not bring value vs. 5.2
To better understand: do you want to remove the phrase and promote the 
section 5.2 "MAC Address and Interface ID Generation"?

(the restrain I have from promoting it is that I did not see 5.2 
implemented; neither do I know the IPR status of it)

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 8 Apr 2019 11:51:59 +0200

[...]
> Could you make sections 4.3 and 4.5 contiguous?

I would re-order them, if you dont mind.

Alex

---

From: NABIL BENAMAR <[email-masked]>
Date: Mon, 8 Apr 2019 10:52:50 +0100

Yes definitely Alex....

There have been many reviews until now. This should be a late or
final review.

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 8 Apr 2019 12:15:24 +0200

[...]
> Duplicate and mis ordered text, isn't it?

Indeed.  The duplication comes from multiple discussions and expresses 
support of many people to the use of opaque identifiers.

To my defense, there is however a notion of going from generic to 
particular.  In first occurences of opaque IIDs we just refer to the 
RFC, then tell how, and so on.

But of course it is a bit long, and worse, it refers twice to the 
RFC7217, which may disturb.

If you dont mind, I shorten it like this:

NEW:
>    ([RFC2464], section 4), help avoid certain privacy risks (see the
>    paragraph below).  If semantically opaque Interface Identifiers are
>    needed, they MAY be generated using the method for generating
>    semantically opaque Interface Identifiers with IPv6 Stateless Address
>    Autoconfiguration given in [RFC7217].  Typically, an opaque Interface
>    Identifier is formed starting from identifiers different than the MAC
>    addresses, and from cryptographically strong material.  Thus, privacy
>    sensitive information is absent from Interface IDs, because it is
>    impossible to calculate back the initial value from which the
>    Interface ID was first generated (intuitively, it is as hard as
>    mentally finding the square root of a number, and as impossible as
>    trying to use computers to identify quickly whether a large number is
>    prime).
> 
>    The privacy risks of using MAC addresses displayed in Interface
>    Identifiers are important.  The IPv6 packets can be captured easily
>    in the Internet and on-link in public roads.  For this reason, an
>    attacker may realize many attacks on privacy.  One such attack on
>    802.11-OCB is to capture, store and correlate Company ID information
>    present in MAC addresses of many cars (e.g. listen for Router
>    Advertisements, or other IPv6 application data packets, and record
>    the value of the source address in these packets).  Further
>    correlation of this information with other data captured by other
>    means, or other visual information (car color, others) MAY constitute
>    privacy risks.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 8 Apr 2019 12:28:41 +0200

[...]

> Do we attack privacy?

Yes.  RFC7258 says "pervasive monitoring is a widespread attack on privacy".

> Maybe say that privacy is a real concern, and maybe move

We had it in the security section and moved it here.

Now, what you say sounds logic to me, so let me move it back the 
paragraph of privacy risks in the security section.

(this is part of the moving back and forth text; I hope this operation 
improves, and not just cycles).

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 8 Apr 2019 12:30:27 +0200

[...]
>     as described in Section 5.1.

Removed.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 8 Apr 2019 12:41:45 +0200

[...]

> Please add link to the reference

I added like below.

But beware that:
- it is the third time we refer to this document in the text.
- the document behind the URL is behind a paywall, even though the
   description of the document is free of access.

NEW:
>    frames whose format is specified in IEEE 802.11(TM) -2016
>    [IEEE-802.11-2016].
[...]
>    [IEEE-802.11-2016]
>               "IEEE Standard 802.11-2016 - IEEE Standard for Information
>               Technology - Telecommunications and information exchange
>               between systems Local and metropolitan area networks -
>               Specific requirements - Part 11: Wireless LAN Medium
>               Access Control (MAC) and Physical Layer (PHY)
>               Specifications. Status - Active Standard.  Description
>               retrieved freely on September 12th, 2017, at URL
>               https://standards.ieee.org/findstds/
>               standard/802.11-2016.html".

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 8 Apr 2019 12:45:26 +0200

[...]

> => "the IEEE Std. 802.11 [ ref ] hidden node", or just "the hidden terminal".

The hidden terminal - done.

I prefer avoid referring a fourth time to a document that cant be read 
unless paying.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 8 Apr 2019 13:10:09 +0200

[...]
>     appear in all capitals, as shown here.

I will add it, thank you.  I want to be up to date with most recent specs.

But here are my worries about it for what is worth:

- I dont understand though why the need to say 'capitals' when in 
CAPITALS is it written.

- I thought that a BCP document was just one RFC.  Here we seem to be 
talking about BCP-14 being both RFC2119 and RFC8174.

A google search on BCP-14 hits first on RFC 2119, and a document called 
'bcp14' (not on RFC8174). https://tools.ietf.org/html/bcp14

The second hit is a page at RFC Editor which points to a "Canonical URL" 
towards https://www.rfc-editor.org/bcp/bcp14.txt which does not talk 
about RFC8174 either.

It then points to https://www.rfc-editor.org/refs/ref-bcp14.txt
That ref points back to a web page telling the "Canonical URL".

- finally, the text ends with 'as shown here', which invites my reading 
to think that what follows needs to be understood with these capitals. 
And what follows is the definition of terms like "IP-OBU", etc.  That is 
worrisome.  You can understand the worry if you read it as a whole:
>    "OPTIONAL" in this document are to be interpreted as described in BCP
>    14 [RFC2119] [RFC8174] when, and only when, they appear in all
>    capitals, as shown here.
> 
>    IP-OBU (Internet Protocol On-Board Unit): an IP-OBU is a computer
>    situated in a vehicle such as an automobile, bicycle, or similar.  It
>    has at least one IP interface that runs in mode OCB of 802.11, and
>    that has an "OBU" transceiver.  See the definition of the term "OBU"
>    in section Appendix I.

The dot after 'here' is very important, but so small.  A quick or 
low-sighted reader may see it as double dots.  And that would be a 
problem, because the "IP-OBU" term definition is not suject to that 
capitalization.

Alex

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 8 Apr 2019 12:58:39 +0000

Hello Alexandre

All the best,please see below

From: Alexandre Petrescu <[email-masked]>
Sent: lundi 8 avril 2019 17:01
To: Pascal Thubert (pthubert) <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Intdir early review of draft-ietf-ipwave-ipv6-over-80211ocb-34

It is a late review.

  *   In the context of document publication I believe this is coming before all the other areas directorates isn’t it. That’s what early means here…

There have been several reviews of this document until here, and two shepherd reviews.

Alex

Reviewer: Pascal Thubert

Review result: Not Ready

Reviewer: Pascal Thubert

Majors issues

-----------------

“

      802.11 than on Ethernet.

“

from IEEE fields.

"

"

an 802.11 header ...'

   layer.

"

this IETF business?

"

"

"

"

"

   time.

"

"

Among these types of

   EUI-64 identifier.

"

"

This

"

"

"

"

   802.11-OCB links.

"

"

"

Minor issues

---------------

   confidentiality.

"

"

Among these types of

  EUI-64 identifier.

"

"

"

value vs. 5.2

"

If semantically

   privacy risks.

...

"

   attacks on privacy.

"

"

"

Also duplicate

Nits

------

"

"

BCP 14 text:

“

“

All the best

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 8 Apr 2019 12:59:30 +0000

Hello Nabil.

You will get a number of IESG reviews as part of the submission process, one per area. This is just a beginning…

Cheers,

Pascal

From: NABIL BENAMAR <[email-masked]>
Sent: lundi 8 avril 2019 17:53
To: Alexandre Petrescu <[email-masked]>
Cc: Pascal Thubert (pthubert) <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Intdir early review of draft-ietf-ipwave-ipv6-over-80211ocb-34

Yes definitely Alex....

There have been many reviews until now. This should be a late or final review.

On Mon, Apr 8, 2019, 10:01 Alexandre Petrescu <[email-masked]<mailto:[email-masked]>> wrote:

It is a late review.

Alex

Reviewer: Pascal Thubert

Review result: Not Ready

Reviewer: Pascal Thubert

Majors issues

-----------------

“

      802.11 than on Ethernet.

“

from IEEE fields.

"

"

an 802.11 header ...'

   layer.

"

this IETF business?

"

"

"

"

"

   time.

"

"

Among these types of

   EUI-64 identifier.

"

"

This

"

"

"

"

   802.11-OCB links.

"

"

"

Minor issues

---------------

   confidentiality.

"

"

Among these types of

  EUI-64 identifier.

"

"

"

value vs. 5.2

"

If semantically

   privacy risks.

...

"

   attacks on privacy.

"

"

"

Also duplicate

Nits

------

"

"

BCP 14 text:

“

“

All the best

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 8 Apr 2019 13:02:31 +0000

Another misconception:

For all I know, IEEE documents are generally available for free 6 months after the publication.

Cheers,

Pascal

> -----Original Message-----
> Sent: lundi 8 avril 2019 19:10
> To: Pascal Thubert (pthubert) <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked]; draft-ietf-ipwave-ipv6-over-
> [email-masked]
> Subject: Re: Intdir early review of draft-ietf-ipwave-ipv6-over-80211ocb-34 -
> KeyWords BCP 14 text
> 
> 
> - I dont understand though why the need to say 'capitals' when in CAPITALS is
> it written.
> 
> - I thought that a BCP document was just one RFC.  Here we seem to be talking
> about BCP-14 being both RFC2119 and RFC8174.
> 
> towards https://www.rfc-editor.org/bcp/bcp14.txt which does not talk about
> RFC8174 either.
> 
> - finally, the text ends with 'as shown here', which invites my reading to think
> that what follows needs to be understood with these capitals.
> The dot after 'here' is very important, but so small.  A quick or low-sighted
> reader may see it as double dots.  And that would be a problem, because the
> "IP-OBU" term definition is not suject to that capitalization.
> 
> Alex

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 8 Apr 2019 13:05:15 +0000

WFM

All the best,

Pascal

> Sent: lundi 8 avril 2019 18:15
> shortening the opaque IID text
> 
> 
> To my defense, there is however a notion of going from generic to particular.
> In first occurences of opaque IIDs we just refer to the RFC, then tell how, and
> so on.
> 
> But of course it is a bit long, and worse, it refers twice to the RFC7217, which
> may disturb.
> 
> > Do we attack privacy? Maybe say that privacy is a real concern, and
> > maybe move that text to security section?
> >
> > "

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 8 Apr 2019 13:05:17 +0000

WFM

All the best,

Pascal

> Sent: lundi 8 avril 2019 17:52
> sequencing the LL and SLAAC sections closer
> 
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 8 Apr 2019 13:06:34 +0000

I think that the sentence can just be removed without any loss.

All the best,

Pascal

> Sent: lundi 8 avril 2019 17:49
> MAC and IID Generation - MAY
> 
> 
> > The MAY is not helpful. I suggest to remove the sentence that does not
> > bring value vs. 5.2
> (the restrain I have from promoting it is that I did not see 5.2 implemented;
> neither do I know the IPR status of it)
> 
> Alex

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 8 Apr 2019 13:08:28 +0000

OK

All the best,

Pascal

> Sent: lundi 8 avril 2019 18:30
> duplicate about privacy risks (again!)
> 
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 8 Apr 2019 15:09:13 +0200

Le 08/04/2019 à 14:58, Pascal Thubert (pthubert) a écrit :
> *From:*Alexandre Petrescu <[email-masked]>
> *Sent:* lundi 8 avril 2019 17:01
> *To:* Pascal Thubert (pthubert) <[email-masked]>; [email-masked]
> *Cc:* [email-masked]; [email-masked]; 
> [email-masked]
>   * In the context of document publication I believe this is coming
>     before all the other areas directorates isn’t it. That’s what early
>     means here…

Ah?

Should we expect more reviews from more directorates?

How about IESG?

Alex

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 8 Apr 2019 13:09:34 +0000

The sentence
> > MAY be formed using an EUI-64 identifier. "
 is the logical equivalent to
"non LL Addresses MAY NOT be formed using an EUI-64 identifier". This should be said in a section that discusses non LL Addresses.

All the best,

Pascal

> Sent: lundi 8 avril 2019 17:45
> title of the section 4.3 on LLs
> 
> 
> The titles of these sections come directly from the RFC2464 IPv6-over-
> Ethernet.
> 
> The title of this section is 'Link-Local Addresses' and as such it has the Address
> root in it.
> 
> The text deals indeed with other kinds of addresses, in that it says 'There are
> several types of IPv6 addresses'.  But then it gets specific to LL addresses.  The
> 'MAY' keyword is only applied to LL addresses.
> 
> As such, I do not understand why do you think it deals with the other kinds of
> addresses (non LL)?
> 
> Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 8 Apr 2019 15:13:43 +0200

> For all I know, IEEE documents are generally available for free 6 months after the publication.

It's a good rule to remember.  I heard it from several people.

For now, maybe I dont understand, but I try to download IEEE 802.11-2016 
from this URL
https://standards.ieee.org/standard/802_11-2016.html

It can be downloaded by two buttons:
- "Access via the IEEE Get Program" - when clicked, it goes to my 
employers' subscription (not everyone is employed by .my employer)

or

- "Access via Subscription" - when clicked it leads to other and other 
pages.

What is your URL that you access without paying?

I will put that URL in the IPv6-over-OCB document.

Alex

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 8 Apr 2019 13:13:45 +0000

"
The PDF of this standard is available at no cost compliments of the IEEE GET program http://ieeexplore.ieee.org/browse/standards/get-program/page/)
"
=> https://ieeexplore.ieee.org/document/7786995 

All the best,

Pascal

> Sent: lundi 8 avril 2019 18:42
> ref ro 802.11 standard

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 8 Apr 2019 15:14:26 +0200

I think 'WFM' means 'Works For Me', so I am happy if it works for you.

Alex

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 8 Apr 2019 13:19:45 +0000

Oh yes. Once you passed me. You may find I was easy ; )

All the best,

Pascal

> Sent: lundi 8 avril 2019 21:09
> > not bring

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 8 Apr 2019 13:19:46 +0000

Yes, that 's just to say OK with me.

All the best,

Pascal

> Sent: lundi 8 avril 2019 21:14
> >> Cc: [email-masked]; [email-masked]; [email-masked];
> >> draft-ietf-ipwave-ipv6-over- [email-masked]
> >> Subject: Re: Intdir early review of
> >> draft-ietf-ipwave-ipv6-over-80211ocb-34 - shortening the opaque IID
> >> text
> >>
> >>
> >> Indeed.  The duplication comes from multiple discussions and
> >> expresses support of many people to the use of opaque identifiers.
> >>
> particular.
> >> In first occurences of opaque IIDs we just refer to the RFC, then
> >> tell how, and so on.
> >>
> >>>      "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
> RECOMMENDED",
> >> "MAY", and

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 8 Apr 2019 15:35:50 +0200

Pascal,

I would like to clarify this.

At this time I dont have access to 802.11 standard.  I dont think you 
have access either, other than via your organisation maybe, but not as 
an individual.

Please let me know whether you have free access?

Can you click and get the document now?

Many people say IEEE 802.11-2016 is free, but it depends what they mean 
by free. At this time I understand it can be "*Please note: free 
consultation available to organizations only, not for individuals or 
students."

I would like to debug this to better understand.  Web browsing is not easy.

The page you point to leads to this figure 
(https://ieeexplore.ieee.org/document/7786995)

Remark "You do not have access to this PDF" when rolling the mouse over 
the small red "PDF" button which becomes black.

Then, I click on that PDF button and I obtain this login page.  This 
login page says that I should Sign In to access this free standard.

That requests to create an account.  I try to create an account.

Then that says "Thank you for your submission", and "An IEEE Content 
Specialist will contact you soon".

Alex

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 8 Apr 2019 10:01:20 -0400

Following the link Pascal provided, I get a summary page, witha pdf link.
If I follow that link, it offers me a free login to get the document.
So yes, it is available for free.

Yours,
Joel

On 4/8/19 3:35 PM, Alexandre Petrescu wrote:
>> The PDF of this standard is available at no cost compliments of the IEEE GET programhttp://ieeexplore.ieee.org/browse/standards/get-program/page/)
>> "
>> =>https://ieeexplore.ieee.org/document/7786995  
>>
>> All the best,
>>
>> Pascal
>>
>>> From: Alexandre Petrescu<[email-masked]>
>>> To: Pascal Thubert (pthubert)<[email-masked]>
>>> Cc:[email-masked];[email-masked];[email-masked]; draft-ietf-ipwave-ipv6-over-
>>> [email-masked]

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 8 Apr 2019 16:01:51 +0200

I remove 'For privacy, the link-local address MAY be formed according to 
the mechanisms described in Section 5.2."MAC Address and Interface ID 
Generation".

The section 5.2 will no longer be referred to, but just present.  A 
little bit orphaned.

If the author does not cry out, it stays that way.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 8 Apr 2019 16:11:23 +0200

> "non LL Addresses MAY NOT be formed using an EUI-64 identifier". This should be said in a section that discusses non LL Addresses.

That 'MAY NOT' is your understanding.  For me the 'MAY NOT' is absent, 
silent.  I can not put a 'NOT' on something that is widely deployed 
today (MAC-based IPv6 GUAs are in widespread use, especially in the 
embedded world).

In the section we discuss non LL addresses (section 4.4 "Stateless 
autoconf") we RECOMMEND stable IIDs (RFC8064) and MAY semantically 
opaque IIDs (RFC 7217).

In that section 4.4 we also say MAY use RFC 2464-based IIDs (MAC-based), 
during transition time.  By transition I understand towards a better 
later world when embedded linuces moved to kernels 4.x (currently at 2.x).

Is this approach not ok?

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 8 Apr 2019 16:12:36 +0200

> So yes, it is available for free.

Joël,

I am sorry.  I may misunderstand.

But please click and then tell whether you get the document, or not.

I have the same feedback from a co-author.  I asked him the same.  I 
have no answer.

I am sorry if I ask too much.

Alex

>> Many people say IEEE 802.11-2016 is free, but it depends what they 
>> mean by free. At this time I understand it can be "*Please note: free 
>> Remark "You do not have access to this PDF" when rolling the mouse 
>> over the small red "PDF" button which becomes black.
>>
>>
>>
>>> The PDF of this standard is available at no cost compliments of the 
>>> IEEE GET 
>>> programhttp://ieeexplore.ieee.org/browse/standards/get-program/page/)
>>> "
>>>> draft-ietf-ipwave-ipv6-over-80211ocb-34 -
>>>> ref ro 802.11 standard
>>>>
>>>>

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 8 Apr 2019 16:17:38 +0200

> For all I know, IEEE documents are generally available for free 6 months after the publication.

(This is true specifically for IEEE 802 documents through the get802 program, and a few other places they have seen the light.  Generally, IEEE’s business model is still largely based on selling documents.)

Grüße, Carsten

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 8 Apr 2019 16:35:08 +0200

Carsten,

Le 08/04/2019 à 16:17, Carsten Bormann a écrit :
> (This is true specifically for IEEE 802 documents through the get802
> program, and a few other places they have seen the light.  Generally,
> IEEE’s business model is still largely based on selling documents.)

I can agree with the principle.

In this particular case, is it too much that I ask you to please
download this 802.11-2016 document
https://ieeexplore.ieee.org/document/7786995

If you already have an account via an organisation, please remove it
from the Options of your browser (so it does not pre-fill the form with
some password) and try to follow the IEEE procedure to maybe make a new one.

If you access IEEE via an organisation's IP address (so your
organisation's name is seen at the top of the page) then try to access
it from home, or from smartphone.

If you think the IEEE GET Program gives some additional access ("With
support from the IEEE-SA, industry sponsors, and government, a number of
IEEE standards are available for download at no cost.  This program,
entitled IEEE GET ProgramTM, grants public access to view and/or
download these current individual standards.) please go to its URL
and see that they list 802.11 but then it points to the same URL as at
the beginning of this email, so cant download.

If it is too much to ask, sorry.

(I already asked a co-author to do this - no answer; and another
knowledgeable person just now doubts in private the availability
statements).

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 8 Apr 2019 17:30:37 +0200

a knowledgeable person tells in private we could share the document in a 
peer-to-peer manner.  I thank.

but there is still no free access to the IEEE 802.11-2016 document, so I 
keep "Description freely available" and I do not put "document freely 
available".

I will check back tomorrow.

Alex

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 8 Apr 2019 15:46:13 +0000

Hi Alex,

I created and logged in using a new personal account (not from the Cisco corporate network).  I also needed to add a physical address, but after that I was able to download the pdf version of the standard to my phone at no charge.

So, I believe that this document (IEEE 802.11-2016) is currently freely available.

However, I'm not sure whether this particular version will still be freely available if a new version of the 802.11 standard is published.  I might be wrong, but I think that just that latest version that is at least 6 months old that is available at no charge, after that you need to pay (or get it via a personal/corporate IEEE membership) ... certainly that is what the website seems to indicate if I try and access an older revision of the IEEE 802.11 standard.

HTH,
Rob

> From: ietf <[email-masked]> On Behalf Of Alexandre Petrescu
> Sent: 08 April 2019 16:31
> To: Alexandre Petrescu <[email-masked]>; Carsten Bormann
> <[email-masked]>
> Cc: Pascal Thubert (pthubert) <[email-masked]>; [email-masked]; draft-
> [email-masked]; [email-masked]; [email-masked]
> free or not free access to 802.11-2016 document
> 
> but there is still no free access to the IEEE 802.11-2016 document, so I keep
> "Description freely available" and I do not put "document freely available".
> 
> > from the Options of your browser (so it does not pre-fill the form
> > with some password) and try to follow the IEEE procedure to maybe make
> > a new one.
> >
> > support from the IEEE-SA, industry sponsors, and government, a number
> > of IEEE standards are available for download at no cost.  This
> > program, entitled IEEE GET ProgramTM, grants public access to view
> > and/or download these current individual standards.) please go to its
> > URL and see that they list 802.11 but then it points to the same URL
> > as at the beginning of this email, so cant download.
> >

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 8 Apr 2019 17:56:03 +0200

Hi Rob,
Thank you for the logging with new personal account.

Was it a "IEEE Xplore Subscription for Individual Access (for Personal 
Use Only)"?

(which button did you use to create an account?)

(also I am surprised you were asked for a physical address; when I tried 
to register as Organisation they just asked for City, no more details 
about address).

Alex

---

From: Russ Housley <[email-masked]>
Date: Mon, 8 Apr 2019 12:29:54 -0400

Alexandre:

Yes.  Once the WG sends the document to the IESG, there will be more review.  Resolving the current set of comments will put us in a much better place, and increase the number of people that are supporting the approach in the document.

Russ

> On Apr 8, 2019, at 9:09 AM, Alexandre Petrescu <[email-masked]> wrote:
> 
> 
> 
>> *Cc:* [email-masked]; [email-masked]; [email-masked]
>> *Subject:* Re: Intdir early review of draft-ietf-ipwave-ipv6-over-80211ocb-34

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 8 Apr 2019 20:05:28 +0200

Hi,

Yes, it works.

I created an account for free and gave a postal address.  It's a fake 
address but in a specific non-US country.  I checked accepting cookies 
and other things, and unchecked some other boxes about ads I think.

Then the pdf downloads ok fully.

Still, I hesitate before saying "freely available".  I might say "freely 
available with some difficulty of access as of 2019".

Alex

Le 08/04/2019 à 17:56, Alexandre Petrescu a écrit :
>> I created and logged in using a new personal account (not from the 
>> Cisco corporate network).  I also needed to add a physical address, 
>> but after that I was able to download the pdf version of the standard 
>> to my phone at no charge.
>>
>> However, I'm not sure whether this particular version will still be 
>> freely available if a new version of the 802.11 standard is 
>> published.  I might be wrong, but I think that just that latest 
>> version that is at least 6 months old that is available at no charge, 
>> after that you need to pay (or get it via a personal/corporate IEEE 
>> membership) ... certainly that is what the website seems to indicate 
>> if I try and access an older revision of the IEEE 802.11 standard.
>>
>> HTH,
>> Rob
>>
>>

---

From: CARLOS JESUS BERNARDOS CANO <[email-masked]>
Date: Mon, 8 Apr 2019 21:03:11 +0200

Hi Pascal, all,

Sorry to jump late into this discussion.

Thanks for the provided text.

I think it contains good parts that I'd recommend authors to consider
incorporating into the draft. I see you are already discussing about that
and I hope the WG reaches an agreement on how to modify current text.

I have some comments from my side:

- I tend to agree with Alex in that I'd skip the RECOMMENDED part of the
text (referring to RFC 8505). I agree that some pieces of RFC 8505 could be
adapted to be used in OCB, but I think using RECOMMENDED with further
analysis within the WG is too much. I'd rather prefer that RFC 8505 is
referenced in the draft as a solution that could be used as starting point
to enhance ND over OCB (but we have agreed already in the WG that ND
enhacements are outside the scope of current draft).

- I see good points in Pascal's text, but probably need some language
fixing, as it might lead to some questions as the Alex has pointed out.

- I'd appreciate if we all acknowledge here all the work Alex (and the rest
of the authors) have been doing so far, as well as Pascal's help. Please,
try to keep the discussion positive. That _always_ helps.

Thanks,

Carlos

On Fri, Apr 5, 2019 at 5:09 PM Pascal Thubert (pthubert) <[email-masked]>
wrote:

> Note that RFC 8505 enables a DAD operation for both link local and global
> addresses, the associated global prefix being owned by either a car or a
> RSU. RSUs connected to the internet can advertise a default router
> preference to indicate they are willing to relay packets for global
> addresses.
>
> global addresses which is somehow avoided in the current draft and could be
> reintroduced.
>
>
>
> Comments welcome : )
>
>
>
> Pascal
>
>
>
> Le 28 mars 2019 à 11:08, Alexandre Petrescu <[email-masked]>
> a écrit :
>
> Pascal,
>

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 8 Apr 2019 21:08:10 +0200

On Apr 8, 2019, at 21:03, CARLOS JESUS BERNARDOS CANO <[email-masked]> wrote:
> 
> - I tend to agree with Alex in that I’d skip the RECOMMENDED part of the text (referring to RFC 8505).

What would that even mean?

If I come up as an OCB node, how do I know if I should act as an ND-classic node or as an efficient-ND (RFC 6775/8505, whatever) node?  RECOMMENDED does not cut it here.  The IP-over-foo document needs to tell me.

Grüße, Carsten

---

From: CARLOS JESUS BERNARDOS CANO <[email-masked]>
Date: Mon, 8 Apr 2019 21:13:44 +0200

Hi Carsten,

On Mon, Apr 8, 2019 at 9:08 PM Carsten Bormann <[email-masked]> wrote:

> If I come up as an OCB node, how do I know if I should act as an
> ND-classic node or as an efficient-ND (RFC 6775/8505, whatever) node?
> RECOMMENDED does not cut it here.  The IP-over-foo document needs to tell
> me.
>

The IP-over-foo is telling you to act as an ND-classic node, as we have not
yet discussed on efficient/enhanced-ND operation over OCB.

Thanks,

Carlos

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 9 Apr 2019 10:37:54 +1200

On 08-Apr-19 21:18, Alexandre Petrescu wrote:
>   conform to.  That spec says 'fe80::/64'.  But that 64 is wrong.  

No it isn't. It specifies the LL prefix used over Ethernet. Since it
is within fe80::/10, it's valid.

I also don't understand the meaning of "at least" in this sentence.

> Hence 

If you specify the prefix as /10, you have to define how the other 118
bits are constructed. Specifying how the final 64 bits are constructed
is insufficient.

Also, it seems to me that you should cite RFC8064 everywhere that you cite
RFC2464, since the EUI-64 mechanism is now considered obsolete. I also think
the citation of draft-hinden-6man-rfc2464bis is confusing, since it seems
to be comatose.

> restrict to 64,

No, but IPv6-over-foo documents usually do apply that restriction, rather
than define 118-bit IIDs.

      Brian

> the IANA starts at 10, and probably other reasons; there

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 9 Apr 2019 00:04:35 +0000

Hello Carlos

I think we’re a bit stuck.

 I spent really a long time explaining why RFC 4861 does not cut it by itself. No magic will make that happen. I tried to help by indicating a version of ND that was designed for radios and to my best knowledge will work here. I understand that people will not trust that on “face value” but I do not understand that people prefer something that was designed before the concept of a radio link was even considered and is known not to work.

In any fashion I cannot support a doc that lets the outside of the IETF believe that RFC 4861 is suited for OCB. RFC 4861 survives on BSS thanks to the association process that provides a signal for DNA and emulates an Ethernet broadcast domain. Nothing like that on OCB.

Best can do is send the doc back to the WG till it can provide a satisfactory solution to ND.

Regards,

Pascal

Le 9 avr. 2019 à 03:04, CARLOS JESUS BERNARDOS CANO <[email-masked]<mailto:[email-masked]>> a écrit :

Hi Pascal, all,

I think it contains good parts that I'd recommend authors to consider incorporating into the draft. I see you are already discussing about that and I hope the WG reaches an agreement on how to modify current text.

- I tend to agree with Alex in that I'd skip the RECOMMENDED part of the text (referring to RFC 8505). I agree that some pieces of RFC 8505 could be adapted to be used in OCB, but I think using RECOMMENDED with further analysis within the WG is too much. I'd rather prefer that RFC 8505 is referenced in the draft as a solution that could be used as starting point to enhance ND over OCB (but we have agreed already in the WG that ND enhacements are outside the scope of current draft).

- I see good points in Pascal's text, but probably need some language fixing, as it might lead to some questions as the Alex has pointed out.

- I'd appreciate if we all acknowledge here all the work Alex (and the rest of the authors) have been doing so far, as well as Pascal's help. Please, try to keep the discussion positive. That _always_ helps.

Thanks,

Carlos

On Fri, Apr 5, 2019 at 5:09 PM Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
Dear all;

Comments welcome : )

Pascal

From: Pascal Thubert (pthubert)
Sent: jeudi 28 mars 2019 11:29
To: Alexandre Petrescu <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: Intdir early review of draft-ietf-ipwave-ipv6-over-80211ocb-34

Regards,

Pascal

Pascal,

Alex

Reviewer: Pascal Thubert

Review result: Not Ready

Reviewer: Pascal Thubert

Majors issues

-----------------

“

      802.11 than on Ethernet.

“

from IEEE fields.

"

"

an 802.11 header ...'

   layer.

"

this IETF business?

"

"

"

"

"

   time.

"

"

Among these types of

   EUI-64 identifier.

"

"

This

"

"

"

"

   802.11-OCB links.

"

"

"

Minor issues

---------------

   confidentiality.

"

"

Among these types of

  EUI-64 identifier.

"

"

"

value vs. 5.2

"

If semantically

   privacy risks.

...

"

   attacks on privacy.

"

"

"

Also duplicate

Nits

------

"

"

BCP 14 text:

“

“

All the best

Pascal

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 9 Apr 2019 10:42:36 +0200

In private, a person clarified this to me, and I agree.  The Canonical 
URL points to a document that says at its top that there are actually 
two documents there (RFC 2119 and RFC 8174).  I have to scroll down to 
see the second.  (it is a bit strange to me to see two RFCs 
concatenated, but I guess it is an exception).

The question left is the following: how to refer to BCP 14 in the xml 
text of draft IP-over-OCB?

The typical way of using it for referring to RFCs does not work. 
xml2rfc issues errors on this reference:

<xref target="BCP14"/>
[...]
<?rfc
     include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.BCP.14"
?>

Maybe others have already referred to BCP 14 in their Internet Drafts?

Alex

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 9 Apr 2019 11:04:26 +0000

Maybe copy section 2.1 of rfc 8505?

Regards,

Pascal

> Le 9 avr. 2019 à 16:42, Alexandre Petrescu <[email-masked]> a écrit :
> 
> In private, a person clarified this to me, and I agree.  The Canonical URL points to a document that says at its top that there are actually two documents there (RFC 2119 and RFC 8174).  I have to scroll down to see the second.  (it is a bit strange to me to see two RFCs concatenated, but I guess it is an exception).
> 
> The question left is the following: how to refer to BCP 14 in the xml text of draft IP-over-OCB?
> 
> The typical way of using it for referring to RFCs does not work. xml2rfc issues errors on this reference:
> 
> <xref target="BCP14"/>
> [...]
> <?rfc
>> - I dont understand though why the need to say 'capitals' when in CAPITALS is it written.
>> - I thought that a BCP document was just one RFC.  Here we seem to be talking about BCP-14 being both RFC2119 and RFC8174.
>> A google search on BCP-14 hits first on RFC 2119, and a document called 'bcp14' (not on RFC8174). https://tools.ietf.org/html/bcp14
>> The second hit is a page at RFC Editor which points to a "Canonical URL" towards https://www.rfc-editor.org/bcp/bcp14.txt which does not talk about RFC8174 either.
>> - finally, the text ends with 'as shown here', which invites my reading to think that what follows needs to be understood with these capitals. And what follows is the definition of terms like "IP-OBU", etc.  That is worrisome.  You can understand the worry if you read it as a whole:
>> The dot after 'here' is very important, but so small.  A quick or low-sighted reader may see it as double dots.  And that would be a problem, because the "IP-OBU" term definition is not suject to that capitalization.
>> Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 9 Apr 2019 14:18:47 +0200

It's a good idea.

I need the xml of it.

Is RFC8505 available as xml?

I cant find it at https://tools.ietf.org/html/rfc8505

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 9 Apr 2019 14:37:19 +0200

it seems RFCs are not in xml format.

So I will do without.  The BCP14 will not be referenced by an xml2rfc 
tag, but by some web automation.

Alex

Le 09/04/2019 à 14:18, Alexandre Petrescu a écrit :
>>> In private, a person clarified this to me, and I agree.  The 
>>> Canonical URL points to a document that says at its top that there 
>>> are actually two documents there (RFC 2119 and RFC 8174).  I have to 
>>> scroll down to see the second.  (it is a bit strange to me to see two 
>>> RFCs concatenated, but I guess it is an exception).
>>>
>>>> - I thought that a BCP document was just one RFC.  Here we seem to 
>>>> be talking about BCP-14 being both RFC2119 and RFC8174.
>>>> A google search on BCP-14 hits first on RFC 2119, and a document 
>>>> called 'bcp14' (not on RFC8174). https://tools.ietf.org/html/bcp14
>>>> The second hit is a page at RFC Editor which points to a "Canonical 
>>>> URL" towards https://www.rfc-editor.org/bcp/bcp14.txt which does not 
>>>> talk about RFC8174 either.
>>>> - finally, the text ends with 'as shown here', which invites my 
>>>> reading to think that what follows needs to be understood with these 
>>>> capitals. And what follows is the definition of terms like "IP-OBU", 
>>>> etc.  That is worrisome.  You can understand the worry if you read 
>>>> it as a whole:

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 9 Apr 2019 13:03:55 +0000

Just pick it from the last draft it didn’t change in a while....

Regards,

Pascal

> Le 9 avr. 2019 à 20:37, Alexandre Petrescu <[email-masked]> a écrit :
> 
> So I will do without.  The BCP14 will not be referenced by an xml2rfc tag, but by some web automation.
> 
> Alex
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 9 Apr 2019 15:14:31 +0200

Ah good to know the draft.

I went to it, and it talks about BCP 14 like this:

>     "OPTIONAL" in this document are to be interpreted as described in BCP 14
>     <xref target="RFC2119"/><xref target="RFC8174"/> when, and only when, they

Remark 'BCP 14' has no xml tags on it.  That means that the web 
automation will make it clickable, not the RFC itself.

There is however a stable "Canonical URL" which could be used to make 
BCP 14 clickable in the source code.  Except that I dont know what kind 
of xml tag to put on it.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 9 Apr 2019 15:54:09 +0200

Le 09/04/2019 à 02:04, Pascal Thubert (pthubert) a écrit :
>   I spent really a long time explaining why RFC 4861 does not cut it

Pascal, with all due respect.

You seem to be claiming RFC4861 does not work on WiFi altogether.

Is it so?

> itself. No magic will make that happen. I tried to help by indicating a 
> version of ND that was designed for radios and to my best knowledge will 
> work here. I understand that people will not trust that on “face value” 
> but I do not understand that people prefer something that was designed 
> before the concept of a radio link was even considered and is known not 
> to work.

Pascal,

We take ND efficient as important for wireless.

For OCB text I ponder over some text.

There is understanding.

Some small point that would help further is if I had an implementation 
available of ND efficient (Address Registration, etc) running at 5.9GHz 
in OCB mode in some cars.  Or some packet dump of it.

> In any fashion I cannot support a doc that lets the outside of the IETF 
> believe that RFC 4861 is suited for OCB. RFC 4861 survives on BSS thanks 
> to the association process that provides a signal for DNA and emulates 
> an Ethernet broadcast domain. Nothing like that on OCB.
> 

Pascal - I would like to ask you which hat you wear when you send the 
doc back?  (it is for my clarification as there are so many roles at 
IETF recently and I do not understand them all).

Yours,

Alex

>> incorporating into the draft. I see you are already discussing about 
>> that and I hope the WG reaches an agreement on how to modify current text.
>>
>> - I tend to agree with Alex in that I'd skip the RECOMMENDED part of 
>> the text (referring to RFC 8505). I agree that some pieces of RFC 8505 
>> could be adapted to be used in OCB, but I think using RECOMMENDED with 
>> further analysis within the WG is too much. I'd rather prefer that RFC 
>> 8505 is referenced in the draft as a solution that could be used as 
>> starting point to enhance ND over OCB (but we have agreed already in 
>> the WG that ND enhacements are outside the scope of current draft).
>>
>> - I'd appreciate if we all acknowledge here all the work Alex (and the 
>> rest of the authors) have been doing so far, as well as Pascal's help. 
>> Please, try to keep the discussion positive. That _always_ helps.
>>
>> Thanks,
>>
>> Carlos
>>
>> On Fri, Apr 5, 2019 at 5:09 PM Pascal Thubert (pthubert) 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>     Dear all;____
>>
>>     __ __
>>
>>     become a section 4.7.____
>>
>>     to relay packets for global addresses.____
>>
>>     current draft and could be reintroduced.____
>>
>>     __ __
>>
>>     Comments welcome : )____
>>
>>     __ __
>>
>>     Pascal____
>>
>>     __ __
>>
>>     *To:* Alexandre Petrescu <[email-masked]
>>     <mailto:[email-masked]>>
>>     *Cc:* [email-masked] <mailto:[email-masked]>
>>     draft-ietf-ipwave-ipv6-over-80211ocb-34____
>>
>>     __ __
>>
>>     Yes Alex. Also as an offer to help...____
>>
>>     __ __
>>
>>     Regards,____
>>
>>     __ __
>>
>>     Pascal____
>>
>>
>>     <mailto:[email-masked]>> a écrit :____
>>
>>         Pascal,____
>>
>>         Should we treat these two reviews (iotdir and intdir reviews)
>>         as just one?____
>>
>>         The contents appear to me to be the same.____
>>
>>         Alex____
>>
>>         Le 04/03/2019 à 12:24, Pascal Thubert a écrit :____
>>
>>             Reviewer: Pascal Thubert____
>>
>>             Review result: Not Ready____
>>
>>             __  __
>>
>>             Reviewer: Pascal Thubert____
>>
>>             Review result: Not ready. Need to clarify IEEE relationship, IOW which SDO____
>>
>>             defines the use of L2 fields, what this spec enforces vs. recognizes as being____
>>
>>             used that way based on IEEE work. The use of IPv6 ND requires a lot more____
>>
>>             thoughts, recommendation to use 6LoWPAN ND. The definition of a subnet is____
>>
>>             unclear. It seems that RSUs would have prefixes but that is not discussed.____
>>
>>             __  __
>>
>>             I am an assigned INT and IOT directorates reviewer for <____
>>
>>             draft-ietf-ipwave-ipv6-over-80211ocb-34 >. These comments were written____
>>
>>             primarily for the benefit of the Internet Area Directors. Document editors and____
>>
>>             shepherd(s) should treat these comments just like they would treat comments____
>>
>>             from any other IETF contributors and resolve them along with any other Last____
>>
>>             Call comments that have been received. For more details on the INT Directorate,____
>>
>>             seehttps://datatracker.ietf.org/group/intdir/about/____
>>
>>             __  __
>>
>>             Majors issues____
>>
>>             -----------------____
>>
>>             __  __
>>
>>             “____
>>
>>             __  __
>>
>>             o  Exceptions due to different operation of IPv6 network layer on____
>>
>>                    802.11 than on Ethernet.____
>>
>>             __  __
>>
>>             “____
>>
>>             Is this doc scoped to OCB or 802.11 in general? Is there an expectation that an____
>>
>>             implementer of IPv6 over Wi-Fi refers to this doc? Spelled as above, it seems____
>>
>>             that you are defining the LLC. Figure 1 shows the proposed adaptation layer as____
>>
>>             IEEE LLC work. Who defines those fields, IETF or IEEE, or mixed? Who defines____
>>
>>             their use? If this spec defines a new LLC header (vs. how to use an IEEE field)____
>>
>>               then it should be very clear, and the newly defined fields should be isolated____
>>
>>             from IEEE fields.____
>>
>>             __  __
>>
>>             "____
>>
>>                 The IPv6 packet transmitted on 802.11-OCB MUST be immediately____
>>
>>                 preceded by a Logical Link Control (LLC) header and an 802.11 header.____
>>
>>             __  __
>>
>>             "____
>>
>>             Is there anything new or specific to OCB vs. classical 802.11 operations?____
>>
>>             If/when this is echoing the IEEE specs then this text should not use uppercase____
>>
>>             but say something like: 'Per IEEE Std 802.11, the IPv6 packet transmitted on____
>>
>>             802.11-OCB is immediately  preceded by a Logical Link Control (LLC) header and____
>>
>>             an 802.11 header ...'____
>>
>>             __  __
>>
>>             different things? Why define both?____
>>
>>             __  __
>>
>>             "   An 'adaptation' layer is inserted between a MAC layer and the____
>>
>>                 Networking layer.  This is used to transform some parameters between____
>>
>>                 their form expected by the IP stack and the form provided by the MAC____
>>
>>                 layer.____
>>
>>             "____
>>
>>             Is this different from what an AP does when it bridges Wi-Fi to Ethernet? Is____
>>
>>             this IETF business?____
>>
>>             __  __
>>
>>             "____
>>
>>                 The Receiver and Transmitter Address fields in the 802.11 header MUST____
>>
>>                 contain the same values as the Destination and the Source Address____
>>
>>                 fields in the Ethernet II Header, respectively.____
>>
>>             "____
>>
>>             Same,  this is IEEE game isn't it?____
>>
>>             __  __
>>
>>             "____
>>
>>             __  __
>>
>>             Solutions for these problems SHOULD____
>>
>>                 consider the OCB mode of operation.____
>>
>>             "____
>>
>>             This is not specific enough to be actionable. I suggest to remove this sentence.____
>>
>>             It would be of interest for the people defining those solutions to understand____
>>
>>             the specific needs of OCB vs. Wi Fi, but I do not see text about that.____
>>
>>             __  __
>>
>>             "____
>>
>>             __  __
>>
>>             The method of forming IIDs____
>>
>>                 described in section 4 of [RFC2464] MAY be used during transition____
>>
>>                 time.____
>>
>>             "____
>>
>>             Contradicts section 4.3 that says____
>>
>>             "____
>>
>>             Among these types of____
>>
>>                 addresses only the IPv6 link-local addresses MAY be formed using an____
>>
>>                 EUI-64 identifier.____
>>
>>             "____
>>
>>             __  __
>>
>>             "____
>>
>>             __  __
>>
>>             This____
>>
>>                 subnet MUST use at least the link-local prefix fe80::/10 and the____
>>
>>                 interfaces MUST be assigned IPv6 addresses of type link-local.____
>>
>>             "____
>>
>>             If this is conforming IPv6 then the MUST is not needed.____
>>
>>             __  __
>>
>>             "____
>>
>>                 A subnet is formed by the external 802.11-OCB interfaces of vehicles____
>>
>>                 that are in close range (not by their in-vehicle interfaces).____
>>
>>             "____
>>
>>             Is the definition transitive? Do we really get a subnet?____
>>
>>               A is close to  B who is close to C .... to Z, makes Paris one subnet! Are you____
>>
>>               talking about a link, rather?____
>>
>>             __  __
>>
>>             "____
>>
>>                 The Neighbor Discovery protocol (ND) [RFC4861] MUST be used over____
>>
>>                 802.11-OCB links.____
>>
>>             "____
>>
>>             __  __
>>
>>             IPv6 ND is not suited for a non-broadcast network. How does DAD work?____
>>
>>             Maybe you could consider RFC 6775 / RFC 8505 instead.____
>>
>>             __  __
>>
>>             "____
>>
>>             In the moment the MAC address is changed____
>>
>>                 on an 802.11-OCB interface all the Interface Identifiers of IPv6____
>>
>>                 addresses assigned to that interface MUST change.____
>>
>>             "____
>>
>>             Why is that? This is unexpected, and hopefully wrong.____
>>
>>             __  __
>>
>>             Minor issues____
>>
>>             ---------------____
>>
>>             __  __
>>
>>             "   OCB (outside the context of a basic service set - BSS): A mode of____
>>
>>                 operation in which a STA is not a member of a BSS and does not____
>>
>>                 utilize IEEE Std 802.11 authentication, association, or data____
>>
>>                 confidentiality.____
>>
>>             __  __
>>
>>                 802.11-OCB: mode specified in IEEE Std 802.11-2016 when the MIB____
>>
>>                 attribute dot11OCBActivited is true.  Note: compliance with standards____
>>
>>                 and regulations set in different countries when using the 5.9GHz____
>>
>>                 frequency band is required.____
>>
>>             "____
>>
>>             __  __
>>
>>             Are these 2 different things?____
>>
>>             __  __
>>
>>             "____
>>
>>             Among these types of____
>>
>>               addresses only the IPv6 link-local addresses MAY be formed using an____
>>
>>                EUI-64 identifier.____
>>
>>             "____
>>
>>             This text should not be in a LL specific section since it deals with the other____
>>
>>             addresses. Maybe rename the section to "addressing" or something?____
>>
>>             __  __
>>
>>             "____
>>
>>                 For privacy, the link-local address MAY be formed according to the____
>>
>>                 mechanisms described in Section 5.2.____
>>
>>             "____
>>
>>             The MAY is not helpful. I suggest to remove the sentence that does not bring____
>>
>>             value vs. 5.2____
>>
>>             __  __
>>
>>             Could you make sections 4.3 and 4.5 contiguous?____
>>
>>             __  __
>>
>>             "____
>>
>>             If semantically____
>>
>>                 opaque Interface Identifiers are needed, a potential method for____
>>
>>                 generating semantically opaque Interface Identifiers with IPv6____
>>
>>                 Stateless Address Autoconfiguration is given in [RFC7217].____
>>
>>             __  __
>>
>>                 Semantically opaque Interface Identifiers, instead of meaningful____
>>
>>                 Interface Identifiers derived from a valid and meaningful MAC address____
>>
>>                 ([RFC2464], section 4), MAY be needed in order to avoid certain____
>>
>>                 privacy risks.____
>>
>>             __  __
>>
>>             ...____
>>
>>             __  __
>>
>>                 In order to avoid these risks, opaque Interface Identifiers MAY be____
>>
>>                 formed according to rules described in [RFC7217].  These opaque____
>>
>>                 Interface Identifiers are formed starting from identifiers different____
>>
>>                 than the MAC addresses, and from cryptographically strong material.____
>>
>>                 Thus, privacy sensitive information is absent from Interface IDs, and____
>>
>>                 it is impossible to calculate the initial value from which the____
>>
>>                 Interface ID was calculated.____
>>
>>             __  __
>>
>>             "____
>>
>>             Duplicate and mis ordered text, isn't it?____
>>
>>             __  __
>>
>>             " For this reason, an attacker may realize many____
>>
>>                 attacks on privacy.____
>>
>>             "____
>>
>>             Do we attack privacy? Maybe say that privacy is a real concern, and maybe move____
>>
>>             that text to security section?____
>>
>>             __  __
>>
>>             "____
>>
>>                 The way Interface Identifiers are used MAY involve risks to privacy,____
>>
>>                 as described in Section 5.1.____
>>
>>             "____
>>
>>             Also duplicate____
>>
>>             __  __
>>
>>             Nits____
>>
>>             ------____
>>
>>             __  __
>>
>>             "____
>>
>>                 IP packets MUST be transmitted over 802.11-OCB media as QoS Data____
>>
>>                 frames whose format is specified in IEEE Std 802.11.____
>>
>>             "____
>>
>>             Please add link to the reference____
>>
>>             __  __
>>
>>             " the 802.11 hidden node"____
>>
>>             Do not use 802.11 standalone (multiple occurrences).____
>>
>>             => "the IEEE Std. 802.11 [ ref ] hidden node", or just "the hidden terminal".____
>>
>>             __  __
>>
>>             BCP 14 text:____
>>
>>             __  __
>>
>>             Suggest to use this text:____
>>
>>             “____
>>
>>                 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",____
>>
>>                 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and____
>>
>>                 "OPTIONAL" in this document are to be interpreted as described in____
>>
>>                 https://tools.ietf.org/html/bcp14  https://tools.ietf.org/html/bcp14____
>>
>>                 [https://tools.ietf.org/html/rfc2119][RFC8174] when, and only when, they____
>>
>>                 appear in all capitals, as shown here.____
>>
>>             __  __
>>
>>             “____
>>
>>             __  __
>>
>>             All the best____
>>
>>             __  __
>>
>>             Pascal____
>>
>>             __  __
>>
>>             __  __
>>
>>             __  __
>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 9 Apr 2019 16:11:33 +0200

Le 09/04/2019 à 00:37, Brian E Carpenter a écrit :
>>> This subnet MUST use at least the link-local prefix fe80::/10 and
>>> the interfaces MUST be assigned IPv6 addresses of type
>>> link-local. " If this is conforming IPv6 then the MUST is not
>>> needed.
>> 
>> The spec in question is RFC 2464.  I consider that to be what we
>> need to conform to.  That spec says 'fe80::/64'.  But that 64 is
>> wrong.
> 

YEs, it is valid.

> I also don't understand the meaning of "at least" in this sentence.

"At least" means that at least the link-local prefix must be present on 
the interface.  More than LL prefix, there could be a global prefix or 
an ULA prefix or several of them.

"At least" does not mean "the value should be at least 10" in that phrase.

Do you think we should say otherwise?

>> Hence the clarification.
> 
> If you specify the prefix as /10, you have to define how the other
> 118 bits are constructed. Specifying how the final 64 bits are
> constructed is insufficient.

I agree.  I could add text that suggests the use of 0s between position 
64 and the position ending the prefix.  Would this be ok with you?

> Also, it seems to me that you should cite RFC8064 everywhere that you
> cite RFC2464, since the EUI-64 mechanism is now considered obsolete.

It is considered obsolete ok, but are you sure?

There are enourmous deployments of embedded computers with kernels 2.x 
that do that EUI-64 mechanism. It will take long to disappear.

An IPv6-over-OCB document today that does not do EUI-64 risks to not be 
implemented.

> I also think the citation of draft-hinden-6man-rfc2464bis is
> confusing, since it seems to be comatose.

Ah no!  Resurrect that, otherwise I remove the ref :-)

> 
>> 
>> Do you disagree with it?
>> 
>> (the reasons why I put there /10 and not /64 are the following: LLs
>> work in linux with any length between 10 and 64, the ND spec does
>> not restrict to 64,
> 
> No, but IPv6-over-foo documents usually do apply that restriction,
> rather than define 118-bit IIDs.

It is good to know about practice in IPv6-over-foo documents.

What should I do in the IP-over-OCB document: continue that restriction? 
or define 118bit IID with filling in 0s between 64 and position of last 
bit of prefix?

(in implementation I already did fe80:1::1/32 as a link-local address on 
OCB at 5.9GHz; the prefix is fe80:1::/32 and the IID is ::1 of length 96 
with 32 leading 0 bits; it works between cars)

Alex

> 
> Brian
> 
>> the IANA starts at 10, and probably other reasons; there is a
>> recent I-D about this LL prefix length:

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 9 Apr 2019 16:04:48 +0000

Hi Pascal/Alex,
  Upleveling this a bit.

> On Apr 9, 2019, at 9:54 AM, Alexandre Petrescu <[email-masked]> wrote:
> 
> 
> 

Pascal, we do know that RFC4861 ND *does* work on 802.11 OCB networks as witnessed by the several existing implementations. Of course, there are cases where it may may be sub optimal and this is why I was fine with explaining some of the shortfalls with an informational pointer to RFC8505 (Thanks for helping with the text!! I think it provides a great overview). I personally do not think mandating RFC8505 is warranted at this point. 

Thanks
Suresh

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 9 Apr 2019 16:50:27 +0000

Hello Suresh 

The piece in ND that yields trouble is the piece that needs multicast. The most trouble is with DAD. DAD will work on OCB only if the cars are in sight at the moment it is tried. Is that realistic?

I documented simple failure scenarios.  Like cars have duplicate addresses but boot far away and then meet. Or they meet a common third party. The response I was given involves magic that is not documented.

Now, there are other scenarios that do not fail. So “doesn’t work “ is an exaggeration. I said “does not cut it” and that means does not pass a bar of satisfaction level where a basic function like DAD is provided. The document should indicate what can be expected to work satisfactorily and what needs more work. It must not give the impression that ND is fully satisfactory and that the doc is the end of it.

My proposed text indicates that at least DAD must be ensured some other way because booting an interface with an ll address and doing DAD at that time and forever is not s good model for the reasons I indicated.

RFC 8505 is a great way to progress but I see that the WG needs time to make up its mind. But it is reasonable to expect that the WG considers the work done by peers that worked on similar space. The document doesn’t mention it at all. There is space between recommending and ignoring where we could find an agreement. 

I also see that even if it helps a lot, RFC 8505 is not the end of it for OCB in particular when cars cross for a very short time. How do they know about each other? There must be some L3 beacon like a fast RA ala MIPv6. Is there a point resolving MAC addresses? Maybe unicast IP can just be sent over broadcast MAC. How do we do a DAD? Maybe an external Registry? Or just pseudo random numbers and statistical chances? What is a link where a link local must be unique, how do we build a subnet and defend addresses there?

All good questions that the doc doesn’t even approach. And there are probably more. This is what I expect to find in an RFC called IPv6 over OCB.

The doc has interesting text about what is OCB that will be useful to do IPv6 over it, but it is not true to its title and doesn’t even explain what the problems are before they can be solved. It doesn’t say that covering that is not in scope either so it leaves the impression of a done deal where all the difficult work is left to be done.

At the end of the day I’m not clear why we want to publish it. Maybe as an informational description of OCB to prepare for the work in the WG? I’d be fine with that but then the title should change.

All the best,

Pascal

> Le 10 avr. 2019 à 00:05, Suresh Krishnan <[email-masked]> a écrit :
> 
> Hi Pascal/Alex,
>  Upleveling this a bit.
>

---

From: 神明達哉 <[email-masked]>
Date: Tue, 9 Apr 2019 10:14:09 -0700

At Tue, 9 Apr 2019 16:11:33 +0200,

[...]
> or define 118bit IID with filling in 0s between 64 and position of last

I don't have a strong opinion about specifically what this doc should
say, but "MUST use at least the link-local prefix fe80::/10"
shouldn't be interpreted as if we could use fe80:1::1 as a valid IPv6
link-local address without violating the current addressing
architecture (RFC4291, Section 2.5.6).  If this text can be
interpreted that way, we should definitely revise it.

> with 32 leading 0 bits; it works between cars)

It's a violation of the current addressing architecture.  Anyone can
do whatever they want in their pet implementations, but unless/until
this document updates RFC4291 so that it explicitly allows a non-0
value in the intermediate 54 bits, it has nothing to do with this
current discussion.  Non-compliant implementations can work as their
author intends, especially if they don't care about
interoperability.  But that doesn't make it magically standard
compliant.

--
JINMEI, Tatuya

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 9 Apr 2019 22:04:14 +0200

Pascal,

Le 09/04/2019 à 18:50, Pascal Thubert (pthubert) a écrit :
[...]

> At the end of the day I’m not clear why we want to publish it. Maybe
> as an informational description of OCB to prepare for the work in the
> WG?

There were about 3 bofs on this and long discussions on chartering or no 
chartering, and what to charter.

Your comment above sounds to me as if we wanted to charter again now.

> I’d be fine with that but then the title should change.

I think this is not serious.  We changed the title many times.  The last 
title was contributed extensively by a very knowledgeable person.

This makes me say the following:

I would like to ask you something else: why do you insist so much on 
this?  What fundamental issue you think is at stake (beyond text or RFC 
referrals)?  Sounds as if you have some other strong reason pushing you 
to ask these things...  maybe some personal issue against me, or some 
other interest?

Alex

>> Hi Pascal/Alex, Upleveling this a bit.
>> 
>>>> Hello Carlos I think we’re a bit stuck. I spent really a long
>>>> time explaining why RFC 4861 does not cut it
>>> 
>> Pascal, we do know that RFC4861 ND *does* work on 802.11 OCB
>> networks as witnessed by the several existing implementations. Of
>> course, there are cases where it may may be sub optimal and this is
>> why I was fine with explaining some of the shortfalls with an
>> informational pointer to RFC8505 (Thanks for helping with the
>> text!! I think it provides a great overview). I personally do not
>> think mandating RFC8505 is warranted at this point.
>> 
>> Thanks Suresh

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 9 Apr 2019 22:13:30 +0200

Tatuya,

Thank you for the message.

Le 09/04/2019 à 19:14, 神明達哉 a écrit :
> At Tue, 9 Apr 2019 16:11:33 +0200, Alexandre Petrescu
> <[email-masked] <mailto:[email-masked]>>
> wrote:
> 
>>>>> "
>>>>> 
>>>>> This subnet MUST use at least the link-local prefix fe80::/10
>>>>> and the interfaces MUST be assigned IPv6 addresses of type 
>>>>> link-local. " If this is conforming IPv6 then the MUST is
>>>>> not needed.
> [...]
>>>> Do you disagree with it?
>>>> 
>>>> (the reasons why I put there /10 and not /64 are the following:
>>>> LLs work in linux with any length between 10 and 64, the ND
>>>> spec does not restrict to 64,
>>> 
>>> No, but IPv6-over-foo documents usually do apply that
>>> restriction, rather than define 118-bit IIDs.
>> 
>> What should I do in the IP-over-OCB document: continue that
>> restriction? or define 118bit IID with filling in 0s between 64 and
>> position of last bit of prefix?
> 
> I don't have a strong opinion about specifically what this doc
> should say, but "MUST use at least the link-local prefix fe80::/10" 
> shouldn't be interpreted as if we could use fe80:1::1 as a valid
> IPv6 link-local address without violating the current addressing 

Thank you for the suggestion.

I would like to ask you whether I can ask you to propose a formulation
of using fe80::/10 without violating RFC4291 2.5.6?

Maybe: "The OCB interface MAY use IPv6 link-local addresses with prefix
length 10 without violating RFC4291 2.5.6, provided such address is
allowed by IANA".

Would this text be ok?

Or do you rather think we should not allow LLs on OCB with any other
prefix than fe80::/64?

>> (in implementation I already did fe80:1::1/32 as a link-local
>> address on OCB at 5.9GHz; the prefix is fe80:1::/32 and the IID is
>> ::1 of length 96 with 32 leading 0 bits; it works between cars)
> 
> It's a violation of the current addressing architecture.

But it does not violate IANA allocation, right?

> Anyone can do whatever they want in their pet implementations, but
> unless/until this document updates RFC4291 so that it explicitly
> allows a non-0 value in the intermediate 54 bits, it has nothing to
> do with this current discussion.  Non-compliant implementations can
> work as their author intends, especially if they don't care about 

Thank you for the suggestion.

Can I dare to read you suggestion as implying that we should add an 
"Updates: 4291" text on the first page of the draft?

Or should I interpret it as a suggestion to not even try to update RFC4291?

About the doubting of authors interoperability worries: the authors do 
care extensively about interoperability.  The interoperability of LLs, 
at this time, is being checked against linux versions, and some BSD flavor.

Alex

> -- JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Tue, 9 Apr 2019 13:46:20 -0700

At Tue, 9 Apr 2019 22:13:30 +0200,

> length 10 without violating RFC4291 2.5.6, provided such address is

This is still ambiguous to me, but if its intent is to allow
fe80:1::1 without violating RFC4291 2.5.6, I don't think it's okay.
The RFC is super clear that the intermediate 54 bits are all 0:

   |   10     |
   |  bits    |         54 bits         |          64 bits           |
   +----------+-------------------------+----------------------------+
   |1111111010|           0             |       interface ID         |
   +----------+-------------------------+----------------------------+

Declaring the 10 bits as "(link-local) prefix" can't change this fact.

> Or do you rather think we should not allow LLs on OCB with any other

(Again, it's more about the value of intermediate 54 bits than /10 vs
/64, but anyway) not necessarily; it may be possible that the
ipwave-ipv6-over-80211ocb spec has a convincing reason for making an
exception to RFC4291 (right now I don't have sufficient understanding
of ipv6-over-80211ocb to judge that point).

> "Updates: 4291" text on the first page of the draft?

Yes, if this specification needs the intermediate 54 bits to have a
non-0 value.  In that case I'd suggest making it clear which part of
RFC4291 this spec updates in which way, i.e, updating Section 2.5.6 of
RFC4291 to allow a non-0 value for the intermediate of 54 bits of an
address matching fe80::/10, and use it as an IPv6 link-local address.
This will inevitably require quite a high bar to pass IESG evaluations
and an IETF last call, but you'll probably find it worth the hassle if
this point is critical for the spec.

On the other hand, if this is something this spec can live without,
not proposing that update will certainly help it move forward faster
and with less controversy.  In that case, some part of the wording
about the "prefix length" will have to be revised, so that it won't be
incorrectly interpreted as allowing fe80:1::1.

I have no suggestion about which option to take; it's up to you.

Whether I support the update in the evaluation/last call phase if and
when this update is proposed, is a totally different question.

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 10 Apr 2019 11:30:32 +1200

Bonjour Alexandre,

> Do you think we should say otherwise?

To me there is nothing in the actual text to tell me that "at least"
qualifies the "/10". I think you could rephrase as
"This subnet's prefix MUST lie within the link-local prefix fe80::/10 ..."

However, see Jinmei's messages about conformance with RFC 4291.

I think there might be unexpected side effects from using an
address like fe80:1::1. What if some code uses matching with
fe80::/64 to test if an address is link-local? I agree that
would be faulty code, but you would be the first to discover it.

Regards
    Brian
 
> .

---

From: Ole Troan <[email-masked]>
Date: Wed, 10 Apr 2019 10:22:37 +0200

> would be faulty code, but you would be the first to discover it.

Indeed.
If you absoultely must cut and paste text from 2464:

5.  Link-Local Addresses

   The IPv6 link-local address [AARCH] for an Ethernet interface is
   formed by appending the Interface Identifier, as defined above, to
   the prefix FE80::/64.

       10 bits            54 bits                  64 bits
     +----------+-----------------------+----------------------------+
     |1111111010|         (zeros)       |    Interface Identifier    |
     +----------+-----------------------+----------------------------+

I presume there is support for brining 802.11p and other 802.3 links?
And that the MAC address length of this link type is also 48 bits?

If the two assumptions above hold, then I see zero justification for pushing the 64 bit boundary in this draft.

Ole

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 10 Apr 2019 10:58:07 +0200

> If you absoultely must cut and paste text from 2464:

YEs, that is how we started.  We cut and paste from 2464.

>     formed by appending the Interface Identifier, as defined above, to

I not understand the question?  Please clarify what do you mean 
(bringing, binning?)  This is for 802.11 mode OCB.  802.11p no longer 
exists.  802.3 does not need a spec because it has rfc2464.

The interface 802.11-OCB is not an 802.3 interface.

Let me try to understand what do you mean?

> And that the MAC address length of this link type is also 48 bits?

YEs, the length of MAC address on 802.11 mode OCB is also 48.

> If the two assumptions above hold, then I see zero justification for pushing the 64 bit boundary in this draft.

Let me try  to understand the first assumption.

Alex

---

From: Ole Troan <[email-masked]>
Date: Wed, 10 Apr 2019 11:04:45 +0200

> I not understand the question?  Please clarify what do you mean (bringing, binning?)  This is for 802.11 mode OCB.  802.11p no longer exists.  802.3 does not need a spec because it has rfc2464.

Fingers stumbling. Bridging.

Ole

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 10 Apr 2019 11:22:42 +0200

Le 10/04/2019 à 11:04, Ole Troan a écrit :
>>> I presume there is support for bridging 802.11p and other 802.3 links?

In the IP-OBUs that I know there is IP forwarding between 802.11-OCB 
(earlier 802.11p) and 802.3, not bridging.

In some IP-OBU (Internet Protocol On-Board Unit) some non-OCB interfaces 
are indeed bridged.  E.g. the Ethernet interface is bridged to the WiFi 
interface; that helps with DHCP, tcpdump and others to see one a single 
- bridged - interface.

Bridging may be, but it is not a MUST.  There is no necessarily any 
bridging between the 802.11-OCB interface and other interface, neither 
bridging between the multiple 802.11-OCB interfaces that might be 
present in the same computer.

Do you assume bridging of 802.11-OCB interface to Ethernet interface is 
always there?

Note: I also heard many comments suggesting that EAL is akin to 
'bridging'.  I do not know whether you refer to that perspective.  If 
yes, we can discuss it separately.

Alex

[...]

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 10 Apr 2019 11:25:49 +0200

Le 10/04/2019 à 11:22, Alexandre Petrescu a écrit :
[...]

>>>> I presume there is support for bridging 802.11p and other 802.3 links?

To make it short: I tried it, it does not work. (bridging 11p to .3 
Ethernet).

Alex

---

From: Ole Troan <[email-masked]>
Date: Wed, 10 Apr 2019 12:28:16 +0200

Alexandre,

Right, so it doesn’t sound like you have any reason to be different from RFC2464.
Just reference or copy that text (section 5, rfc2464).

Ole

> On 10 Apr 2019, at 11:22, Alexandre Petrescu <[email-masked]> wrote:
> 
> 
> 
> In the IP-OBUs that I know there is IP forwarding between 802.11-OCB (earlier 802.11p) and 802.3, not bridging.
> 
> In some IP-OBU (Internet Protocol On-Board Unit) some non-OCB interfaces are indeed bridged.  E.g. the Ethernet interface is bridged to the WiFi interface; that helps with DHCP, tcpdump and others to see one a single - bridged - interface.
> 
> Bridging may be, but it is not a MUST.  There is no necessarily any bridging between the 802.11-OCB interface and other interface, neither bridging between the multiple 802.11-OCB interfaces that might be present in the same computer.
> 
> Do you assume bridging of 802.11-OCB interface to Ethernet interface is always there?
> 
> Note: I also heard many comments suggesting that EAL is akin to 'bridging'.  I do not know whether you refer to that perspective.  If yes, we can discuss it separately.
> 
> Alex
> 
> [...]
> 
> _______________________________________________
> Int-dir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-dir

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 10 Apr 2019 13:41:32 +0200

You said: if OCB is still 48bit, and if there is bridging OCB-Ethernet, 
then no reason to be different than rfc2464.

I said: OCB is still 48bit, but there is no bridging OCB-Ethernet.

The conclusion is: there is reason to be different from RFC 2464.

Now, you give a different conclusion.

Excuse me, I would like to clarify this please?

Alex

---

From: Ole Troan <[email-masked]>
Date: Wed, 10 Apr 2019 14:40:45 +0200

> You said: if OCB is still 48bit, and if there is bridging OCB-Ethernet, then no reason to be different than rfc2464.
> 

Why?

> Excuse me, I would like to clarify this please?

Clarify what?
That a link-layer that looks an awfully lot like Ethernet should not follow the 64-bit boundary and the definition of the link-local address mapping of rfc2464?
Section 4.5.1 is already clear on that.

I think the only thing we are asking you is to change the following paragraph:

OLD:

NEW:
   A subnet is formed by the external 802.11-OCB interfaces of vehicles
   that are in close range (not by their in-vehicle interfaces). A node
   MUST form a link-local address on this link.

Not quite sure what value that paragraph adds in the first place. You could probable remove it.

Cheers,
Ole

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 10 Apr 2019 13:44:37 +0000

Hello Ole:

Better remove, it is wrong anyway. 

Because it is transitive, the description extends the so-called subnet step by step to a potentially large number of cars such that there is no broadcast domain that covers them all. If there is no broadcast domain and no multicast emulation like a BSS does, how can we run ND? Yes, it works with 3 cars in a lab.

The description looks like it is confused with the MANET / 6LoWPAN concept of link, whereby my link joins the collection of nodes that my radio can reach.

All the best,

Pascal

> From: Ole Troan <[email-masked]>
> Sent: mercredi 10 avril 2019 20:41
> Cc: Pascal Thubert (pthubert) <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]; draft-ietf-ipwave-ipv6-over-
> [email-masked]; Brian E Carpenter <[email-masked]>
> Subject: Re: [Int-dir] Intdir early review of draft-ietf-ipwave-ipv6-over-
> 80211ocb-34 - 'conforming IPv6' - fe80::/10 vs fe80::/64
> 
> That a link-layer that looks an awfully lot like Ethernet should not follow the
> 64-bit boundary and the definition of the link-local address mapping of
> rfc2464?
> >>>>>>> qualifies the "/10". I think you could rephrase as "This
> >>>>>>> subnet's prefix MUST lie within the link-local prefix fe80::/10 ..."
> >>>>>>>
> >>> In some IP-OBU (Internet Protocol On-Board Unit) some non-OCB
> interfaces are indeed bridged.  E.g. the Ethernet interface is bridged to the
> WiFi interface; that helps with DHCP, tcpdump and others to see one a single -
> bridged - interface.
> >>>
> >>> Bridging may be, but it is not a MUST.  There is no necessarily any bridging
> between the 802.11-OCB interface and other interface, neither bridging
> between the multiple 802.11-OCB interfaces that might be present in the
> same computer.
> >>>
> 'bridging'.  I do not know whether you refer to that perspective.  If yes, we can
> discuss it separately.
> >>>
> >>> Alex
> >>>
> >>> [...]
> >>>
> >>>>>> If the two assumptions above hold, then I see zero justification for
> pushing the 64 bit boundary in this draft.
> >>>>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 10 Apr 2019 16:01:36 +0200

Le 10/04/2019 à 14:40, Ole Troan a écrit :
>> You said: if OCB is still 48bit, and if there is bridging
>> OCB-Ethernet, then no reason to be different than rfc2464.
>> 

You said if OCB-Ethernet bridging then no need of update.  Then you
concluded differently.  That needs clarification.

> That a link-layer that looks an awfully lot like Ethernet

It looks an awful lot like Ethernet, but it can not be bridged to it. 
The 'brctl' and 'brconf' software issue errors when trying to link OCB 
interface to Ethernet interface.

> [That a link-layer that looks an awfully lot like Ethernet] should not
> follow the 64-bit boundary and the definition of the link-local
> address mapping of rfc2464? Section 4.5.1 is already clear on that.

If OCB can not be bridged to Ethernet then OCB interfaces are free to 
have a 65bit IID, without fearing lack of interoperability to an 
Ethernet interface with 64bit IID.  The IP forwarding does not care 
about IID length, and there is no bridging.

> OLD: A subnet is formed by the external 802.11-OCB interfaces of
> interfaces).  This subnet MUST use at least the link-local prefix
> fe80::/10 and the interfaces MUST be assigned IPv6 addresses of type
> link-local.
> 
> NEW: A subnet is formed by the external 802.11-OCB interfaces of
> interfaces). A node MUST form a link-local address on this link.

Makes sense, I will add it.

Then somebody will ask what is the prefix length of the LL prefix on 
OCB?  What reference should I give to the person asking?

The reference is RFC2464 that says 64bit IID.  But that is for Ethernet 
and EThernet can not be bridged to OCB.

> could probable remove it.

The value in mentioning /10 is that it works on OCB (it works also on 
Ethernet but not on all OSs, and so  it may risk violating a section).

Alex

> Cheers, Ole
>>> Alexandre, Right, so it doesn’t sound like you have any reason to
>>> be different from RFC2464. Just reference or copy that text
>>> (section 5, rfc2464). Ole
>>>>>>>> To me there is nothing in the actual text to tell me
>>>>>>>> that "at least" qualifies the "/10". I think you could
>>>>>>>> rephrase as "This subnet's prefix MUST lie within the
>>>>>>>> link-local prefix fe80::/10 ..."
>>>>>>>> 
>>>>>>>> I think there might be unexpected side effects from
>>>>>>>> using an address like fe80:1::1. What if some code uses
>>>>>>>> matching with fe80::/64 to test if an address is
>>>>>>>> link-local? I agree that would be faulty code, but you
>>>>>>>> would be the first to discover it.
>>>>>>> Indeed. If you absoultely must cut and paste text from
>>>>>>> 2464:
>>>>>> 
>>>>>>> 5.  Link-Local Addresses The IPv6 link-local address
>>>>>>> [AARCH] for an Ethernet interface is formed by appending
>>>>>>> the Interface Identifier, as defined above, to the prefix
>>>>>>> FE80::/64. 10 bits            54 bits                  64
>>>>>>> bits 
>>>> 
>>>> In the IP-OBUs that I know there is IP forwarding between
>>>> 802.11-OCB (earlier 802.11p) and 802.3, not bridging.
>>>> 
>>>> interfaces are indeed bridged.  E.g. the Ethernet interface is
>>>> bridged to the WiFi interface; that helps with DHCP, tcpdump
>>>> and others to see one a single - bridged - interface.
>>>> 
>>>> Bridging may be, but it is not a MUST.  There is no necessarily
>>>> any bridging between the 802.11-OCB interface and other
>>>> interface, neither bridging between the multiple 802.11-OCB
>>>> interfaces that might be present in the same computer.
>>>> 
>>>> 'bridging'.  I do not know whether you refer to that
>>>> perspective.  If yes, we can discuss it separately.
>>>> 
>>>> Alex
>>>> 
>>>> [...]
>>>> 
>>>>>>> If the two assumptions above hold, then I see zero
>>>>>>> justification for pushing the 64 bit boundary in this
>>>>>>> draft.
>>>>>> 
>>>> _______________________________________________ Int-dir mailing
>>>> list [email-masked] 
>> _______________________________________________ Int-dir mailing
>> list [email-masked]

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 10 Apr 2019 16:19:40 +0200

> Better remove, it is wrong anyway.

Pascal, fe80::/10 is not wrong, because:
- using fe80::/10 on OCB works ok.
- using fe80::/10 on Cisco, linux and openbsd works ok.
- IANA allows fe80::/10 for link-local addresses.

Why do you think fe80::/10 is wrong?

> Because it is transitive, the description extends the so-called 
> subnet step by step to a potentially large number of cars such that 
> there is no broadcast domain that covers them all.

Pascal - the extension of OCB subnets happens with IP routing
(forwarding between IP OCB interfaces), not with bridging.  The IP
routing does not forward link-locally scoped IP packets.

There is indeed no single broadcast domain that covers them all.  But 
there is potentially a multicast scope that could cover them all.  I 
never tried it, but I guess it may be necessary.

There is no single broadcast domain for all these numerous cars in a 
convoy also because each car uses not one OCB interface but three OCB 
interfaces, each situated in a distinct IP subnet.

> If there is no broadcast domain and no multicast emulation like a BSS
> does, how can we run ND? Yes, it works with 3 cars in a lab.

If it is ironic...

Between each pair of cars (or triplet of cars some times) there is a 
distinct IP subnet; that IP subnet links the front bumper of one car to 
the rear bumper of the other car (or the rear of a car to two fronts of 
the other two cars, if in triangle formation).  These IP subnets support 
well IPv6 and ND works ok.

It works with 3 cars on track, not just in the garage.  They form linear 
convoy, or triangle formation some times.

> The description looks like it is confused with the MANET / 6LoWPAN 
> concept of link, whereby my link joins the collection of nodes that 
> my radio can reach.

No, there is no  confusion in writing.  There is no confusion in 
experimenting.

There may be confusion in reading.

We do not use MANET protocols neither 6LoWPAN protocol, nor their 
concepts of links, nor 802.15.4.  They are valuable in other contexts.

Alex

> 
> All the best,
> 
> Pascal
> 
>> -----Original Message----- From: Ole Troan <[email-masked]> 
>> Sent: mercredi 10 avril 2019 20:41 To: Alexandre Petrescu 
>> <[email-masked]> Cc: Pascal Thubert (pthubert) 
>> <[email-masked]>; [email-masked]; [email-masked]; 
>> [email-masked]; draft-ietf-ipwave-ipv6-over- 
>> [email-masked]; Brian E Carpenter 
>> <[email-masked]> Subject: Re: [Int-dir] Intdir early 
>> review of draft-ietf-ipwave-ipv6-over- 80211ocb-34 - 'conforming 
>> IPv6' - fe80::/10 vs fe80::/64
>> 
>> Clarify what? That a link-layer that looks an awfully lot like 
>> Ethernet should not follow the 64-bit boundary and the definition 
>> of the link-local address mapping of rfc2464? Section 4.5.1 is 
>> already clear on that.
>> 
>> fe80::/10 and the interfaces MUST be assigned IPv6 addresses of 
>> type link-local.
>> 
>>>> Alexandre, Right, so it doesn’t sound like you have any reason 
>>>> to be different from
>> RFC2464.
>>>> Just reference or copy that text (section 5, rfc2464). Ole
>>>>>>>>>> "At least" does not mean "the value should be at 
>>>>>>>>>> least 10" in that
>> phrase.
>>>>>>>>>> 
>>>>>>>>> that "at least" qualifies the "/10". I think you 
>>>>>>>>> could rephrase as "This subnet's prefix MUST lie 
>>>>>>>>> within the link-local prefix fe80::/10 ..."
>>>>>>>>> 
>>>>>>>>> using an address like fe80:1::1. What if some code 
>>>>>>>>> uses matching with fe80::/64 to test if an address
>>>>>>>>> is link-local? I agree that would be faulty code,
>>>>>>>>> but you would be the first to discover it.
>>>>>>>> [AARCH] for an Ethernet interface is formed by 
>>>>>>>> appending the Interface Identifier, as defined above, 
>>>>>>>> to the prefix FE80::/64. 10 bits            54 bits 64
>>>>>>>> bits 
>>>>> 802.11-OCB
>> bridged to the WiFi interface; that helps with DHCP, tcpdump and 
>> others to see one a single - bridged - interface.
>>>>> 
>> between the 802.11-OCB interface and other interface, neither 
>> 'bridging'.  I do not know whether you refer to that perspective. 
>> If yes, we can discuss it separately.
>>>>> 
>>>>> Alex
>>>>> 
>>>>> [...]
>>>>> 
>>>>>>>> justification for
>>>>> _______________________________________________ Int-dir 
>>>>> mailing list [email-masked]

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 10 Apr 2019 16:38:41 +0200

> I documented simple failure scenarios.  Like cars have duplicate 
> addresses but boot far away and then meet.

(I can tell you we worried about this boot-remote and then meet several
times in practice.

Because of that worry there is 'discovery' in the problem statement 
IPWAVE draft, please read it.

In practice we tried several times to boot cars far away and then meet;
it worked; maybe it worked because they never formed same address, or
because we used manually assigned pre-planned Link-Local addresses like
fe80:1::1/32 to be sure there is no conflict, but it worked.)

> Or they meet a common third party. The response I was given involves
> magic that is not documented.

The reasons why two cars boot-remote and then meet work ok are the 
following:
- both advertise RAs rapidly, in addition to responding to RSs.
- each self-forms an IPv6 LL out of its MAC address, which is a little
   bit, unique.
- to ensure more uniqueness we also use manually assigned link-local
   addresses, like fe80:1::1/32 between car 1 and 2, and fe80:2::1/32
   between car 2 and 3.

I am not sure which undocumented magic you refer to in what I said earlier.

I could remember I talked about channel setup between cars.

That may be considered as magic.

There is a need to assign the channels to interfaces in such a way to
avoid interference and maximize the closures.

In WiFi non-OCB this happens more or less automatically with intelligent
device drivers that listen to availability and the suggest to human
user some choices.  Also, some human planners of Access Point
deployments do make some choices by some algorithm of their preference,
to avoid overlaps, distribute nearby channels like 1-6-11 rather than 
1-2-3, etc.

This is sometimes called magic.  There is no standard of it.  It is like
when you make an IP addressing architecture for a large router deployment.

In OCB there there is no automation of how to set up channels between
cars and RSUs.  And there are not 11 channels, but just 5.  There is 
some recommendation of fixed allocation from regulators (e.g. use safety 
apps on Control Channel and use entertainment apps on Service Channel), 
but that is by no means an ultimate recommendation, nor is there a need 
to abide to it fully.  So people decide channels by some magic of their own.

My own magic for channel allocation could be described here.  It needs 
to have LTE access to a Internet cloud server that tells the cars their 
roles (leader, 1st follower, 2nd follower, etc).  But that would be 
another document, not IPv6-over-OCB.

Do you disagree with this direction?

Do you want just brief text about channel allocation in support of 
subnet formation in the OCB draft, in order to unmagic the magic? (not 
that is the first time I write it and risk disappear later).

Alex

> 
> Now, there are other scenarios that do not fail. So “doesn’t work “ 
> is an exaggeration. I said “does not cut it” and that means does not 
> pass a bar of satisfaction level where a basic function like DAD is 
> provided. The document should indicate what can be expected to work 
> satisfactorily and what needs more work. It must not give the 
> impression that ND is fully satisfactory and that the doc is the end 
> of it.
> 
> My proposed text indicates that at least DAD must be ensured some 
> other way because booting an interface with an ll address and doing 
> DAD at that time and forever is not s good model for the reasons I 
> indicated.
> 
> RFC 8505 is a great way to progress but I see that the WG needs time 
> to make up its mind. But it is reasonable to expect that the WG 
> considers the work done by peers that worked on similar space. The 
> document doesn’t mention it at all. There is space between 
> recommending and ignoring where we could find an agreement.
> 
> I also see that even if it helps a lot, RFC 8505 is not the end of
> it for OCB in particular when cars cross for a very short time. How
> do they know about each other? There must be some L3 beacon like a
> fast RA ala MIPv6. Is there a point resolving MAC addresses? Maybe
> unicast IP can just be sent over broadcast MAC. How do we do a DAD?
> Maybe an external Registry? Or just pseudo random numbers and
> statistical chances? What is a link where a link local must be
> unique, how do we build a subnet and defend addresses there?
> 
> All good questions that the doc doesn’t even approach. And there are 
> probably more. This is what I expect to find in an RFC called IPv6 
> over OCB.
> 
> The doc has interesting text about what is OCB that will be useful
> to do IPv6 over it, but it is not true to its title and doesn’t even 
> explain what the problems are before they can be solved. It doesn’t 
> say that covering that is not in scope either so it leaves the 
> impression of a done deal where all the difficult work is left to be 
> done.
> 
> as an informational description of OCB to prepare for the work in
> the WG? I’d be fine with that but then the title should change.
> 
> All the best,
> 
> Pascal
> 
>> course, there are cases where it may may be sub optimal and this
>> is why I was fine with explaining some of the shortfalls with an

---

From: NABIL BENAMAR <[email-masked]>
Date: Wed, 10 Apr 2019 16:40:58 +0100

Do we still talk about broadcast in IPv6 ?

On Wed, Apr 10, 2019, 14:45 Pascal Thubert (pthubert) <[email-masked]>
wrote:

> Because it is transitive, the description extends the so-called subnet
> step by step to a potentially large number of cars such that there is no
> broadcast domain that covers them all. If there is no broadcast domain and
> no multicast emulation like a BSS does, how can we run ND? Yes, it works
> with 3 cars in a lab.
>
> The description looks like it is confused with the MANET / 6LoWPAN concept
> of link, whereby my link joins the collection of nodes that my radio can
> reach.
>
> All the best,
>
> Pascal
>
> > Not quite sure what value that paragraph adds in the first place. You
> could
> > probable remove it.
> >
> > Cheers,
> > Ole
> >
> >
> > >
> > > Alex
> > >
> > >> Right, so it doesn’t sound like you have any reason to be different
> from
> > RFC2464.
> > >>>>>>>> "At least" does not mean "the value should be at least 10" in
> that
> > phrase.
> > >>>>>>>>
> bridging

---

From: Ole Troan <[email-masked]>
Date: Wed, 10 Apr 2019 18:18:07 +0200

Alexandre,

> concluded differently.  That needs clarification.

No need to update 4291.

> It looks an awful lot like Ethernet, but it can not be bridged to it. The 'brctl' and 'brconf' software issue errors when trying to link OCB interface to Ethernet interface.
> 
> If OCB can not be bridged to Ethernet then OCB interfaces are free to have a 65bit IID, without fearing lack of interoperability to an Ethernet interface with 64bit IID.  The IP forwarding does not care about IID length, and there is no bridging.

Rathole.

> Then somebody will ask what is the prefix length of the LL prefix on OCB?  What reference should I give to the person asking?
> 
> The reference is RFC2464 that says 64bit IID.  But that is for Ethernet and EThernet can not be bridged to OCB.
> 
>> could probable remove it.
> 
> The value in mentioning /10 is that it works on OCB (it works also on Ethernet but not on all OSs, and so  it may risk violating a section).

Because some implementations can handle it, is not a reason to diverge from RFC2464.
Stick with the RFC2464 definition.

Remove the paragraph and just reference 2464, and you should be fine (at least from the link-local perspective) in this draft.

Anyone else see a problem with that solution?

Cheers,
Ole

---

From: 神明達哉 <[email-masked]>
Date: Wed, 10 Apr 2019 10:37:17 -0700

At Wed, 10 Apr 2019 16:01:36 +0200,

> OCB?  What reference should I give to the person asking?

I don't see how that matters, unless the intent is to use a non-0
value in the intermediate 54 bits.  If you're willing to follow the
standard on this point and still want some reference for that
"somebody", I'd suggest referring to Section 2.5.6 of RFC 4291, like:

  NEW: A subnet is formed by the external 802.11-OCB interfaces of
  vehicles that are in close range (not by their in-vehicle
  interfaces). A node MUST form a link-local address on this link,
  as formatted in Section 2.5.6 of [RFC4291].

then, the question of fe80::/10 vs fe80::/64 becomes moot to me, since
both mean effectively the same thing: fe80::/10 with the following 54
bits being all 0 covers exactly the same addresses as fe80::/64.

(As I already argued) on the other hand, if the intent is to
deliberately use a non-0 value in the intermediate 54 bits (or for
that matter non-64-bit interface IDs), the specification should
explicitly say so, rather than alluding to it hidden in the question
of "what's the length of LL prefix", and should explicitly state that
the spec updates Section 2.5.6 of [RFC4291] in that sense.

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Wed, 10 Apr 2019 11:19:17 -0700

At Wed, 10 Apr 2019 16:19:40 +0200,

> - using fe80::/10 on Cisco, linux and openbsd works ok.

Specifically what do you mean by "fe80::/10 works"?  As I noted in a
separate message, unless you use a non-0 value in the intermediate 54
bits, that's effectively the same as fe80::/64.  So I guess "fe80::/10
works" implicitly means you can use a non-0 value in the intermediate
54 bits.  And then I don't see how it (always) works for OpenBSD.  Its
input code drops such packets:

    /* Drop packets if interface ID portion is already filled. */
    if (((IN6_IS_SCOPE_EMBED(&ip6->ip6_src) && ip6->ip6_src.s6_addr16[1]) ||
        (IN6_IS_SCOPE_EMBED(&ip6->ip6_dst) && ip6->ip6_dst.s6_addr16[1])) &&
        (ifp->if_flags & IFF_LOOPBACK) == 0) {
        ip6stat_inc(ip6s_badscope);
        goto bad;
    }
(from https://github.com/openbsd/src/blob/master/sys/netinet6/ip6_input.c)

Besides, even if we we didn't know of an implementation that drops
these packets today, it doesn't guarantee future interoperability as
long as RFC4291 Section 2.5.6 so clearly specifies these bits are all
0; it wouldn't be surprising if a new implementation "abuses" this
fact in a way that is not interoperable with implementations that use
a non-0 value in these bits.  We can't simply blame that new
implementation as "broken" since it just follows the format specified
in the RFC, albeit perhaps too strictly.

So, if this ipv6-over-80211ocb spec needs to rely on the use of a
non-0 value in the intermediate 54 bits, it's not enough to say it
"works" for some existing implementations today (which is actually
already false as I explained above for the OpenBSD case).  It should
explicitly make an exception to this part of RFC4291, rather than
obscurely alluding to it with "fe80::/10", and declare that it
formerly updates RFC4291, so that any future implementation can be
surely interoperable with it.

I actually don't know if "this ipv6-over-80211ocb spec needs to rely
on the use of a non-0 value in the intermediate 54 bits", btw.  If
that's not the case, it's much safer and less controversial to just
not mention it (either in the form of "LL prefix length" or more
explicitly).  I guess that's also what others are suggesting (and I
agree with them in that sense).

--
JINMEI, Tatuya

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 10 Apr 2019 21:35:16 +0200

On Mon, Apr 8, 2019 at 3:01 PM Pascal Thubert (pthubert) <[email-masked]>
wrote:

> Hello Nabil.
>
> *   You will get a number of IESG reviews as part of the submission
> process, one per area. This is just a beginning…*
>

just to point one important issue, the most important issue is not the
review, but the WG convinced and  clear and true technical discussions. The
working group can clarify things to reviewers even iesg, so the WG can
always discuss with ant reviewer.

>
>
>
> *   Cheers,   Pascal   From: NABIL BENAMAR <[email-masked]
> <[email-masked]>> Sent: lundi 8 avril 2019 17:53 To: Alexandre
> Petrescu <[email-masked] <[email-masked]>> Cc:
> Pascal Thubert (pthubert) <[email-masked] <[email-masked]>>;
> [email-masked] <[email-masked]>; [email-masked] <[email-masked]>;
> [email-masked] <[email-masked]>;
> <[email-masked]> Subject: Re: Intdir
> early review of draft-ietf-ipwave-ipv6-over-80211ocb-34   Yes definitely
> Alex....   There have been many reviews until now. This should be a late or
> final review.*
>

also there are things that are necessary and things that are optional, I
don't agree to add optional issues in first RFC of WG.

*   On Mon, Apr 8, 2019, 10:01 Alexandre Petrescu
> <[email-masked] <[email-masked]>> wrote: As a
> note: please improve the title of this. It is not an early review. It is a
> late review. There have been several reviews of this document until here,
> and two shepherd reviews. Alex Le 04/03/2019 à 12:24, Pascal Thubert a
> écrit : Reviewer: Pascal Thubert Review result: Not Ready   Reviewer:
> Pascal Thubert Review result: Not ready. Need to clarify IEEE relationship,
> IOW which SDO defines the use of L2 fields, what this spec enforces vs.
> recognizes as being used that way based on IEEE work. The use of IPv6 ND
> requires a lot more thoughts, recommendation to use 6LoWPAN ND. The
> definition of a subnet is unclear. It seems that RSUs would have prefixes
> but that is not discussed.   I am an assigned INT and IOT directorates
> reviewer for < draft-ietf-ipwave-ipv6-over-80211ocb-34 >. These comments
> were written primarily for the benefit of the Internet Area Directors.
> Document editors and shepherd(s) should treat these comments just like they
> would treat comments from any other IETF contributors and resolve them
> along with any other Last Call comments that have been received. For more
> details on the INT Directorate, see
> https://datatracker.ietf.org/group/intdir/about/
> <https://datatracker.ietf.org/group/intdir/about/>   Majors issues
> -----------------   “   o  Exceptions due to different operation of IPv6
> network layer on       802.11 than on Ethernet.   “ Is this doc scoped to
> OCB or 802.11 in general? Is there an expectation that an implementer of
> IPv6 over Wi-Fi refers to this doc? Spelled as above, it seems that you are
> defining the LLC. Figure 1 shows the proposed adaptation layer as IEEE LLC
> work. Who defines those fields, IETF or IEEE, or mixed? Who defines their
> use? If this spec defines a new LLC header (vs. how to use an IEEE field)
> then it should be very clear, and the newly defined fields should be
> isolated from IEEE fields.   "    The IPv6 packet transmitted on 802.11-OCB
> MUST be immediately    preceded by a Logical Link Control (LLC) header and
> an 802.11 header.   " Is there anything new or specific to OCB vs.
> classical 802.11 operations? If/when this is echoing the IEEE specs then
> this text should not use uppercase but say something like: 'Per IEEE Std
> 802.11, the IPv6 packet transmitted on 802.11-OCB is immediately  preceded
> by a Logical Link Control (LLC) header and an 802.11 header ...'
> different things? Why define both?   "   An 'adaptation' layer is inserted
> between a MAC layer and the    Networking layer.  This is used to transform
> some parameters between    their form expected by the IP stack and the form
> provided by the MAC    layer. " Is this different from what an AP does when
> it bridges Wi-Fi to Ethernet? Is this IETF business?   "    The Receiver
> and Transmitter Address fields in the 802.11 header MUST    contain the
> same values as the Destination and the Source Address    fields in the
> Ethernet II Header, respectively. " Same,  this is IEEE game isn't it?   "
>   Solutions for these problems SHOULD    consider the OCB mode of
> operation. " This is not specific enough to be actionable. I suggest to
> remove this sentence. It would be of interest for the people defining those
> solutions to understand the specific needs of OCB vs. Wi Fi, but I do not
> see text about that.   "   The method of forming IIDs    described in
> section 4 of [RFC2464] MAY be used during transition    time. " Contradicts
> section 4.3 that says " Among these types of    addresses only the IPv6
> link-local addresses MAY be formed using an    EUI-64 identifier. "   "
> This    subnet MUST use at least the link-local prefix fe80::/10 and the
> interfaces MUST be assigned IPv6 addresses of type link-local. " If this is
> conforming IPv6 then the MUST is not needed.   "    A subnet is formed by
> the external 802.11-OCB interfaces of vehicles    that are in close range
> (not by their in-vehicle interfaces). " Is the definition transitive? Do we
> really get a subnet? A is close to  B who is close to C .... to Z, makes
> Paris one subnet! Are you talking about a link, rather?   "    The Neighbor
> Discovery protocol (ND) [RFC4861] MUST be used over    802.11-OCB links. "
> Maybe you could consider RFC 6775 / RFC 8505 instead.   " In the moment the
> MAC address is changed    on an 802.11-OCB interface all the Interface
> Identifiers of IPv6    addresses assigned to that interface MUST change. "
> Why is that? This is unexpected, and hopefully wrong.   Minor issues
> ---------------   "   OCB (outside the context of a basic service set -
> BSS): A mode of    operation in which a STA is not a member of a BSS and
> does not    utilize IEEE Std 802.11 authentication, association, or data
> confidentiality.      802.11-OCB: mode specified in IEEE Std 802.11-2016
> when the MIB    attribute dot11OCBActivited is true.  Note: compliance with
> standards    and regulations set in different countries when using the
> 5.9GHz    frequency band is required. "   Are these 2 different things?   "
> Among these types of addresses only the IPv6 link-local addresses MAY be
> formed using an   EUI-64 identifier. " This text should not be in a LL
> specific section since it deals with the other addresses. Maybe rename the
> section to "addressing" or something?   "    For privacy, the link-local
> address MAY be formed according to the    mechanisms described in Section
> 5.2. " The MAY is not helpful. I suggest to remove the sentence that does
> not bring value vs. 5.2   Could you make sections 4.3 and 4.5 contiguous?
> " If semantically    opaque Interface Identifiers are needed, a potential
> method for    generating semantically opaque Interface Identifiers with
> IPv6    Stateless Address Autoconfiguration is given in [RFC7217].
> ([RFC2464], section 4), MAY be needed in order to avoid certain    privacy
> risks.   ...      In order to avoid these risks, opaque Interface
> Identifiers MAY be    formed according to rules described in [RFC7217].
> These opaque    Interface Identifiers are formed starting from identifiers
> different    than the MAC addresses, and from cryptographically strong
> material.    Thus, privacy sensitive information is absent from Interface
> IDs, and    it is impossible to calculate the initial value from which the
>    Interface ID was calculated.   " Duplicate and mis ordered text, isn't
> it?   " For this reason, an attacker may realize many    attacks on
> privacy. " Do we attack privacy? Maybe say that privacy is a real concern,
> and maybe move that text to security section?   "    The way Interface
> Identifiers are used MAY involve risks to privacy,    as described in
> Section 5.1. " Also duplicate   Nits ------   "    IP packets MUST be
> transmitted over 802.11-OCB media as QoS Data    frames whose format is
> specified in IEEE Std 802.11. " Please add link to the reference   " the
> 802.11 hidden node" Do not use 802.11 standalone (multiple occurrences). =>
> "the IEEE Std. 802.11 [ ref ] hidden node", or just "the hidden terminal".
>   BCP 14 text:   Suggest to use this text: “    The key words "MUST", "MUST
> NOT", "REQUIRED", "SHALL", "SHALL NOT",    "SHOULD", "SHOULD NOT",
> "RECOMMENDED", "NOT RECOMMENDED", "MAY", and    "OPTIONAL" in this document
> are to be interpreted as described in    https://tools.ietf.org/html/bcp14
> <https://tools.ietf.org/html/bcp14> https://tools.ietf.org/html/bcp14
> <https://tools.ietf.org/html/bcp14>    [https://tools.ietf.org/html/rfc2119
> <https://tools.ietf.org/html/rfc2119>][RFC8174] when, and only when, they
>    appear in all capitals, as shown here.   “   All the best   Pascal
> *
>
>
>
>
> * _______________________________________________ its mailing list
> [email-masked] <[email-masked]> https://www.ietf.org/mailman/listinfo/its
> <https://www.ietf.org/mailman/listinfo/its> *

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 11 Apr 2019 13:53:47 +1200

Hi Nabil,

> Do we still talk about broadcast in IPv6 ?

No, we talk about multicast. Pascal was using shorthand. But if multicast fails with high probability, several aspects of IPv6 will fail too, unless the LAN provides an NBMA (non-broadcast multiple access) emulation of multicast, or suitable alternatives to SLAAC, ND, NUD, and RA.

An earlier draft of this spec mentioned this problem:

>>>    The operation of the Neighbor Discovery protocol (ND) over 802.11-OCB
>>>    links is different than over 802.11 links.  In OCB, the link layer
>>>    does not ensure that all associated members receive all messages,
>>>    because there is no association operation.  Neighbor Discovery (ND)
>>>    is used over 802.11-OCB.

but it was inconsistent and was removed. If Ole is correct below about real-life conditions, the *problem* was not removed and the draft is not going to work in the real world.

    Brian

> 
> On Wed, Apr 10, 2019, 14:45 Pascal Thubert (pthubert) <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hello Ole:
> 
>     > From: Ole Troan <[email-masked] <mailto:[email-masked]>>
>     > To: Alexandre Petrescu <[email-masked] <mailto:[email-masked]>>
>     > Cc: Pascal Thubert (pthubert) <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>;
>     > [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; draft-ietf-ipwave-ipv6-over-
>     > [email-masked] <mailto:[email-masked]>; Brian E Carpenter <[email-masked] <mailto:[email-masked]>>
>     > >>> On 10 Apr 2019, at 11:22, Alexandre Petrescu
>     > <[email-masked] <mailto:[email-masked]>> wrote:
>     > >>>
>     > >>>
>     > >>>
>     > >>> [email-masked] <mailto:[email-masked]>
>     > > [email-masked] <mailto:[email-masked]>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 11 Apr 2019 02:36:29 +0000

Hello Brian

I meant broadcast at layer 2 not layer 3. L3 uses multicast but it requires a service at the lower layer to implement it. This is rarely if ever a real L2 multicast service. IOW the IETF has thrown the problem over the fence to the IEEE but it is not really solved to this day.

In practice, the service that is performed on IEEE std 802.3 is a broadcast over a broadcast domain, and the subnet has to be contained within that domain. The broadcast operation is emulated on IEEE std 802.11 by the BSS operation whereby the AP reflects the message to be broadcasted, so the broadcast domain is that of the AP as opposed to that of the source STA. 

By the proposed definition, if car A sees car B they are in the same subnet. If car B sees car C they are in the same subnet. Transitively Car A is in the same subnet as car C. But car C may not be in the radio broadcast domain of car A, and there is no BSS by definition of OCB to emulate a broadcast domain between them via an AP. End result is that a DAD or a lookup by car A will not reach car C. 

By traditional MANET and 6lo definition, the radio broadcast domain of a node is his link. In you lab you can arrange that the broadcast domains of 3 cars fully overlap. In that case, the link appears to match the common sense of a link in wires and the classical IPv6 operations will work pretty much the same as in a BSS over that Link. It is for example easy to place a subnet that matches that Link. It is also easy to confuse a Link with a Subnet, which is what the definition does. As soon as the broadcast domains start diverging, things get hairy, see all the work by Erik about split subnet etc...

The IETF has studied this situations for 10+ years at MANET, 6TiSCH and 6lo. We have an architecture that cover single link and multilink subnets. In the former case, the link is defined by one node that owns the prefix. In the latter case, routing is required inside the subnet and we created RPL to cover the situation. We created RFC 8505 for an host to connect to the network in either situation, without the requirement that the L2 broadcast domain of the host (its Link) overlaps with that of other nodes in the subnet (because they don't). We have made RFC 8505 abstract to the routing protocol if any, IOW without the requirement that the host knows there is a MLSN, understands RPL or whatever other routing is used to put together the MLSN. To get there we had to abandon the dependency that a L2 broadcast from the host reaches all nodes in the subnet, IOW that the subnet is contained within the Link of all of its members, IOW that the Links of all the nodes in the subnet fully overlap. This meant we had to abandon the idea of using multicast in ND for DAD and AR. 

Maybe someone can explain that better than I did. I so please be my guest. I really tried but I'm not convinced I did not waste my time with the authors of the draft.

All the best,

Pascal

> From: Int-dir <[email-masked]> On Behalf Of Brian E Carpenter
> Sent: jeudi 11 avril 2019 09:54
> To: NABIL BENAMAR <[email-masked]>; Pascal Thubert (pthubert)
> <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked]; draft-ietf-ipwave-ipv6-over-
> [email-masked]; Alexandre Petrescu <[email-masked]>;
> Ole Troan <[email-masked]>
> No, we talk about multicast. Pascal was using shorthand. But if multicast fails
> with high probability, several aspects of IPv6 will fail too, unless the LAN
> provides an NBMA (non-broadcast multiple access) emulation of multicast, or
> suitable alternatives to SLAAC, ND, NUD, and RA.
> 
> but it was inconsistent and was removed. If Ole is correct below about real-life
> conditions, the *problem* was not removed and the draft is not going to work
> in the real world.
> 
>     Brian
> 
> >
> > On Wed, Apr 10, 2019, 14:45 Pascal Thubert (pthubert)
> >     Because it is transitive, the description extends the so-called subnet step
> by step to a potentially large number of cars such that there is no broadcast
> domain that covers them all. If there is no broadcast domain and no multicast
> emulation like a BSS does, how can we run ND? Yes, it works with 3 cars in a
> lab.
> >
> concept of link, whereby my link joins the collection of nodes that my radio
> can reach.
> >
> >     All the best,
> >
> >     Pascal
> >
> >     > Cc: Pascal Thubert (pthubert) <[email-masked]
> <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>;
> >     > [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:int-
> [email-masked]>; draft-ietf-ipwave-ipv6-over-
> >     > [email-masked] <mailto:[email-masked]>; Brian E
> Carpenter <[email-masked]
> <mailto:[email-masked]>>
> >     > > You said: if OCB is still 48bit, and if there is bridging OCB-Ethernet, then
> no
> >     > reason to be different than rfc2464.
> >     > >
> <mailto:[email-masked]>> wrote:
> >     > >>>
> >     > >>>
> >     > >>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 11 Apr 2019 10:52:42 +0200

Allow me to change the topic of this.  It helps tracking the discussion.

Le 11/04/2019 à 03:53, Brian E Carpenter a écrit :
> No, we talk about multicast. Pascal was using shorthand. But if
> multicast fails with high probability, several aspects of IPv6 will
> fail too, unless the LAN provides an NBMA (non-broadcast multiple
> access) emulation of multicast, or suitable alternatives to SLAAC,
> ND, NUD, and RA.
> 
>>>> The operation of the Neighbor Discovery protocol (ND) over
>>>> 802.11-OCB links is different than over 802.11 links.  In OCB,
>>>> the link layer does not ensure that all associated members
>>>> receive all messages, because there is no association
>>>> operation.  Neighbor Discovery (ND) is used over 802.11-OCB.
> 
> but it was inconsistent and was removed. If Ole is correct below
> about real-life conditions, the *problem* was not removed and the
> draft is not going to work in the real world.

Brian,

I agree with your comments about the existence of preceding text of ND.

But please note ND works on OCB in the real world.  It works when one 
sets up the PHY and MAC links correctly, prior to putting IP on them.

The way to set up links prior to put IP on them could be described, but 
not sure if its good to put it in an IP-over-OCB document.  RFC2464 does 
not tell how to click RJ45 cables in their sockets: we do it naturally, 
but there is process in it (e.g. always fit the tag in the hole, and 
feel and hear a click; if tag on the other way then it risks breaking; 
after breaking an RJ45 socket surely IP wont work, because it is loose 
and shows too many interruptions).

Similarly setting the PHY of an OCB domain such that IP can work has 
process in it: select the right antennas, directionality, power levels, 
channels; dont go beyond distance allowed by power levels.  If that 
process is not followed then there is no chance for IP (neither ND) to 
work understandably.  People grow white hairs because of this.  More 
attention to PHY and MAC prior to IP setup would reduce frustration of 
the IP inclined.

It is good to keep work at levels.

Alex

>> there is no broadcast domain that covers them all. If there is no
>> broadcast domain and no multicast emulation like a BSS does, how
>> can we run ND? Yes, it works with 3 cars in a lab.
>> 
>>> -----Original Message----- From: Ole Troan <[email-masked]
>>> <mailto:[email-masked]>> Sent: mercredi 10 avril 2019
>>> 20:41 To: Alexandre Petrescu <[email-masked]
>>> <mailto:[email-masked]>> Cc: Pascal Thubert
>>> (pthubert) <[email-masked] <mailto:[email-masked]>>;
>>> [email-masked] <mailto:[email-masked]>; [email-masked]
>>> <mailto:[email-masked]>; [email-masked]
>>> <mailto:[email-masked]>; draft-ietf-ipwave-ipv6-over- 
>>> <mailto:[email-masked]>> Subject: Re: [Int-dir]
>>> Intdir early review of draft-ietf-ipwave-ipv6-over- 80211ocb-34 -
>>> 'conforming IPv6' - fe80::/10 vs fe80::/64
>>> 
>>>>> Alexandre, Right, so it doesn’t sound like you have any
>>>>> reason to be different from
>>> RFC2464.
>>>>>>>>>> To me there is nothing in the actual text to tell
>>>>>>>>>> me that "at least" qualifies the "/10". I think you
>>>>>>>>> Indeed. If you absoultely must cut and paste text
>>>>>>>>> from 2464:
>>>>>>>> 
>>>>>>>>> to the prefix FE80::/64. 10 bits            54 bits
>>>>>>>>> 64 bits 
>>>>>> mailing list [email-masked] <mailto:[email-masked]> 
>>>> list [email-masked] <mailto:[email-masked]>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 11 Apr 2019 11:23:58 +0200

Pascal,

Please allow me to change the subject of this, to reflect the content.
It helps tracking the discussion.

Le 11/04/2019 à 04:36, Pascal Thubert (pthubert) a écrit :
> Hello Brian
> 
> I meant broadcast at layer 2 not layer 3. L3 uses multicast but it 
> requires a service at the lower layer to implement it. This is rarely
> if ever a real L2 multicast service.

I can agree.

> IOW the IETF has thrown the problem over the fence to the IEEE but
> it is not really solved to this day.

I think indeed there is redirection of responsability to IEEE.  Maybe
IEEE does not like to do it, because of some reasons.

With respect to link-layer multicast: there is indeed no IEEE messaging
for creation or removal of link-layer multicast groups (like in IP there
is MLDv2).  But there is concept of link-layer multicast groups at IEEE.
  This is used extensively by mapping IP groups into link-layer groups,
and it helps IP.

Should IEEE develop a mechanism using messages (not just local filters)
for creating these link-layer groups?

> In practice, the service that is performed on IEEE std 802.3 is a 
> broadcast over a broadcast domain, and the subnet has to be contained
> within that domain.

Well yes and no.

Yes it is a broadcast  on 802.3 if we talk IPv4, but it is still
link-layer multicast on 802.3 if we talk IPv6: the link-layer addresses
ofIPv6 on Ethernet are link-layer multicast addresses.

> The broadcast operation is emulated on IEEE std 802.11 by the BSS
> operation whereby the AP reflects the message to be broadcasted, so
> the broadcast domain is that of the AP as opposed to that of the
> source STA.

I agree.

> By the proposed definition, if car A sees car B they are in the same
>  subnet. If car B sees car C they are in the same subnet. 
> Transitively Car A is in the same subnet as car C.

PAscal, again, this depends on how you set up the OCB interfaces on cars
A, B and C.

There are two options:
- use a single OCB interface with antenna sitting on top of each
   automobile.  Make them all in the same channel frequency (e.g. CCH -
   Control Channel).  That indeed has that A-B-C transitivity aspect.
   Worse, it has scalability issues: one cant grow a convoy beyond a few
   tens of meters and be sure the frontmost talks directly to the
   rearmost.  One never knows whether somebody in the middle repeats, or
   not.  Or one needs to  rely on MANET protocols that may forward on a
   single interface.  It has some PHY issues as well, that I can
   describe.  The powerpoint is readily filled with my last PHY
   experiments of propagation.
- use multiple OCB antennas situated at some strategic places in a car.
   This is in the same way as when placing the other ultra sound, radar
   and lidar sensors in the automobile.

   An OCB interface in the front bumper of one car forms a subnet with
   another OCB interface in the rear bumper of another car, on a
   particular channel (SCHx - service channel number x).  The front and
   rear subnets of a car are in distinct channels.  There is no A-B-C
   transitivity.  There is IP forwarding between front and rear
   interfaces of a car.

This can be described.  But I dont think it should be described in the
IP-over-OCB document.  It is a PHY MAC setting for OCB.

> But car C may not be in the radio broadcast domain of car A, and
> there is no BSS by definition of OCB to emulate a broadcast domain
> between them via an AP. End result is that a DAD or a lookup by car A
> will not reach car C.

That may be true, but it is true mostly in a setting where each car uses
a single OCB interface whose antenna is placed on the roof of the car
(placed at same place as the the GPS, LTE, FM or DVB-T antennas are placed).

In settings where each car has multiple OCB interfaces and multiple
antennas placed at strategic places (strategic: places that are relevant
to PHY propagation conditions), rather than simply on the roof, the
issue you describe in the above paragraph.

Now, if you read up to here, I would like to ask you (without claiming
to be all-knowing), whether you think a car could have several OCB
interfaces?

> By traditional MANET and 6lo definition, the radio broadcast domain 
> of a node is his link.

It is good, and I agree with it.

For my part, I do not use the traditional MANET and 6lo definitions
because I believe they are not sufficient for vehicular environments.

> In you lab you can arrange that the broadcast domains of 3 cars fully
> overlap.

I agree, people do that.  It is in small lab, with size in the range of
a few meters; there is much reflexion from the walls.  It is not outdoors.

> In that case, the link appears to match the common sense of a link in
> wires and the classical IPv6 operations will work pretty much the
> same as in a BSS over that Link. It is for example easy to place a
> subnet that matches that Link. It is also easy to confuse a Link with
> a Subnet, which is what the definition does. As soon as the broadcast
> domains start diverging, things get hairy, see all the work by Erik
> about split subnet etc...

I fully agree with this paragraph.

I think if one puts several interfaces and antennas in a car, and
carefully design the use of the propagation models (e.g. avoid 'omni',
consider 'directional', etc) then one can avoid many problems forbidding
IP from running on wireless.

> The IETF has studied this situations for 10+ years at MANET, 6TiSCH 
> and 6lo. We have an architecture that cover single link and multilink
> subnets.

Yes, there is.

> In the former case, the link is defined by one node that owns the
> prefix. In the latter case, routing is required inside the subnet and
> we created RPL to cover the situation.

YEs, but these are departures from what might be called traditional IP
forwarding.  That forwarding happens between two distinct interfaces.

In practice it means little software for MANET-6lo-multilink is publicly
available, and the engineer skill about them is hard to find.  This
translates to equipment being very expensive.

I want to tell you that communication equipment for cars is already very
high compared to an off-the-shelf WiFi router.  That high price tag is
due also to specification of things that are too intelligent and that
require high skills from few people.  This is the case of V2X stacks
doing ETSI CAM with GeoNetworking and similar.  You end up with a
3000Eur IP-OBU when its underlying hardware with linux and traditional
IP forwarding costs around 700Eur.

To that 3000Eur one may need to add costs of complexity of MANET
protocols and 6lo multilink subnet moels you arrive at a cost per
communication box that is the equivalent of a small car.

This high cost is less and less acceptable.

Compare that to the 1Eur LTE-WiFi dongle retrofitted recently in some cars.

> We created RFC 8505 for an host to connect to the network in either 
> situation, without the requirement that the L2 broadcast domain of 
> the host (its Link) overlaps with that of other nodes in the subnet 
> (because they don't). We have made RFC 8505 abstract to the routing 
> protocol if any, IOW without the requirement that the host knows 
> there is a MLSN, understands RPL or whatever other routing is used

MLSN?

> to put together the MLSN. To get there we had to abandon the
> dependency that a L2 broadcast from the host reaches all nodes in the
> subnet, IOW that the subnet is contained within the Link of all of

IOW?

> its members, IOW that the Links of all the nodes in the subnet fully 
> overlap. This meant we had to abandon the idea of using multicast in 
> ND for DAD and AR.
> 
> Maybe someone can explain that better than I did. I so please be my 
> guest. I really tried but I'm not convinced I did not waste my time 
> with the authors of the draft.

You did not waste your time, no more than I did.

Alex

> 
> All the best,
> 
> Pascal
> 
>> -----Original Message----- From: Int-dir <[email-masked]>
>> On Behalf Of Brian E Carpenter Sent: jeudi 11 avril 2019 09:54 To:
>> NABIL BENAMAR <[email-masked]>; Pascal Thubert (pthubert)
>>  <[email-masked]> Cc: [email-masked]; [email-masked]; 
>> [email-masked]; Alexandre Petrescu 
>> <[email-masked]>; Ole Troan <[email-masked]> 
>> Subject: Re: [Int-dir] Intdir early review of 
>> draft-ietf-ipwave-ipv6-over- 80211ocb-34 - 'conforming IPv6' - 
>> fe80::/10 vs fe80::/64
>> 
>> Hi Nabil,
>> 
>>>>> 802.11-OCB links is different than over 802.11 links.  In 
>>>>> OCB, the link layer does not ensure that all associated 
>>>>> members receive all messages, because there is no association
>>> subnet step
>> by step to a potentially large number of cars such that there is no
>> broadcast domain that covers them all. If there is no broadcast 
>> domain and no multicast emulation like a BSS does, how can we run 
>> ND? Yes, it works with 3 cars in a lab.
>>> 
>> <mailto:[email-masked]>>
>>>> Subject: Re: [Int-dir] Intdir early review of 
>>>> draft-ietf-ipwave-ipv6-over- 80211ocb-34 - 'conforming IPv6' -
>>>>  fe80::/10 vs fe80::/64
>>>> 
>>>>> OCB-Ethernet, then
>>>>  Ethernet should not follow
>> the
>>>> 64-bit boundary and the definition of the link-local address 
>>>> mapping of rfc2464? Section 4.5.1 is already clear on that.
>>>> 
>>>> I think the only thing we are asking you is to change the 
>>>> following
>> paragraph:
>>>> 
>>>> OLD: A subnet is formed by the external 802.11-OCB interfaces 
>>>> of vehicles that are in close range (not by their in-vehicle 
>>>> interfaces).  This subnet MUST use at least the link-local 
>>>> prefix fe80::/10 and the interfaces MUST be assigned IPv6 
>>>> addresses of type link-local.
>>>> 
>>>> NEW: A subnet is formed by the external 802.11-OCB interfaces 
>>>> of vehicles that are in close range (not by their in-vehicle 
>>>>>>>>>>> me that "at
>> least"
>>>>>>>>>>> qualifies the "/10". I think you could rephrase 
>>>>>>>>>>> as "This subnet's prefix MUST lie within the 
>>>>>>>>>>> However, see Jinmei's messages about conformance
>>>>>>>>>>>  with RFC
>> 4291.
>>>>>>>>>>> 
>>>>>>>>>>> I think there might be unexpected side effects 
>>>>>>>>>>> from using an address like fe80:1::1. What if 
>>>>>>>>>>> some code uses matching with fe80::/64 to test if
>>>>>>>>>>> an address is link-local? I agree that would be
>>>>>>>>>>> faulty code, but you would be the first to 
>>>>>>>>>>> discover it.
>>>>>>>>>> 5.  Link-Local Addresses The IPv6 link-local 
>>>>>>>>>> address [AARCH] for an Ethernet interface is formed
>>>>>>>>>> by appending the Interface Identifier, as defined
>>>>>>>>>> above,
>> to
>>>>>>>>>> I presume there is support for bridging 802.11p and
>>>>>>>>>> other 802.3
>> links?
>>>>>>> 
>>>>>>> 802.11-
>> OCB
>>>>  bridged to
>> the
>>>> WiFi interface; that helps with DHCP, tcpdump and others to see
>>>> one a
>> single -
>>>> bridged - interface.
>>>>>>> 
>>>> bridging between the multiple 802.11-OCB interfaces that might
>>>>  be present in
>> the
>>>> same computer.
>>>>>>> 
>>>>>>> Do you assume bridging of 802.11-OCB interface to 
>>>>>>> Ethernet
>> interface is
>>>> always there?
>>>>>>> 
>>>> perspective.  If yes,
>> we can
>>>>>>>>>>  justification
>> for

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 11 Apr 2019 11:25:06 +0200

Pascal,

Do you agree there can be multiple IP OCB interfaces in one car?

Alex

Le 11/04/2019 à 11:23, Alexandre Petrescu a écrit :
>>>>>>> to be different
>>>>>>>>>>>> I think there might be unexpected side effects from using 
>>>>>>>>>>>> an address like fe80:1::1. What if some code uses matching 
>>>>>>>>>>>> with fe80::/64 to test if
>>>>>>>>>>>> faulty code, but you would be the first to discover it.
>>>>>>>>>>> Indeed. If you absoultely must cut and paste text from 2464:
>>>>>>>>>>
>>>>>>>>>>> 5.  Link-Local Addresses The IPv6 link-local address [AARCH] 
>>>>>>>>>>> for an Ethernet interface is formed
>>>>>>>> any
>>>>> If yes,
>>> _______________________________________________ Int-dir mailing list 
>>> [email-masked] https://www.ietf.org/mailman/listinfo/int-dir

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 11 Apr 2019 13:26:59 +0200

Le 10/04/2019 à 20:19, 神明達哉 a écrit :
> At Wed, 10 Apr 2019 16:19:40 +0200, Alexandre Petrescu
>> Pascal, fe80::/10 is not wrong, because: - using fe80::/10 on OCB
>> works ok. - using fe80::/10 on Cisco, linux and openbsd works ok.
> 
> Specifically what do you mean by "fe80::/10 works"?

On command line interface (CLI) of linux it is ok to add an address 
fe80:1::1/32 to an interface, and then ping a neighbor having an address 
fe80:1::2/32 on its own interface.

It works on linux, Cisco, as I tried myself.

Others reported openbsd to work ok with Interface ID of length different
than 64.  Because of that report, I believe openbsd will also work ok
with fe80:1::1/32.

That means that any other plen for LLs, down to 10, will work.  I.e. add
an address fe80::1/10 on the interface and then ping a neighbor.

Specifically, why do you question the "fe80::/10 works" statement?  Do
you think it does not work?

(in other report, if I remember correctly, you suggested than in a
certain flavor of BSD it is impossible to assign fe80:1::1 on an interface).

> As I noted in a separate message, unless you use a non-0 value in the
> intermediate 54 bits, that's effectively the same as fe80::/64.  So I
> guess "fe80::/10 works" implicitly means you can use a non-0 value in
> the intermediate 54 bits.

I agree with your understanding.

I meant to say that fe80:1::/32 works as I tried it, and, by extension, 
that fe80::/10 would work as well.

> And then I don't see how it (always) works
> for OpenBSD.  Its input code drops such packets:
> 

Is the macro IN6_IS_SCOPE_EMBED bound by a number like 64 or 10?  I cant 
see the macro definition.

My claim about openbsd working with fe80:1::1/32 is a logic extension I 
make from other programmer's claim that the /64 boundary has been 
removed from openbsd.  In that email the person talks about RA with plen 
112, and GUA formed; the email mirrored from 6man, and openbsd commit 
references, are:
https://marc.info/?l=ipng&m=152141046701347&w=2
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sbin/slaacd/engine.c#rev1.22

> long as RFC4291 Section 2.5.6 so clearly specifies these bits are
> all 0; it wouldn't be surprising if a new implementation "abuses"
> this fact in a way that is not interoperable with implementations
> that use a non-0 value in these bits.  We can't simply blame that
> new implementation as "broken" since it just follows the format
> specified in the RFC, albeit perhaps too strictly.

I can agree to the point of view about implementations abiding to RFC4291.

But I would like to ask the implementation whether it prefers to be 
in-line with RFC4291 (rfc4291) or with the IANA allocation (fe80::/10).

There are obviously advantages and inconvenients to both.  Why should we 
decide to be just one?

I agree.

Not all implementations can do fe80::/1.  A situation is follows:
- linux can do fe80:1::1/32, ping ok.
- OpenBSD is debatable whether or not it accepts fe80::/10 or only
   fe80::/64.
- Cisco IOS displays fe80::/10 in its CLI.
- Windows 10 displays fe80::64bitIID%12 or some other number (it does
   not seem to be the prefix len, but the IID is 64bitlength).
- Android: someone can easily check ifcondig add fe80:1::1/32 eth0.  I
   guess, suppose it will work, since it's linux kernel.

The question can also be whether or not some OS stack should be 
corrected?  I.e. should linux be corrected to not violate, or should 
FreeBSD be corrected to agree to IANA.

It can also be whether or not there can be qualifiers such as 
'violation', or 'conformance to IPv6' are appropriate.

> agree with them in that sense).

There is indeed the option of being silent about the prefix length of 
IPv6 LLs in the IPv6-over-OCB document.

There is the option of mentioning "fe80::/10", but with "Updates 4291 
section X" in the header of the 1st page.

There is the option of proving by implementation that fe80:1::1/32 on 
OCB is not harmful to others.

Each of these options has advantages and drawbacks.

Alex

---

From: Alexandre PETRESCU <[email-masked]>
Date: Thu, 11 Apr 2019 13:28:50 +0200

[...]
>> I actually don't know if "this ipv6-over-80211ocb spec needs to
>> rely on the use of a non-0 value in the intermediate 54 bits", btw.
>> If that's not the case, it's much safer and less controversial to
>> just not mention it (either in the form of "LL prefix length" or
>> more explicitly).  I guess that's also what others are suggesting
>> (and I agree with them in that sense).

There is the option of being silent about the prefix length of
IPv6 LLs in the IPv6-over-OCB document.

Alex

---

From: Ole Troan <[email-masked]>
Date: Thu, 11 Apr 2019 13:38:43 +0200

> OCB is not harmful to others.

Two of these options will likely prohibit consensus being reqched on this document.
I encourage you to carefully consider how to best spend your time and the time of the particpants in the involved set of working groups.

Ole

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 11 Apr 2019 13:50:21 +0200

Here is my take on the options below:

[...]

> IPv6 LLs in the IPv6-over-OCB document.

- other recent docs are also silent about the LL prefix length; by this
   silence some understand it as being variable.  For example RFC7217
   "Stable and Opaque IIDs for SLAAC".

- being silent about fe80::/10 (dont say "fe80::/10") does not remove
   the current text reference to RFC4291 (see at the end of the email).
   A reader is thus led into reading rfc4291 about LLs.  That text can be
   understood either as "fe80::/64" or as "fe80::/10" with 54 0 bits.  It
   can not be understood as fe80:1::1/32 that I use.

   Should we remove the reference to RFC4291 too?

   Shoulwd we replace it with a reference to IANA page that says
   "fe80::/10".

> section X" in the header of the 1st page.

I prefer this option.

Be silent about "fe80::/10" in the running text but modify 1st page of 
IPv6-over-OCB document such that:
- tell "Updates RFC4291 [*]" on the header of the 1st page,
- and "[*]: RFC4291 section 2.5.6 figure has variable-value 54bits
   (instead of 0 value)" on the bottom of 1st page.  There is some place
   there.

If you think that this looks more like an Errata, think that an Errata 
on this topic has already been filed to RFC4291.  It is Errata ID 4406 
available at https://www.rfc-editor.org/errata/eid4406.

The conclusion of that Errata is: "[...] The re-definition of the 
link-local address would need to be driven by a draft updating RFC 
4291." There is already an Internet Draft to try to update this.  The 
Internet Draft is draft-petrescu-6man-ll-prefix-len.

> OCB is not harmful to others.

I agree with this option too.  I would invite the practice inclined to 
test it further.  There is a small easy thing to do: try 'ifconfig eth0 
add fe80:1::1/32 on a command line on Android wifi interface', and 
report here whether it works or not.  It would be a small step forward.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 11 Apr 2019 13:53:25 +0200

Le 11/04/2019 à 13:38, Ole Troan a écrit :
>>>> I actually don't know if "this ipv6-over-80211ocb spec needs
>>>> to rely on the use of a non-0 value in the intermediate 54
>>>> bits", btw. If that's not the case, it's much safer and less
>>>> controversial to just not mention it (either in the form of "LL
>>>> prefix length" or more explicitly).  I guess that's also what
>>>> others are suggesting (and I agree with them in that sense).
>> 
>> There is the option of being silent about the prefix length of IPv6
>> LLs in the IPv6-over-OCB document.
>> 
>> There is the option of mentioning "fe80::/10", but with "Updates
>> 4291 section X" in the header of the 1st page.
>> 
>> There is the option of proving by implementation that fe80:1::1/32
>> on OCB is not harmful to others.
> 
> Two of these options will likely prohibit consensus being reqched on
> this document. I encourage you to carefully consider how to best
> spend your time and the time of the particpants in the involved set
> of working groups.

YEs, thank you for the advice Ole.  I need to take care how to spend my 
time.  Maybe try to avoid taking on directions that are known to be dead 
ended.

I read your message as a warning that I take seriously.  For that, I 
would like to ask you whether you make this suggestion as a WG Chair of 
6man WG?  Or as a contributor to other WGs?

Alex

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 11 Apr 2019 13:26:41 +0000

Hi Alex,

> On Apr 11, 2019, at 7:53 AM, Alexandre Petrescu <[email-masked]> wrote:
> 
> YEs, thank you for the advice Ole.  I need to take care how to spend my time.  Maybe try to avoid taking on directions that are known to be dead ended.
> 
> I read your message as a warning that I take seriously.  For that, I would like to ask you whether you make this suggestion as a WG Chair of 6man WG?  Or as a contributor to other WGs?

<AD Hat On>
I would like to look at this from a different angle. It is clear from the current standards that you need to be using fe80::/64 to form the LL address as the IPv6 address architecture requires the IID to be 64 bits long (for non b000 prefixes) and SLAAC requires the prefix and the IID lengths to add up to 128. If you want this changed, I don’t think this is the document where you should do it. The *burden of proof is on you* to show why the status quo does not work in this case and IMHO it has not been meet. 

I would request that you keep the link-local prefix length discussion out of this draft, and in 6man where it belongs. Here is the thread that you started in January this year in 6man

https://mailarchive.ietf.org/arch/msg/ipv6/SD0OSOxFe9UGExX84u_CQSdfOsM

and the associated draft

https://datatracker.ietf.org/doc/draft-petrescu-6man-ll-prefix-len/

If you wish to pursue this topic further, please do so with *that* draft. An IP-over-foo document is not a place to do such a major architectural change.

Thanks
Suresh

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 11 Apr 2019 15:37:49 +0200

Le 11/04/2019 à 15:26, Suresh Krishnan a écrit :
>>>>>> I actually don't know if "this ipv6-over-80211ocb spec
>>>>>> needs to rely on the use of a non-0 value in the
>>>>>> intermediate 54 bits", btw. If that's not the case, it's
>>>>>> much safer and less controversial to just not mention it
>>>>>> (either in the form of "LL prefix length" or more
>>>>>> explicitly).  I guess that's also what others are
>>>>>> suggesting (and I agree with them in that sense).
>>>> IPv6 LLs in the IPv6-over-OCB document. There is the option of
>>>> mentioning "fe80::/10", but with "Updates 4291 section X" in
>>>> the header of the 1st page. There is the option of proving by
>>>> implementation that fe80:1::1/32 on OCB is not harmful to
>>>> others.
>>> Two of these options will likely prohibit consensus being reqched
>>> on this document. I encourage you to carefully consider how to
>>> best spend your time and the time of the particpants in the
>>> involved set of working groups.
>> 
>> YEs, thank you for the advice Ole.  I need to take care how to
>> spend my time.  Maybe try to avoid taking on directions that are
>> known to be dead ended.
>> 
>> I read your message as a warning that I take seriously.  For that,
>> I would like to ask you whether you make this suggestion as a WG
>> Chair of 6man WG?  Or as a contributor to other WGs?
> 
> <AD Hat On> I would like to look at this from a different angle. It
> is clear from the current standards that you need to be using
> fe80::/64 to form the LL address as the IPv6 address architecture
> requires the IID to be 64 bits long (for non b000 prefixes) and SLAAC
> requires the prefix and the IID lengths to add up to 128. If you want
> this changed, I don’t think this is the document where you should do
> it. The *burden of proof is on you* to show why the status quo does
> not work in this case and IMHO it has not been meet.
> 
> I would request that you keep the link-local prefix length discussion
> out of this draft, and in 6man where it belongs. Here is the thread
> that you started in January this year in 6man
> 
> If you wish to pursue this topic further, please do so with *that*
> draft. An IP-over-foo document is not a place to do such a major
> architectural change.

Well ok, but I would like to pursue that draft without opposition.

The draft did have discussion yet it got refused for presentation.

I would like to avoid ping pong.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 11 Apr 2019 15:56:47 +0200

I removed the fe80::/10 word and submitted version -38.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 11 Apr 2019 15:59:51 +0200

Pascal,

I believe all issues you raised are solved in version -38.

The editorial changes about text coherency are solved.

The ND text was modified, and an annex was added containing your own 
text, but with removal of RECOMMENDED of your preferred RFC, replaced 
with some lower case qualifiers instead.

The fe80::/10 word was removed.

Alex

---

From: William Whyte <[email-masked]>
Date: Thu, 11 Apr 2019 11:15:26 -0400

Hi Alex -- there *can* be multiple OCB interfaces in one car, but should
the standard be written assuming that there are multiple OCB interfaces? I
would have thought that the goal would be to write a standard that works
even if there's a single OCB interface.

If we're relying on multiple OCB interfaces to make this work, how many of
those interfaces per car are we relying on? We can't presumably be assuming
a distinct interface for each remote car that the local car is
communicating with. If we aren't assuming a distinct interface for each
remote car, then doesn't the problem that Pascal identifies come up?

(You also mention that the antenna at the front of car B communicates with
the one at back of car A -- but what if A overtakes B? And to be clear, I'm
not asking for a direct answer to that question, I'm saying that if there
are assumptions about the physical topology that we're relying on, we need
to make those assumptions very clear and make them clear up front)

I'd be very concerned if we were writing a standard that didn't work if
there was only one OCB interface in the car. Can you reassure me on that?

Cheers,

William

On Thu, Apr 11, 2019 at 5:25 AM Alexandre Petrescu <
[email-masked]> wrote:

>  subnet. If car B sees car C they are in the same subnet. Transitively Car
> A is in the same subnet as car C.
>
>
> By traditional MANET and 6lo definition, the radio broadcast domain of a
> node is his link.
>
>
> The IETF has studied this situations for 10+ years at MANET, 6TiSCH and
> 6lo. We have an architecture that cover single link and multilink
> subnets.
>
>
> Yes, there is.
>
> situation, without the requirement that the L2 broadcast domain of the host
> (its Link) overlaps with that of other nodes in the subnet (because they
> don't). We have made RFC 8505 abstract to the routing protocol if any, IOW
> without the requirement that the host knows there is a MLSN, understands
> RPL or whatever other routing is used
>
>
> MLSN?
>
> overlap. This meant we had to abandon the idea of using multicast in ND for
> DAD and AR.
>
> Maybe someone can explain that better than I did. I so please be my guest.
> I really tried but I'm not convinced I did not waste my time with the
> authors of the draft.
>
>
> <[email-masked]>
> NABIL BENAMAR <[email-masked]> <[email-masked]>; Pascal
> Thubert (pthubert)
>  <[email-masked]> <[email-masked]> Cc: [email-masked]; [email-masked];
> [email-masked]; draft-ietf-ipwave-ipv6-over- [email-masked];
> Alexandre Petrescu <[email-masked]>
> <[email-masked]> Subject: Re: [Int-dir] Intdir early review of
> draft-ietf-ipwave-ipv6-over- 80211ocb-34 - 'conforming IPv6' - fe80::/10 vs
> fe80::/64
>
> Hi Nabil,
>
> No, we talk about multicast. Pascal was using shorthand. But if multicast
> fails with high probability, several aspects of IPv6 will
> links is different than over 802.11 links.  In OCB, the link layer does not
> ensure that all associated members receive all messages, because there is
> no association
> but it was inconsistent and was removed. If Ole is correct below about
> real-life conditions, the *problem* was not removed and the draft is not
> going to work in the real world.
>
> Brian
>
>
> <[email-masked] <mailto:[email-masked]> <[email-masked]>>
> wrote:
>
>
> Hello Ole:
>
> step
> <mailto:[email-masked]> <[email-masked]>>
>
> Sent: mercredi 10 avril 2019 20:41 To: Alexandre Petrescu <
> [email-masked]
>
> <mailto:[email-masked]> <[email-masked]>>
>
> <mailto:[email-masked]> <[email-masked]>>; [email-masked]
> <mailto:[email-masked]> <[email-masked]>;
>
> [email-masked] <mailto:[email-masked]> <[email-masked]>; [email-masked] <
> mailto:int <int>-
>
> [email-masked] <mailto:[email-masked]>
> <[email-masked]>; Brian E
>
> <mailto:[email-masked]> <[email-masked]>>
>
> then
> rfc2464? Section 4.5.1 is already clear on that.
>
> I think the only thing we are asking you is to change the following
>
> paragraph:
>
>
> OLD: A subnet is formed by the external 802.11-OCB interfaces of vehicles
> that are in close range (not by their in-vehicle interfaces).  This subnet
> MUST use at least the link-local prefix fe80::/10 and the interfaces MUST
> be assigned IPv6 addresses of type link-local.
>
> NEW: A subnet is formed by the external 802.11-OCB interfaces of vehicles
> that are in close range (not by their in-vehicle interfaces). A node MUST
> form a link-local address on this link.
>
> Alexandre, Right, so it doesn’t sound like you have any reason to be
> different
>
> from
>
> RFC2464.
>
> <mailto:[email-masked]> <[email-masked]>>
> wrote:
>
>
>
>
> qualifies the "/10". I think you could rephrase as "This subnet's prefix
> MUST lie within the link-local prefix fe80::/10 ..."
>
> I think there might be unexpected side effects from using an address like
> fe80:1::1. What if some code uses matching with fe80::/64 to test if
> 5.  Link-Local Addresses The IPv6 link-local address [AARCH] for an
> Ethernet interface is formed
> to
> the prefix FE80::/64. 10 bits            54 bits
> 64 bits +----------+-----------------------+----------------------------+
>
>
>
>
>
> between the multiple 802.11-OCB interfaces that might
>  be present in
>
> the
>
> same computer.
>
>
> Do you assume bridging of 802.11-OCB interface to Ethernet
>
> interface is
>
> always there?
>
>
> 'bridging'.  I do not know whether you refer to that perspective.  If yes,
>
> we can
>
> discuss it separately.
>
>
> Alex
>
> [...]
>
> [email-masked] <mailto:[email-masked]> <[email-masked]>
> [email-masked] <mailto:[email-masked]> <[email-masked]>
> its mailing list

-- 

---

I may have sent this email out of office hours. I never expect a response
outside yours.

---

From: 神明達哉 <[email-masked]>
Date: Thu, 11 Apr 2019 08:21:36 -0700

At Thu, 11 Apr 2019 13:26:59 +0200,

> than 64.  Because of that report, I believe openbsd will also work ok

I guess you mean this thread:
https://mailarchive.ietf.org/arch/msg/ipv6/2dnG1_yJON6zpGKz7YRWgI55iMc

It's a big logical leap to conclude that fe80:1::1(/32) can be used as
a link-local address from that discussion.  First, it's quite clear
that it's largely about generating global addresses.  In fact, the
implementor actually clarified that "/64" is used for link-local
addresses:
https://mailarchive.ietf.org/arch/msg/ipv6/WetxgYx-kJ1p4xUZbFxf6BikEks

Secondly, even if this could be interpreted as if this implementation
allows 96-bit IIDs for link-local addresses, that doesn't mean it can
use a non-0 bit in the (now 22-bit) intermediate field.  At best it
can only mean "fe80:1::1/10" (using a 118-bit interface ID) would be
allowed.

> - using fe80::/10 on Cisco, linux and openbsd works ok.

you confirm it literally "works" by running it by yourself, rather
than just deducing a conclusion from someone else's word in a
different topic in your favor.  Otherwise your other assertions will
look similarly implausible.

Anyway, as ipv6-over-80211ocb now seems to be removing the possibly
misleading text of "fe80::/10" intending to allow a non-0 value in the
intermediate 54 bits of link-local addresses, I have no more comment
on this in this thread.  I'll stop here.

--
JINMEI, Tatuya

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 11 Apr 2019 18:28:34 +0200

Le 11/04/2019 à 17:21, 神明達哉 a écrit :
> Alexandre Petrescu <[email-masked] 

I agree with the comments on your email.  NExt time I talk about 
implementations I do, not deduced from others' tests.

The text now indeed removes fe80::/10.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 11 Apr 2019 19:09:49 +0200

William,

I agree with your comments.

The assumptions about physical topology, and cars overtake each other
and their bumper-to-bumper situation changes; if cars can overtake
each other the cloud will tell them their new situation, so change
the channels.  And, in a platoon (V2V) cars should not overtake each other.

With respect to whether or not the specification should work when there
is only one OCB on top of the car: it should.  Only one OCB interface on
top of a car, and IPv6 Road-Side Unit connected on 4G/IPv6 to the
Internet: it worked for me with two cars and one RSU outdoors, in a real
road South East of France in year 2015.  It accesses the Internet with
Mobile IPv6 and IPv6-over-OCB, and some NATv6 (because 4G only gives
RSU a /64, and we need more).  For more cars to V2I: one should try this 
V2I scenario before claiming it does not work.

Moreover, V2I is more than just a car accessing the Internet through an
RSU.

It is also about a car talking directly to a traffic lights controller,
without accessing the Internet.  I have a trial ongoing about this (you
can see the preliminaries of it if you try to browse a real traffic
lights controller but situated - for now - in-lab at 193.48.19.10).  The 
practical issues we have at this time is the support of IPv4 (RSU only 
supports IPv4 and that will not change in the next few years) and 
certificates (you will understand the certificate problem if you try to 
browse it).  The practical issues are not about transitivity A-B-C or 
MANET/6lo; these solutions (transitivity A-B-C MANET/6lo) will not help 
such IP-over-OCB V2I deployment in any way.  Maybe you know about other
IP-over-OCB V2I deployments that have other problems whose solutions
need MANET/6lo and transitivity A-B-C.

There is also V2X: mainly Vehicle-to-Vulnerable-Road-User.  I tested it
with CAMs on real road.  The issues there are about low visibility of
the top antenna to other persons (it misses the potential poussette
pushed by lady on passage pietons - it's too low), and the lack of OCB
drivers on Android.  The quick solution to that is the car brains to
send the CAM on IP (not on GeoNetworking) but on in-car Ethernet and
then further on 4G to the cloud, and the person's smartphone to search
for it on the cloud.  Again here noone that I worked with suggested the
MANET/6lo transitivity A-B-C solutions.  Rather, they suggest the use of
smartglasses and smartwatch because it is the future.  The smartglasses
are WiFi, so we could use IP on them (even though not IPv6).  The
smartwatch has Bluetooth LE.  But nobody suggested to use IP on
Bluetooth.  Just dongle the watch to smartphone and use the IP of the 
smartphone.  IP on bluetooth does not solve any problem that we were 
facing there.

BAsed on my own experience on the above, this is about re-assuring:

About the reassuring question:  I can not reassure that IP will still
work on a PHY MAC of a single OCB interface on top of car that is not
used how it is designed to be used.

I can reassure you that IP works fine on single OCB interface on top of
car whose MAC and PHY are set correctly, even when only one antenna on
top of car; but best is to put 2 antennas in MIMO mode on top of the
car, to have more reassurance of good PHY setup of that single
interface.  (this MIMO recommendation again has nothing to do with
MANET/6lo nor transitivity A-B-C nor DAD nor ND).

Alex

Le 11/04/2019 à 17:15, William Whyte a écrit :
> Hi Alex -- there *can* be multiple OCB interfaces in one car, but
> should the standard be written assuming that there are multiple OCB
> interfaces? I would have thought that the goal would be to write a
> standard that works even if there's a single OCB interface.
> 
> If we're relying on multiple OCB interfaces to make this work, how
> many of those interfaces per car are we relying on? We can't
> presumably be assuming a distinct interface for each remote car that
> the local car is communicating with. If we aren't assuming a distinct
> interface for each remote car, then doesn't the problem that Pascal
> identifies come up?
> 
> (You also mention that the antenna at the front of car B communicates
>  with the one at back of car A -- but what if A overtakes B? And to
> be clear, I'm not asking for a direct answer to that question, I'm
> saying that if there are assumptions about the physical topology that
> we're relying on, we need to make those assumptions very clear and
> make them clear up front)
> 
> I'd be very concerned if we were writing a standard that didn't work
> if there was only one OCB interface in the car. Can you reassure me
> on that?
> 
> Cheers,
> 
> William
> 
> 
> 
> 
> On Thu, Apr 11, 2019 at 5:25 AM Alexandre Petrescu 
>> Please allow me to change the subject of this, to reflect the 
>> content. It helps tracking the discussion.
>> 
>>> I meant broadcast at layer 2 not layer 3. L3 uses multicast but 
>>> it requires a service at the lower layer to implement it. This
>>> is rarely if ever a real L2 multicast service.
>> 
>> I can agree.
>> 
>>> IOW the IETF has thrown the problem over the fence to the IEEE
>>> but it is not really solved to this day.
>> 
>> I think indeed there is redirection of responsability to IEEE.
>> Maybe IEEE does not like to do it, because of some reasons.
>> 
>> With respect to link-layer multicast: there is indeed no IEEE 
>> messaging for creation or removal of link-layer multicast groups
>> (like in IP there is MLDv2).  But there is concept of link-layer
>> multicast groups at IEEE. This is used extensively by mapping IP
>> groups into link-layer groups, and it helps IP.
>> 
>> Should IEEE develop a mechanism using messages (not just local 
>> filters) for creating these link-layer groups?
>> 
>>> In practice, the service that is performed on IEEE std 802.3 is
>>> a broadcast over a broadcast domain, and the subnet has to be 
>>> contained within that domain.
>> 
>> Well yes and no.
>> 
>> link-layer multicast on 802.3 if we talk IPv6: the link-layer 
>> addresses ofIPv6 on Ethernet are link-layer multicast addresses.
>> 
>>> The broadcast operation is emulated on IEEE std 802.11 by the
>>> BSS operation whereby the AP reflects the message to be
>>> broadcasted, so the broadcast domain is that of the AP as opposed
>>> to that of the source STA.
>> 
>> I agree.
>> 
>>> By the proposed definition, if car A sees car B they are in the
>>> same subnet. If car B sees car C they are in the same subnet. 
>> PAscal, again, this depends on how you set up the OCB interfaces on
>> cars A, B and C.
>> 
>> There are two options: - use a single OCB interface with antenna
>> sitting on top of each automobile.  Make them all in the same
>> channel frequency (e.g. CCH - Control Channel).  That indeed has
>> that A-B-C transitivity aspect. Worse, it has scalability issues:
>> one cant grow a convoy beyond a few tens of meters and be sure the
>> frontmost talks directly to the rearmost.  One never knows whether
>> somebody in the middle repeats, or not.  Or one needs to  rely on
>> MANET protocols that may forward on a single interface.  It has
>> some PHY issues as well, that I can describe.  The powerpoint is
>> readily filled with my last PHY experiments of propagation. - use
>> multiple OCB antennas situated at some strategic places in a car. 
>> This is in the same way as when placing the other ultra sound, 
>> radar and lidar sensors in the automobile.
>> 
>> An OCB interface in the front bumper of one car forms a subnet
>> with another OCB interface in the rear bumper of another car, on a 
>> particular channel (SCHx - service channel number x).  The front 
>> and rear subnets of a car are in distinct channels.  There is no
>> A-B-C transitivity.  There is IP forwarding between front and rear 
>> interfaces of a car.
>> 
>> This can be described.  But I dont think it should be described in 
>> the IP-over-OCB document.  It is a PHY MAC setting for OCB.
>> 
>>> there is no BSS by definition of OCB to emulate a broadcast
>>> domain between them via an AP. End result is that a DAD or a
>>> lookup by car A will not reach car C.
>> 
>> That may be true, but it is true mostly in a setting where each car
>> uses a single OCB interface whose antenna is placed on the roof of
>> the car (placed at same place as the the GPS, LTE, FM or DVB-T
>> antennas are placed).
>> 
>> In settings where each car has multiple OCB interfaces and
>> multiple antennas placed at strategic places (strategic: places
>> that are relevant to PHY propagation conditions), rather than
>> simply on the roof, the issue you describe in the above paragraph.
>> 
>> Now, if you read up to here, I would like to ask you (without 
>> claiming to be all-knowing), whether you think a car could have
>> several OCB interfaces?
>> 
>>> By traditional MANET and 6lo definition, the radio broadcast 
>>> domain of a node is his link.
>> 
>> For my part, I do not use the traditional MANET and 6lo
>> definitions because I believe they are not sufficient for vehicular
>> environments.
>> 
>>> In you lab you can arrange that the broadcast domains of 3 cars 
>>> fully overlap.
>> 
>> I agree, people do that.  It is in small lab, with size in the 
>> range of a few meters; there is much reflexion from the walls.  It
>> is not outdoors.
>> 
>>> In that case, the link appears to match the common sense of a 
>>> link in wires and the classical IPv6 operations will work pretty
>>> much the same as in a BSS over that Link. It is for example easy
>>> to place a subnet that matches that Link. It is also easy to
>>> confuse a Link with a Subnet, which is what the definition does.
>>> As soon as the broadcast domains start diverging, things get
>>> hairy, see all the work by Erik about split subnet etc...
>> 
>> carefully design the use of the propagation models (e.g. avoid 
>> 'omni', consider 'directional', etc) then one can avoid many
>> problems forbidding IP from running on wireless.
>> 
>>> The IETF has studied this situations for 10+ years at MANET, 
>>> 6TiSCH and 6lo. We have an architecture that cover single link 
>>> and multilink subnets.
>> 
>> Yes, there is.
>> 
>>> In the former case, the link is defined by one node that owns
>>> the prefix. In the latter case, routing is required inside the
>>> subnet and we created RPL to cover the situation.
>> 
>> YEs, but these are departures from what might be called traditional
>> IP forwarding.  That forwarding happens between two distinct
>> interfaces.
>> 
>> In practice it means little software for MANET-6lo-multilink is 
>> publicly available, and the engineer skill about them is hard to
>> find. This translates to equipment being very expensive.
>> 
>> I want to tell you that communication equipment for cars is already
>> very high compared to an off-the-shelf WiFi router.  That high
>> price tag is due also to specification of things that are too
>> intelligent and that require high skills from few people.  This is
>> the case of V2X stacks doing ETSI CAM with GeoNetworking and
>> similar.  You end up with a 3000Eur IP-OBU when its underlying
>> hardware with linux and traditional IP forwarding costs around
>> 700Eur.
>> 
>>> We created RFC 8505 for an host to connect to the network in 
>>> either situation, without the requirement that the L2 broadcast 
>>> domain of the host (its Link) overlaps with that of other nodes 
>>> in the subnet (because they don't). We have made RFC 8505 
>>> abstract to the routing protocol if any, IOW without the 
>>> requirement that the host knows there is a MLSN, understands RPL 
>>> or whatever other routing is used
>> 
>> MLSN?
>> 
>>> dependency that a L2 broadcast from the host reaches all nodes
>>> in the subnet, IOW that the subnet is contained within the Link
>>> of all of
>> 
>> IOW?
>> 
>>> its members, IOW that the Links of all the nodes in the subnet 
>>> fully overlap. This meant we had to abandon the idea of using 
>>> multicast in ND for DAD and AR.
>>> 
>>> Maybe someone can explain that better than I did. I so please be 
>>> my guest. I really tried but I'm not convinced I did not waste
>>> my time with the authors of the draft.
>> 
>>>> -----Original Message----- From: Int-dir 
>>>> <[email-masked]> <mailto:[email-masked]> On
>>>> Behalf Of Brian E Carpenter Sent: jeudi 11 avril 2019 09:54
>>>> To: NABIL BENAMAR <[email-masked]> 
>>>> <mailto:[email-masked]>; Pascal Thubert (pthubert) 
>>>> <[email-masked]> <mailto:[email-masked]> Cc: 
>>>> [email-masked] <mailto:[email-masked]>;
>>>> <mailto:[email-masked]>; Ole Troan 
>>>> <[email-masked]> <mailto:[email-masked]> Subject: 
>>>> Re: [Int-dir] Intdir early review of 
>>>> No, we talk about multicast. Pascal was using shorthand. But
>>>> if multicast fails with high probability, several aspects of
>>>> IPv6 will fail too, unless the LAN provides an NBMA
>>>> (non-broadcast multiple access) emulation of multicast, or
>>>>>>> The operation of the Neighbor Discovery protocol (ND)
>>>>>>> over 802.11-OCB links is different than over 802.11
>>>>>>> links.  In OCB, the link layer does not ensure that all
>>>>>>> associated members receive all messages, because there is
>>>>>>> no association operation.  Neighbor Discovery (ND) is
>>>>>>> used over 802.11-OCB.
>>>> 
>>>> but it was inconsistent and was removed. If Ole is correct
>>>> below about real-life conditions, the *problem* was not removed
>>>> and the draft is not going to work in the real world.
>>>> 
>>>> Brian
>>>> 
>>>>> 
>>>> <[email-masked] <mailto:[email-masked]> 
>>>> <mailto:[email-masked]> <mailto:[email-masked]>>
>>>> wrote:
>>>>> 
>>>>> Hello Ole:
>>>>> 
>>>> by step to a potentially large number of cars such that there
>>>> is no broadcast domain that covers them all. If there is no
>>>> broadcast domain and no multicast emulation like a BSS does,
>>>> how can we run ND? Yes, it works with 3 cars in a lab.
>>>>> 
>>>> concept of link, whereby my link joins the collection of nodes
>>>> that my radio can reach.
>>>>> 
>>>>> All the best,
>>>>> 
>>>>> Pascal
>>>>> 
>>>>>> -----Original Message----- From: Ole Troan 
>>>>>> <[email-masked] <mailto:[email-masked]>
>>>> <mailto:[email-masked]> <mailto:[email-masked]>>
>>>>>> <mailto:[email-masked]>
>>>> <mailto:[email-masked]> 
>>>>>> <mailto:[email-masked]>
>>>> <mailto:[email-masked]> <mailto:[email-masked]>>; 
>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]> 
>>>> <mailto:[email-masked]>;
>>>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]> 
>>>>>> <mailto:[email-masked]> <mailto:int-
>>>> [email-masked] <mailto:[email-masked]>>;
>>>> draft-ietf-ipwave-ipv6-over-
>>>>>> <mailto:[email-masked]>
>>>>>> <mailto:[email-masked]>; Brian E
>>>> <mailto:[email-masked]> 
>>>> <mailto:[email-masked]> 
>>>>>> draft-ietf-ipwave-ipv6-over- 80211ocb-34 - 'conforming
>>>>>> Clarify what? That a link-layer that looks an awfully lot
>>>>>> like Ethernet should not follow
>>>> the
>>>>>> 64-bit boundary and the definition of the link-local
>>>>>> OLD: A subnet is formed by the external 802.11-OCB
>>>>>> interfaces of vehicles that are in close range (not by
>>>>>> their in-vehicle interfaces).  This subnet MUST use at
>>>>>> least the link-local prefix fe80::/10 and the interfaces
>>>>>> MUST be assigned IPv6 addresses of type link-local.
>>>>>> 
>>>>>> NEW: A subnet is formed by the external 802.11-OCB
>>>>>> interfaces of vehicles that are in close range (not by
>>>>>> their in-vehicle interfaces). A node MUST form a link-local
>>>>>> address on this link.
>>>>>> 
>>>>>>>> Alexandre, Right, so it doesn’t sound like you have
>>>>>>>> any reason to be different
>>>> from
>>>>>> RFC2464.
>>>>>> <mailto:[email-masked]>
>>>> <mailto:[email-masked]> 
>>>>>>>>>>>>> To me there is nothing in the actual text to
>>>>>>>>>>>>> tell me that "at
>>>> least"
>>>>>>>>>>>>> qualifies the "/10". I think you could
>>>>>>>>>>>>> rephrase as "This subnet's prefix MUST lie
>>>>>>>>>>>>> However, see Jinmei's messages about
>>>>>>>>>>>>> conformance with RFC
>>>> 4291.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I think there might be unexpected side
>>>>>>>>>>>>> effects from using an address like fe80:1::1.
>>>>>>>>>>>>> What if some code uses matching with
>>>>>>>>>>>>> fe80::/64 to test if an address is
>>>>>>>>>>>>> link-local? I agree that would be faulty
>>>>>>>>>>>>> code, but you would be the first to discover
>>>>>>>>>>>>> it.
>>>>>>>>>>>> address [AARCH] for an Ethernet interface is
>>>>>>>>>>>> formed by appending the Interface Identifier,
>>>>>>>>>>>> as defined above,
>>>> to
>>>>>>>>>>>> the prefix FE80::/64. 10 bits            54
>>>>>>>>>>>> bits 64 bits 
|1111111010|         (zeros)       |    Interface
>>>>>>>>> Identifier    |
>>>>>>>>>>>> other 802.3
>>>> links?
>>>>>>>>> 
>>>>>>>>> In the IP-OBUs that I know there is IP forwarding
>>>>>>>>> between 802.11-
>>>> OCB
>>>>>> interfaces are indeed bridged.  E.g. the Ethernet interface
>>>>>> is bridged to
>>>> the
>>>>>> WiFi interface; that helps with DHCP, tcpdump and others to
>>>>>> see one a
>>>> single -
>>>>>> bridged - interface.
>>>>>>>>> 
>>>>>> between the 802.11-OCB interface and other interface,
>>>>>> neither bridging between the multiple 802.11-OCB interfaces
>>>>>> that might be present in
>>>> the
>>>>>> same computer.
>>>>>>>>> 
>>>>>>>>>>>> If the two assumptions above hold, then I see
>>>>>>>>>>>> zero justification
>>>> for
>>>>>>>>> Int-dir mailing list [email-masked]
>>>>>>>>> <mailto:[email-masked]> <mailto:[email-masked]>
>>>>>>>>> <mailto:[email-masked]> 
>>>>>>> <mailto:[email-masked]> <mailto:[email-masked]> 
> [email-masked] <mailto:[email-masked]> 
> I may have sent this email out of office hours. I never expect a 
> response outside yours.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 11 Apr 2019 19:25:13 +0200

Le 11/04/2019 à 19:09, Alexandre Petrescu a écrit :
[...]
> browse it).

Speaking of which, I am currently looking for someone to test the DIASER 
UDP protocol on IPv4 to query this traffic lights controller.  In a 
secure manner, because the data is sensitive.  I have the python scripts 
ready for DIASER on UDP on IPv4, to query the traffic lights status and 
their expected (well like in weather prediction) state duration.

If successful, then we can talk about writing an individual Internet 
Draft containing an IPv4 RIO in an IPv6 RA over OCB, to allow making a 
direct IP path from the car to talk directly to the traffic lights.  A 
colleague programmer is already interested.

I also asked a few of the current project partners, but they are not 
interested for the moment - lack of time, at this time.  They tell me it 
should be me on the RSU who does that DIASER and then convert it to SPAT 
and upload it to cloud.  When I reply with the end-to-end principle (let 
the cloud query the controller, rather than in-middle convertor), they 
tell me that everybody does it that way (RSU reads controller data, and 
RSU uploads to cloud).  So I am trying to show a different way is 
possible: make the cloud query the traffic lights controller, and the 
car query the traffic lights controller, and anybody who so wishes, yet 
in a secure manner (probably some form of certificates).

That is a current problem that I have.

Alex

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 12 Apr 2019 08:49:56 +1200

Hi,

If there are multiple interfaces, it seems to me that you automatically have the situation described by Pascal, in which traditional Ethernet-like multicast ND, DAD and RA simply do not work. 

> a standard that works even if there's a single OCB interface.

That's the easy case.

Regards
   Brian

On 12-Apr-19 03:15, William Whyte wrote:
> Hi Alex -- there *can* be multiple OCB interfaces in one car, but should the standard be written assuming that there are multiple OCB interfaces? I would have thought that the goal would be to write a standard that works even if there's a single OCB interface.
> 
> If we're relying on multiple OCB interfaces to make this work, how many of those interfaces per car are we relying on? We can't presumably be assuming a distinct interface for each remote car that the local car is communicating with. If we aren't assuming a distinct interface for each remote car, then doesn't the problem that Pascal identifies come up?
> 
> (You also mention that the antenna at the front of car B communicates with the one at back of car A -- but what if A overtakes B? And to be clear, I'm not asking for a direct answer to that question, I'm saying that if there are assumptions about the physical topology that we're relying on, we need to make those assumptions very clear and make them clear up front)
> 
> I'd be very concerned if we were writing a standard that didn't work if there was only one OCB interface in the car. Can you reassure me on that?
> 
> Cheers,
> 
> William
> 
> 
> 
> 
> On Thu, Apr 11, 2019 at 5:25 AM Alexandre Petrescu <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Pascal,
> 
>>>     I meant broadcast at layer 2 not layer 3. L3 uses multicast but it requires a service at the lower layer to implement it. This is rarely
>>>     In practice, the service that is performed on IEEE std 802.3 is a broadcast over a broadcast domain, and the subnet has to be contained
>>>     within that domain.
>>
>>     Well yes and no.
>>
>>>      subnet. If car B sees car C they are in the same subnet. Transitively Car A is in the same subnet as car C.
>>
>>>     By traditional MANET and 6lo definition, the radio broadcast domain of a node is his link.
>>
>>>     The IETF has studied this situations for 10+ years at MANET, 6TiSCH and 6lo. We have an architecture that cover single link and multilink
>>>     subnets.
>>
>>     Yes, there is.
>>
>>>     We created RFC 8505 for an host to connect to the network in either situation, without the requirement that the L2 broadcast domain of the host (its Link) overlaps with that of other nodes in the subnet (because they don't). We have made RFC 8505 abstract to the routing protocol if any, IOW without the requirement that the host knows there is a MLSN, understands RPL or whatever other routing is used
>>
>>     MLSN?
>>
>>>     its members, IOW that the Links of all the nodes in the subnet fully overlap. This meant we had to abandon the idea of using multicast in ND for DAD and AR.
>>>
>>>>     -----Original Message----- From: Int-dir <[email-masked]> <mailto:[email-masked]>
>>>>     NABIL BENAMAR <[email-masked]> <mailto:[email-masked]>; Pascal Thubert (pthubert)
>>>>      <[email-masked]> <mailto:[email-masked]> Cc: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; draft-ietf-ipwave-ipv6-over- [email-masked] <mailto:[email-masked]>; Alexandre Petrescu <[email-masked]> <mailto:[email-masked]>; Ole Troan <[email-masked]> <mailto:[email-masked]> Subject: Re: [Int-dir] Intdir early review of draft-ietf-ipwave-ipv6-over- 80211ocb-34 - 'conforming IPv6' - fe80::/10 vs fe80::/64
>>>>
>>>>     Hi Nabil,
>>>>
>>>>     No, we talk about multicast. Pascal was using shorthand. But if multicast fails with high probability, several aspects of IPv6 will
>>>>>>>     The operation of the Neighbor Discovery protocol (ND) over 802.11-OCB links is different than over 802.11 links.  In OCB, the link layer does not ensure that all associated members receive all messages, because there is no association
>>>>     <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>> wrote:
>>>>>
>>>>>     Hello Ole:
>>>>>
>>>>     broadcast domain that covers them all. If there is no broadcast domain and no multicast emulation like a BSS does, how can we run ND? Yes, it works with 3 cars in a lab.
>>>>>
>>>>>>     -----Original Message----- From: Ole Troan <[email-masked] <mailto:[email-masked]>
>>>>>>     Sent: mercredi 10 avril 2019 20:41 To: Alexandre Petrescu <[email-masked] <mailto:[email-masked]>
>>>>     <mailto:[email-masked]> <mailto:[email-masked]>>
>>>>>>     Cc: Pascal Thubert (pthubert) <[email-masked] <mailto:[email-masked]>
>>>>     <mailto:[email-masked]> <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>;
>>>>>>     [email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]> <mailto:int-
>>>>     [email-masked] <mailto:[email-masked]>>; draft-ietf-ipwave-ipv6-over-
>>>>>>     [email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>; Brian E
>>>>     Carpenter <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>>
>>>>>>     Subject: Re: [Int-dir] Intdir early review of draft-ietf-ipwave-ipv6-over- 80211ocb-34 - 'conforming IPv6' -
>>>>>>      fe80::/10 vs fe80::/64
>>>>>>
>>>>>>     64-bit boundary and the definition of the link-local address mapping of rfc2464? Section 4.5.1 is already clear on that.
>>>>>>
>>>>>>     OLD: A subnet is formed by the external 802.11-OCB interfaces of vehicles that are in close range (not by their in-vehicle interfaces).  This subnet MUST use at least the link-local prefix fe80::/10 and the interfaces MUST be assigned IPv6 addresses of type link-local.
>>>>>>
>>>>>>     NEW: A subnet is formed by the external 802.11-OCB interfaces of vehicles that are in close range (not by their in-vehicle interfaces). A node MUST form a link-local address on this link.
>>>>>>
>>>>>>>>     Alexandre, Right, so it doesn’t sound like you have any reason to be different
>>>>     from
>>>>>>     RFC2464.
>>>>>>     <[email-masked] <mailto:[email-masked]>
>>>>     <mailto:[email-masked]> <mailto:[email-masked]>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>     qualifies the "/10". I think you could rephrase as "This subnet's prefix MUST lie within the link-local prefix fe80::/10 ..."
>>>>>>>>>>>>>
>>>>>>>>>>>>>     I think there might be unexpected side effects from using an address like fe80:1::1. What if some code uses matching with fe80::/64 to test if
>>>>>>>>>>>>     5.  Link-Local Addresses The IPv6 link-local address [AARCH] for an Ethernet interface is formed
>>>>>>     between the 802.11-OCB interface and other interface, neither bridging between the multiple 802.11-OCB interfaces that might
>>>>>>      be present in
>>>>     the
>>>>>>     same computer.
>>>>>>>>>
>>>>>>>>>     _______________________________________________ Int-dir mailing list [email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/int-dir
>>>>>>>
>>>>>>>     _______________________________________________ Int-dir mailing list [email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/int-dir
>>>>>
>>>>
>>>>     _______________________________________________ Int-dir mailing list [email-masked] <mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/int-dir
> I may have sent this email out of office hours. I never expect a response outside yours.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 11 Apr 2019 23:27:13 +0000

Sadly my comments are far from resolved, Alex.

You still refine a layer-2 portal (a fully IEEE concept) on your own terms using BCP 14. I cannot agree with trying to publish something that will be a direct conflict.

You still have a definition of a subnet which is widely confused with that of a link. You need to clarify for yourself what those concepts are and then you can start writing text on how to apply them on OCB. Your question on multiple interfaces shows there’s a long way to go.

In that path you will need to learn about full mesh vs. NBMA, broadcast domains, route over (routers) vs mesh under (L3 switches), connected dominating sets and transitive properties. Once you get there you’ll realize that the number of interfaces doesn’t matter long as you have at least one, that your text on subnet definition doesn’t work and you may even recommend RFC 8505, who knows.

Also you’ll need to differentiate architecture and implementation so you avoid spreading misconceptions like your issues on bridging .11 and .3. The portal works from the architecture standpoint. The implementation you played with may have difficulties. 

Cheers 

Pascal 

Regards,

Pascal

> Le 11 avr. 2019 à 22:00, Alexandre Petrescu <[email-masked]> a écrit :
> 
> Pascal,
> 
> The ND text was modified, and an annex was added containing your own text, but with removal of RECOMMENDED of your preferred RFC, replaced with some lower case qualifiers instead.
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 12 Apr 2019 01:02:48 +0000

True, Brian, and the point behind it is that you’re already there with a single interface unless special precautions have been taken care of, which can not be assumed outside of the lab. Which makes the whole discussion of how many interfaces secondary.

Bottom line is that the link as defined by “my broadcast domain” is single ended (my view not a common view), not fully guaranteed to be reflexive due to asymmetries, and almost guaranteed to be non transitive.

On a network like that you may model p2p, hub/spoke like .11 does at L2, or NBMA with a support for MLSN either mesh under or route over. Certainly not as transit. 

RFC 4861 will give you p2p and transit.

The intersection is p2p... 

Take care,

Pascal

> Le 12 avr. 2019 à 07:27, Pascal Thubert (pthubert) <[email-masked]> a écrit :
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 12 Apr 2019 10:42:05 +0200

Le 11/04/2019 à 22:49, Brian E Carpenter a écrit :
> Hi,
> 
> If there are multiple interfaces, it seems to me that you
> automatically have the situation described by Pascal, in which
> traditional Ethernet-like multicast ND, DAD and RA simply do not
> work.

Brian,

IPv6 ND on multiple OCB interfaces of an IP-OBU Router works ok.  Each 
interface has its own subnet, with its own ND, DAD and RA.  The router 
forwards IP packets between these interfaces.  It has a routing table.

I do not understand what do you mean when you say that EThernet-like 
multicast ND, DAD and RA simply do not work.

I agree.

Alex

> Regards Brian
>> presumably be assuming a distinct interface for each remote car
>> that the local car is communicating with. If we aren't assuming a
>> distinct interface for each remote car, then doesn't the problem
>> that Pascal identifies come up?
>> 
>> (You also mention that the antenna at the front of car B
>> communicates with the one at back of car A -- but what if A
>> overtakes B? And to be clear, I'm not asking for a direct answer to
>> that question, I'm saying that if there are assumptions about the
>> physical topology that we're relying on, we need to make those
>> assumptions very clear and make them clear up front)
>> 
>> I'd be very concerned if we were writing a standard that didn't
>> work if there was only one OCB interface in the car. Can you
>> reassure me on that?
>> 
>> Cheers,
>> 
>> William
>> 
>> 
>> 
>> 
>>>> broadcasted, so the broadcast domain is that of the AP as
>>>> opposed to that of the source STA.
>>> 
>>> I agree.
>>> 
>>> PAscal, again, this depends on how you set up the OCB interfaces
>>> on cars A, B and C.
>>> 
>>> one cant grow a convoy beyond a few tens of meters and be sure
>>> the frontmost talks directly to the rearmost.  One never knows
>>> whether somebody in the middle repeats, or not.  Or one needs to
>>> rely on MANET protocols that may forward on a single interface.
>>> It has some PHY issues as well, that I can describe.  The
>>> powerpoint is readily filled with my last PHY experiments of
>>> propagation. - use multiple OCB antennas situated at some
>>> strategic places in a car. This is in the same way as when
>>> placing the other ultra sound, radar and lidar sensors in the
>>> automobile.
>>> 
>>> with another OCB interface in the rear bumper of another car, on
>>> a particular channel (SCHx - service channel number x).  The
>>> front and rear subnets of a car are in distinct channels.  There
>>> is no A-B-C transitivity.  There is IP forwarding between front
>>> and rear interfaces of a car.
>>> 
>>> This can be described.  But I dont think it should be described
>>> in the IP-over-OCB document.  It is a PHY MAC setting for OCB.
>>> 
>>>> But car C may not be in the radio broadcast domain of car A,
>>>> and there is no BSS by definition of OCB to emulate a broadcast
>>> That may be true, but it is true mostly in a setting where each
>>> car uses a single OCB interface whose antenna is placed on the
>>> roof of the car (placed at same place as the the GPS, LTE, FM or
>>> DVB-T antennas are placed).
>>> 
>>> definitions because I believe they are not sufficient for
>>> vehicular environments.
>>> 
>>> range of a few meters; there is much reflexion from the walls.
>>> It is not outdoors.
>>> 
>>>> link in wires and the classical IPv6 operations will work
>>>> pretty much the same as in a BSS over that Link. It is for
>>>> example easy to place a subnet that matches that Link. It is
>>>> also easy to confuse a Link with a Subnet, which is what the
>>>> definition does. As soon as the broadcast domains start
>>>> diverging, things get hairy, see all the work by Erik about
>>>> split subnet etc...
>>> 
>>> I think if one puts several interfaces and antennas in a car,
>>> and carefully design the use of the propagation models (e.g.
>>> avoid 'omni', consider 'directional', etc) then one can avoid
>>> many problems forbidding IP from running on wireless.
>>> 
>>> YEs, but these are departures from what might be called
>>> traditional IP forwarding.  That forwarding happens between two
>>> distinct interfaces.
>>> 
>>> I want to tell you that communication equipment for cars is
>>> already very high compared to an off-the-shelf WiFi router.  That
>>> high price tag is due also to specification of things that are
>>> too intelligent and that require high skills from few people.
>>> This is the case of V2X stacks doing ETSI CAM with GeoNetworking
>>> and similar.  You end up with a 3000Eur IP-OBU when its
>>> underlying hardware with linux and traditional IP forwarding
>>> costs around 700Eur.
>>> 
>>> protocols and 6lo multilink subnet moels you arrive at a cost
>>> per communication box that is the equivalent of a small car.
>>> 
>>>> requirement that the host knows there is a MLSN, understands
>>>> Maybe someone can explain that better than I did. I so please
>>>> be my guest. I really tried but I'm not convinced I did not
>>>> waste my time with the authors of the draft.
>>> 
>>>>> <[email-masked]> <mailto:[email-masked]> 
>>>>> On Behalf Of Brian E Carpenter Sent: jeudi 11 avril 2019
>>>>> 09:54 To: NABIL BENAMAR <[email-masked]>
>>>>> draft-ietf-ipwave-ipv6-over- 80211ocb-34 - 'conforming IPv6'
>>>>> - fe80::/10 vs fe80::/64
>>>>> 
>>>>> Hi Nabil,
>>>>> 
>>>>>>>> associated members receive all messages, because there
>>>>>>>> is no association operation.  Neighbor Discovery (ND)
>>>>>>>> is used over 802.11-OCB.
>>>>> 
>>>>> below about real-life conditions, the *problem* was not
>>>>> removed and the draft is not going to work in the real
>>>>> world.
>>>>> 
>>>>> Brian
>>>>> 
>>>>>> 
>>>>> concept of link, whereby my link joins the collection of
>>>>> nodes that my radio can reach.
>>>>>> 
>>>>>> All the best,
>>>>>> 
>>>>>> Pascal
>>>>>> 
>>>>>>> their in-vehicle interfaces). A node MUST form a
>>>>>>> link-local address on this link.
>>>>>>> 
>>>>>>>>>>>>>> To me there is nothing in the actual text
>>>>>>>>>>>>>> to tell me that "at
>>>>> least"
>>>>>>>>>>>>>> effects from using an address like
>>>>>>>>>>>>>> fe80:1::1. What if some code uses matching
>>>>>>>>>>>>>> with fe80::/64 to test if an address is
>>>>>>>>>>>>>> code, but you would be the first to
>>>>>>>>>>>>>> discover it.
>>>>>>> interfaces are indeed bridged.  E.g. the Ethernet
>>>>>>> interface is bridged to
>>>>> the
>>>>>>> WiFi interface; that helps with DHCP, tcpdump and others
>>>>>>> to see one a
>>>>> single -
>>>>>>> bridged - interface.
>>>>>>>>>> 
>>>>>>> neither bridging between the multiple 802.11-OCB
>>>>>>> interfaces that might be present in
>>>>> the
>>>>>>> same computer.
>>>>>>>>>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 12 Apr 2019 10:43:22 +0200

Pascal,

I propose that you edit the document and solve them yourself.

How can I help you?

Dont be sad.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 12 Apr 2019 11:05:22 +0200

if you dont know how to edit the document, here it is:

- download the xml -37 file from tools.ietf.org
   https://tools.ietf.org/id/draft-ietf-ipwave-ipv6-over-80211ocb-38.xml
- rename it to a -39 file
- inside the file docName="draft-ietf-ipwave-ipv6-over-80211ocb-39"
- modify it to solve your issues
- get approval from the WG, or from representatives
- dont add any new thing that has IPR
   dont add any new thing that has IPR
   dont add any new thing that has IPR
- check the draft with xml2rfc.ietf.org
- upload the xml to tools.ietf.org, button "Draft Submission"
- wait for approval from at least one co-author (I will approve it if I
   am ok; normally I am ok with many things now, as you have seen).

Alex

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 12 Apr 2019 11:06:03 +0200

Hi Pascal and Alexandre,

Thanks for your review and thanks to authors that made many changes from
draft -34 to 38.

I reply to both and sorry for the not able to always be on reply quickly
because of sadly war in my city Tripoli. My comments/reply below.

To: WG AD> I think any reviewer MUST read the IETF WG charter before
reviewing any of their draft. I hope that can be a rule/best-practice in
IETF in future.

> Sadly my comments are far from resolved, Alex.

I reply to your comments below on Draft-34 but please note that this draft
is now draft-38, and authors did do many efforts. So it may need a new
clarifications.

>
> You still refine a layer-2 portal (a fully IEEE concept) on your own terms
> using BCP 14. I cannot agree with trying to publish something that will be
> a direct conflict.
>
> You still have a definition of a subnet which is widely confused with that
> of a link. You need to clarify for yourself what those concepts are and
> then you can start writing text on how to apply them on OCB. Your question
> on multiple interfaces shows there’s a long way to go.
>

Don't understand your point (where is confusion to be solved!), if it is
not defined then please provide text to define the Link. In my opinion the
Link is known by the Link layer IEEE802.11-OCB. So let us focus discussion
on the IETF IPWAVE WG charter's first objective related to this link
IEEE802.11-OCB and not IEEE802.11 other modes nor IEEE802.15 nor any other
wireless Link (we are not doing per IETF-charter general wireless network
we are doing only one Wireless Link IEEE802.11-OCB which is different than
other IEEE802.11).

> In that path you will need to learn about full mesh vs. NBMA, broadcast
> domains, route over (routers) vs mesh under (L3 switches), connected
> dominating sets and transitive properties.

Also some IETF reviewers of our draft need to learn about IPWAVE.
In my opinion in this IETF WG we are not doing Full Mesh, also not Routing,
please look at the IETF IPWAVE WG charter, which does not mention that.
Please note that this WG charter does mention Carefully that this WG is
working on special Use Cases (ITS is a special case not like general work
of broadcast domains and connected systems).

> Once you get there you’ll realize that the number of interfaces doesn’t
> matter long as you have at least one, that your text on subnet definition
> doesn’t work and you may even recommend RFC 8505, who knows.
>

The number of interfaces does not matter as long as there is a connection.
If the text does not work then please mention why,

>
> Also you’ll need to differentiate architecture and implementation so you
> avoid spreading misconceptions like your issues on bridging .11 and .3. The
> portal works from the architecture standpoint. The implementation you
> played with may have difficulties.
>

You need to know the IP-WAVE architecture which I think you confuse about
because you want to make a general wireless network architecture. This
IPWAVE WG is not doing General wireless network architecture. Furthermore,
that misconceptions you referred to is not misconception if you look deep
in the use cases of IPWAVE. The bridging is important because in IPWAVE
cases most important communications (out-board not in board as you want to
include WPAN) is between RSU and Vehicle, which is important in this draft.

more replays/comments below,

> > I believe all issues you raised are solved in version -38.

ok

> > The editorial changes about text coherency are solved.
ok

> text, but with removal of RECOMMENDED of your preferred RFC, replaced with
> some lower case qualifiers instead.
> >

I responded to that before, ietf can define in any rfc what is important to
it in any architecture layer it likes. This WG is doing the IP-WAVE
architecture.

> >> thoughts, recommendation to use 6LoWPAN ND.

It was examined and used for WPAN not IPWAVE, in one other adopted draft in
our WG ware recommending different ND also,

> The definition of a subnet is

Ok, the subnet can be defined without discussing networking, we are
considering IP communication between two nodes only, for more than two or
multihop can be discussed in another draft.

> It seems that RSUs would have prefixes but that is not discussed.
ok

> >> see https://datatracker.ietf.org/group/intdir/about/

We are not doing 802.11 it is different mode and different communication
than OCB.

> >> Is this doc scoped to OCB or 802.11 in general?

Our IETF WG is Scoped to OCB, Please read about WG charter before review
any draft for any WG in IETF.

> >> IEEE LLC work. Who defines those fields, IETF or IEEE, or mixed?

it is defined by IEEE, but we need to add our views and definition while
doing IP over, any user would like to know what both IEEE and IETF say
about such technology (I would always like to know as a user).

> Who defines
> isolated

Yes it is defined by IEEE, they are different.

> >> Is this different from what an AP does when it bridges Wi-Fi to

You need to learn about IPWAVE. and Yes it is different, WiFi is different
environment from IEEE802.11-OCB, we are doing High Speed Communication that
WiFi cannot work and does not do, the Link data rate vs transmitted power
of WiFi is not like IEEE802.11-OCB, and different service mode.

> >> This is not specific enough to be actionable. I suggest to remove this

Why? The most important issue is that IPWAVE is under this special mode OCB.

> >> the specific needs of OCB vs. Wi Fi, but I do not see text about that.

This draft is not doing Comparison between technologies nor doing
Comparisons between Links, we have a specific objective which is defined in
our ietf charter.

> >> Why is that? This is unexpected, and hopefully wrong.

In IPWAVE cases MAC address is important to be consistent and for
geolocation communication synchronisation.

>> Minor issues

Yes we have cars that can be used in different countries and travels
between different regulations and communications.

Finally, the other minor issues you made was solved by Alex and the other
authors, and thanks to all our authors and reviewers.

Best Wishs
AB

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 12 Apr 2019 11:13:01 +0200

Hi Alex

I did not know that these messages are also added to IETF, it once was done
and I replied but I don't think we should make this review discussion on
IETF list.

Now I delete it from my sendings for now, but I think we should solve it
only in our WG list.

AB

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 12 Apr 2019 11:34:06 +0200

> even if there's a single OCB interface.

Yes a single OCB interface per frequency band, we cannot have many
interfaces per node for same frequency band in CSMA.

AB

>> guest. I really tried but I'm not convinced I did not waste my time with
>> the authors of the draft.
>>
>>
>> NABIL BENAMAR <[email-masked]> <[email-masked]>;
>> Pascal Thubert (pthubert)
>>  <pthubert@cisco..com> <[email-masked]> Cc: [email-masked];
>> [email-masked]; Alexandre Petrescu <[email-masked]>
>> broadcast domain that covers them all. If there is no broadcast domain
>> and no multicast emulation like a BSS does, how can we run ND? Yes, it
>> works with 3 cars in a lab.
>>
>>
>> yes,
>> Let me try  to understand the first assumption..
>>
>> Ole
>>
>>

---

From: NABIL BENAMAR <[email-masked]>
Date: Fri, 12 Apr 2019 15:14:42 +0100

Thank you for comments Abdussalam!

Bravo on being able to comment on this draft under such circumstances!

On Fri, Apr 12, 2019, 10:06 Abdussalam Baryun <[email-masked]>
wrote:

> > >> defines the use of L2 fields, what this spec enforces vs. recognizes
> as
> > being
> > >> implementer of IPv6 over Wi-Fi refers to this doc? Spelled as above,
> it
> > seems
> Why? The most important issue is that IPWAVE is under this special mode OCB

---

From: Nabil Benamar <[email-masked]>
Date: Fri, 12 Apr 2019 15:34:02 +0100

Hello Pascal,

I seconded Akex and would like to suggest you to add the missing text in
the draft.

Best regards
Nabil

On Mon, Apr 8, 2019, 14:01 Pascal Thubert (pthubert) <[email-masked]>
wrote:

> *From:* NABIL BENAMAR <[email-masked]>
> *Sent:* lundi 8 avril 2019 17:53
> *Cc:* Pascal Thubert (pthubert) <[email-masked]>; [email-masked];
> [email-masked]; [email-masked];
> On Mon, Apr 8, 2019, 10:01 Alexandre Petrescu <

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Fri, 12 Apr 2019 14:38:57 +0000

I am not following these discussions.  From my point of view, many of the discussions are totally out of scope for this document.

Some one needs to moderate these discussions.

Sri

From: its <[email-masked]<mailto:[email-masked]>> on behalf of Nabil Benamar <[email-masked]<mailto:[email-masked]>>
Date: Friday, April 12, 2019 at 7:34 AM
To: "Pascal Thubert (pthubert)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Nabil Benamar <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Alexandre Petrescu <[email-masked]<mailto:[email-masked]>>
Subject: Re: [ipwave] Intdir early review of draft-ietf-ipwave-ipv6-over-80211ocb-34

Hello Pascal,

I seconded Akex and would like to suggest you to add the missing text in the draft.

Best regards
Nabil

On Mon, Apr 8, 2019, 14:01 Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
Hello Nabil.

Cheers,

Pascal

From: NABIL BENAMAR <[email-masked]<mailto:[email-masked]>>
Sent: lundi 8 avril 2019 17:53
To: Alexandre Petrescu <[email-masked]<mailto:[email-masked]>>
Cc: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: Intdir early review of draft-ietf-ipwave-ipv6-over-80211ocb-34

Yes definitely Alex....

It is a late review.

Alex

Reviewer: Pascal Thubert

Review result: Not Ready

Reviewer: Pascal Thubert

Majors issues

-----------------

“

      802.11 than on Ethernet.

“

from IEEE fields.

"

"

an 802.11 header ...'

   layer.

"

this IETF business?

"

"

"

"

"

   time.

"

"

Among these types of

   EUI-64 identifier.

"

"

This

"

"

"

"

   802.11-OCB links.

"

"

"

Minor issues

---------------

   confidentiality.

"

"

Among these types of

  EUI-64 identifier.

"

"

"

value vs. 5.2

"

If semantically

   Stateless Address Autoconfiguration is given in [RFC7217]..

   privacy risks.

...

"

   attacks on privacy.

"

"

"

Also duplicate

Nits

------

"

"

BCP 14 text:

“

“

All the best

Pascal

_______________________________________________
its mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/its

---

From: NABIL BENAMAR <[email-masked]>
Date: Fri, 12 Apr 2019 15:44:49 +0100

I agree with you Sri!

It's worth noting that during the 2 last IETF meetings, we got the
impression that the draft needs just few adjustments. I think that the ND
issues should be tackled in a seperated document.

On Fri, Apr 12, 2019, 15:39 Sri Gundavelli (sgundave) <[email-masked]>
wrote:

> I am not following these discussions.  From my point of view, many of the
> discussions are totally out of scope for this document.
>
> From: its <[email-masked]> on behalf of Nabil Benamar <
> [email-masked]>
> To: "Pascal Thubert (pthubert)" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "
> [email-masked]" <[email-masked]>, Nabil Benamar <
> [email-masked]>, "
> [email-masked]" <
> [email-masked]>, Alexandre Petrescu <
> [email-masked]>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Fri, 12 Apr 2019 14:59:26 +0000

If you go back and check 2017 archives, I did raise many of these issues.  But, we clearly decided to limit the scope excluding address configuration, DAD, ND aspect, link models. When there is such a scope statement, it should clearly move these comments to the draft that defines how ND works for 802.11-OCB links.

https://mailarchive.ietf.org/arch/msg/its/9NvUfRigGd4Klu0Q2Ee-63ziATw

https://mailarchive.ietf.org/arch/msg/its/VcrwNSvNJVIZNcRLNjDY0iSw3CA

Sri

From: its <[email-masked]<mailto:[email-masked]>> on behalf of Sri Gundavelli <[email-masked]<mailto:[email-masked]>>
Date: Friday, April 12, 2019 at 7:38 AM
To: Nabil Benamar <[email-masked]<mailto:[email-masked]>>, "Pascal Thubert (pthubert)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Nabil Benamar <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Alexandre Petrescu <[email-masked]<mailto:[email-masked]>>
Subject: Re: [ipwave] Intdir early review of draft-ietf-ipwave-ipv6-over-80211ocb-34

Sri

Hello Pascal,

Best regards
Nabil

Cheers,

Pascal

Cc: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf..org>

Yes definitely Alex....

It is a late review.

Alex

Reviewer: Pascal Thubert

Review result: Not Ready

Reviewer: Pascal Thubert

Majors issues

-----------------

“

      802.11 than on Ethernet.

“

from IEEE fields.

"

"

an 802.11 header ...'

   layer.

"

this IETF business?

"

"

"

"

"

   time.

"

"

Among these types of

   EUI-64 identifier.

"

"

This

"

"

"

"

   802.11-OCB links.

"

"

"

Minor issues

---------------

   confidentiality.

"

"

Among these types of

  EUI-64 identifier.

"

"

"

value vs. 5.2

"

If semantically

   Stateless Address Autoconfiguration is given in [RFC7217]...

   privacy risks.

...

"

   attacks on privacy.

"

"

"

Also duplicate

Nits

------

"

"

BCP 14 text:

“

“

All the best

Pascal

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 12 Apr 2019 17:17:17 +0200

I agree with you Sri.
You raised these issues much earlier, even prior to WG formation.

WE discussed back and forth about this since long.  WE found a way 
forward each time: separate ND into another work.

Alex

Le 12/04/2019 à 16:59, Sri Gundavelli (sgundave) a écrit :
> If you go back and check 2017 archives, I did raise many of these 
> issues.  But, we clearly decided to limit the scope excluding address 
> configuration, DAD, ND aspect, link models. When there is such a scope 
> statement, it should clearly move these comments to the draft that 
> defines how ND works for 802.11-OCB links.
> 
> 
> From: its <[email-masked] <mailto:[email-masked]>> on behalf 
> of Sri Gundavelli <[email-masked] <mailto:[email-masked]>>
> To: Nabil Benamar <[email-masked] <mailto:[email-masked]>>, 
> "Pascal Thubert (pthubert)" <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] 
> <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" 
> <[email-masked] <mailto:[email-masked]>>, "[email-masked] 
> <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, 
> Nabil Benamar <[email-masked] 
> <mailto:[email-masked]>>, 
> "[email-masked] 
> <mailto:[email-masked]>" 
> <[email-masked] 
> <mailto:[email-masked]>>, Alexandre 
> Petrescu <[email-masked] 
> I am not following these discussions.  From my point of view, many of 
> the discussions are totally out of scope for this document.
> 
> From: its <[email-masked] <mailto:[email-masked]>> on behalf 
> of Nabil Benamar <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] 
> <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" 
> <[email-masked] <mailto:[email-masked]>>, "[email-masked] 
> <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, 
> Nabil Benamar <[email-masked] 
> <mailto:[email-masked]>>, 
> "[email-masked] 
> <mailto:[email-masked]>" 
> <[email-masked] 
> <mailto:[email-masked]>>, Alexandre 
> Petrescu <[email-masked] 
>     Hello Nabil.____
>     You will get a number of IESG reviews as part of the submission
>     process, one per area. This is just a beginning…____
> 
>     __ __
> 
>     Cheers,____
> 
>     __ __
> 
>     Pascal____
> 
>     __ __
> 
>     *From:* NABIL BENAMAR <[email-masked]
>     <mailto:[email-masked]>>
>     *Cc:* Pascal Thubert (pthubert) <[email-masked]
>     <mailto:[email-masked]>>; [email-masked]
>     <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>;
>     [email-masked] <mailto:[email-masked]>;
>     <mailto:draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf..org>
>     Yes definitely Alex....____
> 
>     __ __
> 
>     final review.____
>     On Mon, Apr 8, 2019, 10:01 Alexandre Petrescu
>     wrote:____
>         As a note: please improve the title of this.____
> 
>         It is not an early review.____
> 
>         It is a late review.____
> 
>         There have been several reviews of this document until here, and
>         two shepherd reviews.____
> 
>         Alex____
> 
>                 Stateless Address Autoconfiguration is given in [RFC7217]...____
> 
>             __  __
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 12 Apr 2019 17:21:51 +0200

I agree Nabil.

Several times we presented this draft.  Each time we agreed that ND may 
have an issue, admit it in text in the IP-OCB document, but do not solve 
it in this document.  That is what the current version of the draft 
admit there may be some ND issues, but do not solve it.

Even during the last presentation in Prague we said that.

Alex

Le 12/04/2019 à 16:44, NABIL BENAMAR a écrit :
> impression that the draft needs just few adjustments. I think that the 
> ND issues should be tackled in a seperated document.
> 
> On Fri, Apr 12, 2019, 15:39 Sri Gundavelli (sgundave) 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     I am not following these discussions.  From my point of view, many
>     of the discussions are totally out of scope for this document.
> 
>     From: its <[email-masked] <mailto:[email-masked]>> on
>     behalf of Nabil Benamar <[email-masked]
>     <mailto:[email-masked]>>
>     <mailto:[email-masked]>" <[email-masked]
>     <mailto:[email-masked]>>, Nabil Benamar <[email-masked]
>     <mailto:[email-masked]>>,
>     On Mon, Apr 8, 2019, 14:01 Pascal Thubert (pthubert)
>         <mailto:[email-masked]>
>         <mailto:[email-masked]>> wrote:____
> 
>             There have been several reviews of this document until here,
>             and two shepherd reviews.____
> 
>             Alex____
> 
>                     Stateless Address Autoconfiguration is given in [RFC7217]..____
> 
>                 __  __
>

---

From: Russ Housley <[email-masked]>
Date: Fri, 12 Apr 2019 11:46:48 -0400

> In that path you will need to learn about full mesh vs. NBMA, broadcast domains, route over (routers) vs mesh under (L3 switches), connected dominating sets and transitive properties. Once you get…

This seems to be going away from the direction that Carlos and I suggested in out note earlier this week:

	https://mailarchive.ietf.org/arch/msg/its/mLuG_SjotmHkiD5cAdU0ih5ckOM <https://mailarchive.ietf.org/arch/msg/its/mLuG_SjotmHkiD5cAdU0ih5ckOM>

If there is a technical problem with that direction, please speak about it.  Otherwise, please focus on getting the ND portion of the document ready for IETF Last Call.

Russ

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 12 Apr 2019 16:32:08 +0000

Hello Russ

Right now the document doesn’t have a scope - It only says that the application and the link layer are not in scope which could be expected without saying. This is what created a lot of confusion. An external reviewer cannot guess that there was an agreement on the ML to empty the doc from the substance that the title leads to expect.

The first step is probably for the authors to produce text giving that scope and then we can focus the review on exactly that. And adjust the title accordingly.

I understand from Sri that ND should not be in scope at all. Again there needs to be text in the scope for that. The current text still a section on subnets that leads to expect an ND discussion and more than 2 nodes. The latest discussion has clarified that if we stick to classical ND then only P2P subnets can be ensured (think like for ISDN) and even this requires an external method for DAD. This restriction should be included in the scope. It is acceptable to reduce the scope but it is not acceptable to oversell ND for things it cannot do and was never supposed to do.

Whether global addresses and internet connectivity is in scope should also be detailed.

On the side: Pretty much all the radios we deal with support at least hub and spoke. I thought it was of interest to build at least that.

Initially and in the absence of Layer-3 support hub and spoke was permitted by an emulation at Layer-2 in a WiFi BSS. For all the others radios (e.g. Bluetooth or 15.4) and since the Layer-3 support now exists it is done using WiND. My knee jerk reaction when I reviewed the doc was to wonder why be so back level on OCB. But then if the use cases are only link local P2P then we can live without it.

I’ll try to write a draft or a paper on the different WLAN/WPAN subnet models and the applicability of rfc 8505 to build them but I cannot commit when.

Regards,

Pascal

Le 12 avr. 2019 à 17:47, Russ Housley <[email-masked]<mailto:[email-masked]>> a écrit :

Pascal and Alex:

https://mailarchive.ietf.org/arch/msg/its/mLuG_SjotmHkiD5cAdU0ih5ckOM

Russ

---

From: 神明達哉 <[email-masked]>
Date: Fri, 12 Apr 2019 11:36:52 -0700

>    The fe80::/10 word was removed.

So I've just checked draft-ietf-ipwave-ipv6-over-80211ocb-38.  It now
reads:

   A subnet is formed by the external 802.11-OCB interfaces of vehicles
   that are in close range (not by their in-vehicle interfaces).  This
   subnet MUST use at least the link-local prefix and the interfaces
   MUST be assigned IPv6 address(es) of type link-local.

Given that the use of non-0 values in the intermediate 54 bits of
link-local addresses is now out of scope of this specification, I
don't see the purpose of the second sentence.

"the interfaces MUST be assigned IPv6 address(es) of type link-local"
is redundant, since it's already a part of the very basic
specification of IPv6 addressing architecture (second paragraph of
RFC4291 Section 2.1).  According to a previous conversation, perhaps
it tries to re-emphasize the already-existing requirement?  In that
case, I think it better belongs to Section 4.3, since the requirement
of having a link-local address is not a requirement on a subnet, but
on an interface.  I'd suggest revising the first paragraph of Section
4.3 as follows:

   There are several types of IPv6 addresses [RFC4291], [RFC4193], that
   MAY be assigned to an 802.11-OCB interface.  Among these types of
   addresses, the interface MUST at least have one link-local IPv6
   unicast address as specified in [RFC4291].  Only those link-local
   addresses MAY be formed using an EUI-64 identifier, in particular
   during transition time.

And, beyond this obvious requirement, it's not clear to me what this
means: "This subnet MUST use at least the link-local prefix".  Perhaps
it also tries to say this must be a single-link subnet (so all nodes
in the subnet can communicate each either directly using their
link-local addresses)?  If so, it's better to say so explicitly, e.g:

   A subnet is formed by the external 802.11-OCB interfaces of vehicles
   that are in close range (not by their in-vehicle interfaces).  This
   MUST be a single-like subnet.  It means that all nodes in the
   subnet must be able to communicate directly using their link-local
   unicast addresses.

If there's no such special intention, I'd suggest just removing the
second sentence (with moving the requirement of having a LL address to
Section 4.3).

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 13 Apr 2019 08:17:33 +1200

> forwards IP packets between these interfaces.  It has a routing table.

So you mean that every car is a router? Sure, that can work. But this
wasn't clear from Section 3 of the draft or the discussion here.
So do you plan to use RPL? And some method of dynamic prefix assignment?
I realise that these questions are out of scope for the present draft,
but they are important context that could be mentioned in Section 3.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 13 Apr 2019 08:28:33 +1200

> If you go back and check 2017 archives, I did raise many of these issues.  But, we clearly decided to limit the scope excluding address configuration, DAD, ND aspect, link models. When there is suc…

This is of course possible. In general the IETF hasn't done that, but has
followed the lead set by RFC 2464 with the complete specification of
IPv6-over-foo in one document.

However, I don't believe that publishing an RFC about the frame format
without *simultaneously* publishing an RFC about ND etc would be a good
idea. That would leave developers absolutely unable to write useful
code, and might easily lead to incompatible implementations. Since
we'd presumably like Fords to be able to communicate with Peugeots,
that seems like a bad idea.

Regards
   Brian

> From: its <[email-masked] <mailto:[email-masked]>> on behalf of Sri Gundavelli <[email-masked] <mailto:[email-masked]>>
> To: Nabil Benamar <[email-masked] <mailto:[email-masked]>>, "Pascal Thubert (pthubert)" <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, Nabil Benamar <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, Alexandre Petrescu <[email-masked] <mailto:[email-masked]>>
> From: its <[email-masked] <mailto:[email-masked]>> on behalf of Nabil Benamar <[email-masked] <mailto:[email-masked]>>
> To: "Pascal Thubert (pthubert)" <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, Nabil Benamar <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, Alexandre Petrescu <[email-masked] <mailto:[email-masked]>>
> On Mon, Apr 8, 2019, 14:01 Pascal Thubert (pthubert) <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hello Nabil.____
> 
>     __ __
> 
>     You will get a number of IESG reviews as part of the submission process, one per area. This is just a beginning…____
> 
>     __ __
> 
>     Cheers,____
> 
>     __ __
> 
>     Pascal____
> 
>     __ __
> 
>     *From:* NABIL BENAMAR <[email-masked] <mailto:[email-masked]>>
>     *To:* Alexandre Petrescu <[email-masked] <mailto:[email-masked]>>
>     *Cc:* Pascal Thubert (pthubert) <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf...org>
>     *Subject:* Re: Intdir early review of draft-ietf-ipwave-ipv6-over-80211ocb-34____
> 
>     __ __
> 
>     There have been many reviews until now. This should be a late or final review.____
> 
>     __ __
> 
>     On Mon, Apr 8, 2019, 10:01 Alexandre Petrescu <[email-masked] <mailto:[email-masked]>> wrote:____
> 
>         There have been several reviews of this document until here, and two shepherd reviews.____
> 
>         Alex____
> 
>             see https://datatracker.ietf.org/group/intdir/about/____
> 
>             __ __
> 
>             Majors issues____
> 
>             -----------------____
> 
>             __ __
> 
>             “____
> 
>             __ __
> 
>                Stateless Address Autoconfiguration is given in [RFC7217]....____
> 
>             __ __
>

---

From: Abdussalam Baryun <[email-masked]>
Date: Sun, 14 Apr 2019 00:09:10 +0200

On Fri, Apr 12, 2019 at 10:28 PM Brian E Carpenter <
[email-masked]> wrote:

> statement, it should clearly move these comments to the draft that defines
> how ND works for 802.11-OCB links.
>

yes this draft-38 is similar to rfc2464.

> idea.

that was done and was good idea by IETF in publishing (RFC2460,
RFC2461,RFC2373),  and (RFC3513, RFC4861,RFC8200), which they are separate
of same IPv6 communication. IMHO it is not good idea to separate IPv6
related protocols because it gets complicated if in one, and it has
different scenarios and use cases. Similarly in ITS if using that IPv6 over
OCB it is good to separate if possible.

> That would leave developers absolutely unable to write useful
> code, and might easily lead to incompatible implementations.

There are many SDOs that are standardizing for ITS so we need
to specify work, otherwise the developer will not wait for us but will do
useful work without us.

AB

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Sat, 13 Apr 2019 23:06:33 +0000

I understand your point Brian, but IMO there are enough reasons not to
delay this work.

There are many use-cases/applications where there is a stable topology of
RSU¹s and OBU¹s. The regulations around 5.9 Ghz (DSRC) band allows the
channel use for non-priority/non-traffic safety related applications. For
example, a vehicle in a gas station can receive a coupon from the
802.11-OCB radio (AP/RSU) in the gas station. There, its a stable topology
that classic ND is designed for. In this operating mode, its perfectly
reasonable to use classic ND and it works. The authors have shown enough
lab data on the same.

Ideally, I agree with you that it makes lot more sense to publish both the
specs at the same time. But, for what ever reasons the WG went on this
path. Authors have spent incredible amount of efforts in getting the draft
this far and we cannot ignore that. You can see the efforts from the
version number; when did we last see a draft version -037?

We also need to distill the recent ND discussions and filter out the
threads that are clearly motivated to insert a ND protocol that is
designed for a totally different operating environment. An argument that a
protocol designed for low-power environments is the solution for vehicular
environments requires some serious vetting. Looking at the
characteristics, always-sleeping, occasional internet connectivity,
low-power, no memory, no processing power, no mobility ..etc, meeting
vehicular requirements is some thing most people in the WG do not get it.

Bottom line, IMO, we should move this forward and publish the document.
All we need is a simple statement in the spec which puts some scope
limits, w.r.t the missing ND pieces and issues. There are other proposals
in the WG that will address the gaps and bring closure to the work.

Sri

---

From: Abdussalam Baryun <[email-masked]>
Date: Sun, 14 Apr 2019 01:06:45 +0200

On Fri, Apr 12, 2019 at 6:32 PM Pascal Thubert (pthubert) <
[email-masked]> wrote:

> Hello Russ
>
> Right now the document doesn’t have a scope - It only says that the
> application and the link layer are not in scope which could be expected
> without saying.
>

not true. However, I agree with Russ, we need to follow the WG chair so we
can progress our work.

> This is what created a lot of confusion. An external reviewer cannot guess
> that there was an agreement on the ML to empty the doc from the substance
> that the title leads to expect.
>

IMHO, the title is clear, and understood, but you can suggest and we
discuss.

>
> The first step is probably for the authors to produce text giving that
> scope and then we can focus the review on exactly that. And adjust the
> title accordingly.
>

I hope you can work with us of the scope and suggestions.
I can suggest that we add text of IEEE1609,

IPv6 has provisions for neighbor discovery in which a Neighbor Cache is
populated with IP addresses

 and

associated MAC addresses of devices within communications range. This is
accomplished via a multicast

response mechanism, as specified in RFC 2461, and generates a substantial
amount of traffic on the

 channel. In some WAVE systems, it may be desirable to keep traffic on the
channel to a minimum,

 suggesting that the Neighbor Cache be populated via alternate methods such
as passive monitoring of over

the-air transmissions. Note that neighbor discovery per IETF RFC 2461 is
not precluded by the IEEE 1609

standards.

>
> I understand from Sri that ND should not be in scope at all.
>

I understand from Sri that ND is not precluded (as mentioned in IEEE1609)
but in WG other drafts we are considering developing for IPWAVE.

> Again there needs to be text in the scope for that. The current text
> still a section on subnets that leads to expect an ND discussion and more
> than 2 nodes.
>

ok can be modified,

> The latest discussion has clarified that if we stick to classical ND then
> only P2P subnets can be ensured (think like for ISDN) and even this
> requires an external method for DAD.
>

Not absolutely. In IPWAVE environment or in ITS it is not important
Neighbour  Discovery but the importance is Service Discovery, so the
application can change transmission power and can control the transmission
range and data rate. The WSMP is important in the RSU node and OBU node to
make the communication. The WAVE protocol send short WSA and WRA messages.

This restriction should be included in the scope. It is acceptable to
> reduce the scope but it is not acceptable to oversell ND for things it
> cannot do and was never supposed to do.
>

We can do without, but as mentioned by IEEE we can agree for now,
that  IETF RFC 2461 is not precluded by the IEEE 1609

> Whether global addresses and internet connectivity is in scope should also

In IPWAVE environment both are in scope, why not in scope? Each service
provider has global address which is in WAVE unique ID. We don't forget
that any application-service can be IP based or non-IP based so the WAVE
advertises the address of the protocol identifier for such
application-service. We also don't forget that we may have other SDOs that
have different protocol/advertising technique for OCB links.

>
> On the side: Pretty much all the radios we deal with support at least hub
> and spoke. I thought it was of interest to build at least that.
>
> Initially and in the absence of Layer-3 support hub and spoke was
> permitted by an emulation at Layer-2 in a WiFi BSS. For all the others
> radios (e.g. Bluetooth or 15.4) and since the Layer-3 support now exists it
> is done using WiND. My knee jerk reaction when I reviewed the doc was to
> wonder why be so back level on OCB. But then if the use cases are only link
> local P2P then we can live without it.
>

It is not P2P without disconnection, usually when said P2P is means fixed
PHY layer not disconnected/dynamic-phy-link. The IPWAVE environment a high
speed Car-OBU is looking for services of short durations and it can get it
from many RSU sites because the transmission range is large and the Link
has many channels.

> I’ll try to write a draft or a paper on the different WLAN/WPAN subnet
> models and the applicability of rfc 8505 to build them but I cannot commit
> when.
>

That is for fixed networks and usually for building applications and
usually for Short Range of about less than 300 meters suitable for indoor
applications. This WG is doing Range of about 1 Km,  road traffic
safety and transportation applications.

AB

---

From: NABIL BENAMAR <[email-masked]>
Date: Sun, 14 Apr 2019 02:58:50 +0100

+1 Sri

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 14 Apr 2019 14:20:10 +1200

>> limits, w.r.t the missing ND pieces and issues. 

Yes, that is clearly essential, as well as an associated health
warning that implementers must not rush ahead because of the risk
of non-interoperability. 

Regards
   Brian

On 14-Apr-19 13:58, NABIL BENAMAR wrote:
> +1 Sri
> 
> On Sun, Apr 14, 2019, 00:06 Sri Gundavelli (sgundave) <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     On 4/12/19, 1:28 PM, "Brian E Carpenter" <[email-masked] <mailto:[email-masked]>>
>     wrote:
>

---

From: Nabil Benamar <[email-masked]>
Date: Sun, 14 Apr 2019 10:50:50 +0100

I agree with this view. ..so can we solve the ND issue this way and move
the draft forward?

Best regards
Nabil

On Sun, Apr 14, 2019, 03:20 Brian E Carpenter <[email-masked]>
wrote:

> > On Sun, Apr 14, 2019, 00:06 Sri Gundavelli (sgundave) <
> [email-masked] <mailto:[email-masked]>> wrote:
> >
> >     On 4/12/19, 1:28 PM, "Brian E Carpenter" <
> [email-masked] <mailto:[email-masked]>>
> >     wrote:
> >

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 14 Apr 2019 10:50:19 -0400

I presume I am misreading this exchange.
Brian seems to have suggested publishing the I-D under discussion as an 
RFC, with a warning that implementors should not start implementing 
because we have not figured out other critical bits that will affect the 
implementation.

Is that really a useful thing to do?  Why?

If what you want to do is put in a normative reference to the missing 
bits, put it through the IESG process, and then have it wait at the RFC 
Editor until the working group finishes the missing bits and the IETF 
approves them, I would have to ask again, why?

Yours,
Joel

On 4/14/19 5:50 AM, Nabil Benamar wrote:
> On Sun, Apr 14, 2019, 03:20 Brian E Carpenter 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>      > On Sun, Apr 14, 2019, 00:06 Sri Gundavelli (sgundave)
>     <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >
>      >     RSU¹s and OBU¹s. The regulations around 5..9 Ghz (DSRC) band
>     allows the
>      >     On 4/12/19, 1:28 PM, "Brian E Carpenter"
>     <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked]
>     <mailto:[email-masked]>>>
>      >     wrote:
>      >
>      >     >On 13-Apr-19 02:59, Sri Gundavelli (sgundave) wrote:
>      >     >>If you go back and check 2017 archives, I did raise many of
>     these
>      >     >>issues.  But, we clearly decided to limit the scope
>     excluding address
>      >     >>configuration, DAD, ND aspect, link models. When there is
>     such a scope
>      >     >>statement, it should clearly move these comments to the
>     draft that
>      >     >>defines how ND works for 802.11-OCB links.
>      >     >
>      >     >This is of course possible. In general the IETF hasn't done
>     that, but has
>      >     >followed the lead set by RFC 2464 with the complete
>     specification of
>      >     >IPv6-over-foo in one document.
>      >     >
>      >     >However, I don't believe that publishing an RFC about the
>     frame format
>      >     >without *simultaneously* publishing an RFC about ND etc
>     would be a good
>      >     >idea. That would leave developers absolutely unable to write
>     useful
>      >     >code, and might easily lead to incompatible implementations.
>     Since
>      >     >we'd presumably like Fords to be able to communicate with
>     Peugeots,
>      >     >that seems like a bad idea.
>      >     >
>      >     >Regards
>      >     >   Brian
>      >
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 14 Apr 2019 18:31:37 +0200

I agree with you Sri.

It can make sense to write a separate ND spec for more variable 
environments, but not to delay the existing IP-over-OCB work.

ND in a gas station, ND between vehicles moving together, ND with car 
parked on parking, are just a fex examples where ND works fine on OCB.

Remark also that ND is not the only protocol on top of IP.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 14 Apr 2019 18:38:00 +0200

Brian,

> warning that implementers must not rush ahead because of the risk

There is already paragraph, and an Appendix, about potential ND issues. 
I think that text qualifies as an associated health warning.

I do not know what do you mean about the risk of interoperability.  This 
ND that works is interoperable between several OCB cards, IP Road Side 
Units, and linuces. (I can cite brands that I al familiar with and that 
interoperate.

This is the current paragraph and Appendix that qualify as a warning 
that you suggest:

>    The baseline Neighbor Discovery protocol (ND) [RFC4861] MUST be used
>    over 802.11-OCB links.  Transmitting ND packets may prove to have
>    some performance issues.  These issues may be exacerbated in OCB
>    mode.  Solutions for these problems SHOULD consider the OCB mode of
>    operation.  The best of current knowledge indicates the kinds of
>    issues that may arise with ND in OCB mode; they are described in
>    Appendix J.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 14 Apr 2019 18:42:41 +0200

Brian,

Le 12/04/2019 à 22:28, Brian E Carpenter a écrit :
>> issues.  But, we clearly decided to limit the scope excluding 
>> address configuration, DAD, ND aspect, link models. When there is 
>> such a scope statement, it should clearly move these comments to 
>> the draft that defines how ND works for 802.11-OCB links.
> 
> This is of course possible. In general the IETF hasn't done that,
> but has followed the lead set by RFC 2464 with the complete
> specification of IPv6-over-foo in one document.
> 
> However, I don't believe that publishing an RFC about the frame 
> format without *simultaneously* publishing an RFC about ND etc would 
> be a good idea.

Brian - it took us several years to arrive at this IP-over-OCB spec.  I
suspect an ND-over-OCB would take even longer, as it seems more complex
in particular mobility contexts; mobility contexts are hard tot try.
What happens with the IP-over-OCB spec during these additional years?  A
draft expires after 6 months.  Would one update the IP-over-OCB draft
update it every 6 months with just artificial ' ' in it just to keep it
alive?  It does not seem feasible.

> That would leave developers absolutely unable to write useful code,
> and might easily lead to incompatible implementations. Since we'd
> presumably like Fords to be able to communicate with Peugeots, that
> seems like a bad idea.

Fords talking to Peugeots in a convoy can work fine today, without 
additional ND work.  ND works fine on PHYs and MACs that are set up 
properly.

Alex

>> behalf of Sri Gundavelli <[email-masked] 
>> <mailto:[email-masked]>> Date: Friday, April 12, 2019 at 7:38 
>> AM To: Nabil Benamar <[email-masked] 
>> <mailto:[email-masked]>>, "Pascal Thubert (pthubert)" 
>> <[email-masked] <mailto:[email-masked]>> Cc:
>> "[email-masked] <mailto:[email-masked]>" <[email-masked]
>> <mailto:[email-masked]>> Subject: Re: [ipwave]
>> Intdir early review of draft-ietf-ipwave-ipv6-over-80211ocb-34
>> 
>> <mailto:[email-masked]>> Date: Friday, April 12, 2019 at 7:34 
>> AM To: "Pascal Thubert (pthubert)" <[email-masked] 
>> <mailto:[email-masked]>> Cc: "[email-masked] 
>> <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, 
>> "[email-masked] <mailto:[email-masked]>" <[email-masked] 
>> <mailto:[email-masked]>>, "[email-masked] 
>> <mailto:[email-masked]>> Subject: Re: [ipwave]
>> Intdir early review of draft-ietf-ipwave-ipv6-over-80211ocb-34
>> 
>> Hello Pascal,
>> 
>> Best regards Nabil
>> <mailto:[email-masked]>> *Sent:* lundi 8 avril 2019 17:53
>> <mailto:[email-masked]>> *Cc:* Pascal Thubert 
>> [email-masked] <mailto:[email-masked]>; [email-masked] 
>> <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; 
>> <mailto:draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf...org> 
>> Who defines____
>> not bring____

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 14 Apr 2019 18:59:09 +0200

Le 12/04/2019 à 20:36, 神明達哉 a écrit :
> On Thu, Apr 11, 2019 at 6:59 AM Alexandre Petrescu 
> don't see the purpose of the second sentence. >
> RFC4291 Section 2.1).

True, RFC4291 sec. 2.1 says that all interfaces must have at least one 
link-local address.  But (1) it does not use CAPITALS to require 
something and (2) it does not require the link-local prefix to be on the 
interface.

One can assign just an address to an interface, without specifying the 
prefix.  In that case, a plen is assumed to be 128.  If one assigns 
fe80::1 (dont specify plen) on one computer, but assigns fe80::2/64 
(specify the plen) on another computer, then there are risks of 
interoperability.  In some cases, because of that lack of specifying the 
prefix, it wont ping.

Dont you think we should require that the link-local prefix must be 
assigned to each interface? (in addition to requiring the ll address).

> According to a previous conversation, perhaps
> it tries to re-emphasize the already-existing requirement?

Yes - continue to require LL addresses like 4291 does, but also the LL 
prefix, which 4291 does not do.

> In that
> on an interface.

It is a requirement to put a prefix (also known as a subnet) .

>  I'd suggest revising the first paragraph of Section
> 4.3 as follows:
> 

Thanks for the suggestion.  But it does not say 'link-local prefix'.

>     MUST be a single-like subnet.  It means that all nodes in the

single-link?

>     subnet must be able to communicate directly using their link-local

Sounds reasonable.  Multi-link subnets were not assumed here, and when 
not assuming them I suspect the subnets are exclusively single-link.

I never heard the term single-link subnet?

I could put the text as you suggest, but I am afraid to write about 
single-link subnets: they are all like that, I think.

(multilink subnets: I have never seen them in vehicular networks).

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 14 Apr 2019 19:20:06 +0200

for this particular detail,

>  If so, it's better to say so explicitly, e.g:
> 

I added the last phrase (all nodes in the subnet must be able to 
communicate directly using their lls).

Remark that, for me, that is a phrase with some risks of ambiguity. 
'Communicate directly' may mean to you that it does not go through IP 
Router, but to others may mean it does not go through Access Point. 
This 'communicate directly' means many things to many people.

For best use, at this time I think this 'communicate directly' should be 
qualified by the layer (i.e. at network layer).

Also, 'using their link local unicast addresses' can mean to some that 
there exist link local multicast addresses (they dont, as proven by a 
search of "link-local multicast address" in RFC4291; at most maybe some 
groups with ll scope exist); also it does not say where these ll 
addresses sit: if they are in the src and dst fields then you are right, 
but if they are in some inner header, encapsulated, then it's ambiguous.

Alex

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 15 Apr 2019 08:24:05 +1200

On 15-Apr-19 04:59, Alexandre Petrescu wrote:
> something

It does not use RFC 2119 keywords at all, so "must" means "must".
In fact, RFC 2119 "MUST" means "must"; there is really no semantic
distinction.

RFC 8174 does not affect this statement.

    Brian

> and (2) it does not require the link-local prefix to be on the 
> interface.
>

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 15 Apr 2019 08:30:02 +1200

> because we have not figured out other critical bits that will affect the 

I'm no expert, but my understanding at the moment is that ND will work
in some OCB deployment scenarios and not in others. So I'm suggesting
that the draft should clearly state in which scenarios it will work,
and recommend avoiding other scenarios until an alternative is
standardized.
 
> approves them, I would have to ask again, why?

Well, that's exactly what the "MISSREF" status of pending RFCs does,
but I don't think that needs to be the case here if the draft is carefully
scoped as above.

Regards
    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 15 Apr 2019 08:49:03 +1200

Hi Alexandre,

>>    issues that may arise with ND in OCB mode; they are described in

That's exactly the text that I find problematic. I can't write a new
version because I lack your expert knowledge, but IMHO it should be
more specific:

    The baseline Neighbor Discovery protocol (ND) [RFC4861] MUST be used
    over 802.11-OCB links.  However, as on any wireless link, transmission
    of multicast ND packets may fail in OCB. In particular, scenarios
    where TBD TBD TBD are likely to be unreliable and SHOULD NOT be
    deployed until an alternative standardised solution is available. 
    The best of current knowledge indicates the kinds of issues that
    may arise with ND in OCB mode; they are described in Appendix J.

Also I don't like this phrasing in Appendix J:

   Early experiences indicate that it should be possible to exchange
   IPv6 packets over OCB while relying on IPv6 ND alone for DAD and AR
   (Address Resolution).

Could you rather say the opposite:

   Early experience indicates that it is possible to exchange
   IPv6 packets over OCB while relying on IPv6 ND alone for DAD and AR
   (Address Resolution) in good conditions. However, this does not
   apply if TBD TBD TBD...

Regards
    Brian

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 15 Apr 2019 06:53:37 +0000

This text is wrong, Alexandre.

There is a distinction between performance issue and does not work. You can not MUST a protocol that by design will only work in a subset of the possible situations. 

What you can do is document in which situations it can be made to work (P2P and full overlap of the broadcast domains) and explain the drawbacks (eg if broadcast is sent at higher power or slower phy then it impacts unicast communications). 

Then you want to open the door to using more suitable techniques in future documents, which the MUST seems to discourage.

Regards,

Pascal

> Le 14 avr. 2019 à 18:38, Alexandre Petrescu <[email-masked]> a écrit :
> 
> Brian,
> 
> There is already paragraph, and an Appendix, about potential ND issues. I think that text qualifies as an associated health warning.
> 
> I do not know what do you mean about the risk of interoperability.  This ND that works is interoperable between several OCB cards, IP Road Side Units, and linuces. (I can cite brands that I al familiar with and that interoperate.
> 
> This is the current paragraph and Appendix that qualify as a warning that you suggest:
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 15 Apr 2019 09:35:26 +0200

Pascal - do you know of a OCB use and some scenario where ND does not work?

(I mean some trials that you may have done with OCB; if you never played 
with OCB and wiht IP on it, I think it makes no sense to describe 
speculations of it).

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 15 Apr 2019 09:42:53 +0200

Tatuya,

That RFC4291 section 2.1 says:
>    All interfaces are required to have at least one Link-Local unicast
>    address (see Section 2.8 for additional required addresses).

Sidenote: I think the loopback interface does not have a link-local 
address.  Probably it is not all interfaces that must have at least one ll(
Alex

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 15 Apr 2019 08:04:21 +0000

Hello Alexandre.

I hoped I was clear before. 

Take 4 cars, A, B, C, D separated by 100 meters each, such that all can hear C, though A has a bad quality, and A and D are too far apart. C advertises a prefix in RA(PIO), all can hear it. 

- Try pinging A from D using the address based on that prefix, won't ping. 
- Try configuring A's address on D it will be accepted, which means that DAD will not work either. 

This is nothing new, common to all the short/middle range radios we have looked at. You may try the same placing C at the corner of a street, A and D in orthogonal streets.
This has nothing to do with low power and everything to do with radio propagation.
The exception is Wi-Fi, and that's because the BSS emulates the broadcast domain, as I think I explained already.
RFC 8505 recreates the Wi-Fi design but at L3... and the use cases above were made to work on other radios with similar properties. More in the 6TiSCH architecture I guess...

Sorry you consumed all the time I could dedicate, and more.

All the best,

Pascal

> Sent: lundi 15 avril 2019 15:35
> Cc: Brian E Carpenter <[email-masked]>; NABIL BENAMAR
> <[email-masked]>; Sri Gundavelli (sgundave)
> <[email-masked]>; nabil benamar <[email-masked]>;
> [email-masked]; [email-masked]; [email-masked]; draft-ietf-ipwave-ipv6-over-
> [email-masked]
> Subject: Re: draft-ietf-ipwave-ipv6-over-80211ocb-38
> 
> (I mean some trials that you may have done with OCB; if you never played with
> OCB and wiht IP on it, I think it makes no sense to describe speculations of it).
> 
> Alex
> 
> > There is a distinction between performance issue and does not work. You
> can not MUST a protocol that by design will only work in a subset of the
> possible situations.
> >
> > What you can do is document in which situations it can be made to work
> (P2P and full overlap of the broadcast domains) and explain the drawbacks (eg
> if broadcast is sent at higher power or slower phy then it impacts unicast
> communications).
> >
> > Then you want to open the door to using more suitable techniques in future
> documents, which the MUST seems to discourage.
> >
> >
> > Regards,
> >
> > Pascal
> >
> >>>>> All we need is a simple statement in the spec which puts some
> >>>>> scope limits, w.r.t the missing ND pieces and issues.
> >>> warning that implementers must not rush ahead because of the risk of
> >>> non-interoperability.
> >>
> >> There is already paragraph, and an Appendix, about potential ND issues. I
> think that text qualifies as an associated health warning.
> >>
> >> I do not know what do you mean about the risk of interoperability.  This ND
> that works is interoperable between several OCB cards, IP Road Side Units, and
> linuces. (I can cite brands that I al familiar with and that interoperate.
> >>
> format

---

From: Jong-Hyouk Lee <[email-masked]>
Date: Mon, 15 Apr 2019 17:16:04 +0900

Agree.
--
Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random
Protocol Engineering Lab., Sangmyung University

#email: [email-masked]
#webpage: https://sites.google.com/site/hurryon

> 2019. 4. 12. 오후 11:59, Sri Gundavelli (sgundave) <[email-masked]> 작성:
> 
> https://mailarchive.ietf.org/arch/msg/its/9NvUfRigGd4Klu0Q2Ee-63ziATw <https://mailarchive.ietf.org/arch/msg/its/9NvUfRigGd4Klu0Q2Ee-63ziATw>
> 
> https://mailarchive.ietf.org/arch/msg/its/VcrwNSvNJVIZNcRLNjDY0iSw3CA <https://mailarchive.ietf.org/arch/msg/its/VcrwNSvNJVIZNcRLNjDY0iSw3CA>
> 
> Sri
> 
> 
> 
> 
>> From: NABIL BENAMAR <[email-masked] <mailto:[email-masked]>> 
>> Cc: Pascal Thubert (pthubert) <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf..org>
>> On Mon, Apr 8, 2019, 10:01 Alexandre Petrescu <[email-masked] <mailto:[email-masked]>> wrote:
>>>> see https://datatracker.ietf.org/group/intdir/about/ <https://datatracker.ietf.org/group/intdir/about/>
>>>>  
>>>> Majors issues
>>>> -----------------
>>>>  
>>>> “
>>>>  
>>>>    https://tools.ietf.org/html/bcp14 <https://tools.ietf.org/html/bcp14> https://tools.ietf.org/html/bcp14 <https://tools.ietf.org/html/bcp14>
>>>>    [https://tools.ietf.org/html/rfc2119 <https://tools.ietf.org/html/rfc2119>][RFC8174] when, and only when, they
>> https://www.ietf.org/mailman/listinfo/its <https://www.ietf.org/mailman/listinfo/its>

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 15 Apr 2019 10:41:07 +0200

Le 15/04/2019 à 10:04, Pascal Thubert (pthubert) a écrit :
> Take 4 cars,

HAve you taken them?  Or is it pencil and paper?

DEpending on that I will read further.

Alex

  A, B, C, D separated by 100 meters each, such that all can hear C, 
though A has a bad quality, and A and D are too far apart. C advertises 
a prefix in RA(PIO), all can hear it.

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 15 Apr 2019 10:43:35 +0200

> This is nothing new, common to all the short/middle range radios we have looked at.

Have you looked at OCB?

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 15 Apr 2019 10:50:28 +0200

Le 15/04/2019 à 10:04, Pascal Thubert (pthubert) a écrit :
> Take 4 cars, A, B, C, D separated by 100 meters each,

DO you know that in OCB the allowed power levels are much higher than in 
WiFi?  This has impact on your assumption that at 100m spacing between 
pairs of cars is still ok with 4 cars: they all hear each other ok.

In OCB one can go as far as 800m between two cars in open outdoors, 
safely.  We did.

In some countries one can go even further.  I would love to try this in 
America where power levels can go up to 40dbm (i.e. maybe 2km).

So, if you try to make 4 cars in America to follow your pencil and paper 
test you need maybe 8km distance.  You need a few drivers to work for 
you and as many programmers.  You also need walkie-talkies.  Can you get 
that?

Alex

  such that all
> can hear C, though A has a bad quality, and A and D are too far
> apart. C advertises a prefix in RA(PIO), all can hear it.
> 
> - Try pinging A from D using the address based on that prefix, won't
> ping. - Try configuring A's address on D it will be accepted, which
> means that DAD will not work either.
> 
> This is nothing new, common to all the short/middle range radios we
> have looked at. You may try the same placing C at the corner of a
> street, A and D in orthogonal streets. This has nothing to do with
> low power and everything to do with radio propagation. The exception
> is Wi-Fi, and that's because the BSS emulates the broadcast domain,
> as I think I explained already. RFC 8505 recreates the Wi-Fi design
> but at L3... and the use cases above were made to work on other
> radios with similar properties. More in the 6TiSCH architecture I
> guess...
> 
>> -----Original Message----- From: Alexandre Petrescu
>> <[email-masked]> Sent: lundi 15 avril 2019 15:35 To:
>> Pascal Thubert (pthubert) <[email-masked]> Cc: Brian E
>> Carpenter <[email-masked]>; NABIL BENAMAR 
>> [email-masked]; [email-masked]; [email-masked];
>> draft-ietf-ipwave-ipv6-over- [email-masked] Subject: Re:
>> draft-ietf-ipwave-ipv6-over-80211ocb-38
>> 
>> (I mean some trials that you may have done with OCB; if you never
>> played with OCB and wiht IP on it, I think it makes no sense to
>> describe speculations of it).
>> 
>> Alex
>> 
>> can not MUST a protocol that by design will only work in a subset
>> of the possible situations.
>>> 
>> (P2P and full overlap of the broadcast domains) and explain the
>> drawbacks (eg if broadcast is sent at higher power or slower phy
>> then it impacts unicast communications).
>>> 
>>>>>>> All we need is a simple statement in the spec which puts
>>>>>>> some scope limits, w.r.t the missing ND pieces and
>>>>>>> issues.
>>>>> Yes, that is clearly essential, as well as an associated
>>>>> health warning that implementers must not rush ahead because
>>>>> of the risk of non-interoperability.
>>>> 
>> that works is interoperable between several OCB cards, IP Road Side
>> Units, and linuces. (I can cite brands that I al familiar with and
>> that interoperate.
>>>> 
>>>> This is the current paragraph and Appendix that qualify as a
>>>> warning that
>> you suggest:
>>>> 
>>>>> The baseline Neighbor Discovery protocol (ND) [RFC4861] MUST
>>>>> be used over 802.11-OCB links.  Transmitting ND packets may
>>>>> prove to have some performance issues.  These issues may be
>>>>> exacerbated in OCB mode.  Solutions for these problems SHOULD
>>>>> consider the OCB mode of operation.  The best of current
>>>>> knowledge indicates the kinds of issues that may arise with
>>>>> ND in OCB mode; they are described in Appendix J.
>>>> 
>>>> 
>>>> Alex
>>>> 
>>>>> Regards Brian
>>>>>> On 14-Apr-19 13:58, NABIL BENAMAR wrote: +1 Sri
>>>>>> 
>>>>>> I understand your point Brian, but IMO there are enough
>>>>>> reasons not
>> to
>>>>>> delay this work.
>>>>>> 
>>>>>> There are many use-cases/applications where there is a
>>>>>> stable
>> topology of
>>>>>> RSU¹s and OBU¹s. The regulations around 5.9 Ghz (DSRC) band
>>>>>> allows
>> the
>>>>>> channel use for non-priority/non-traffic safety related
>>>>>> applications.
>> For
>>>>>> example, a vehicle in a gas station can receive a coupon
>>>>>> from the 802.11-OCB radio (AP/RSU) in the gas station.
>>>>>> There, its a stable
>> topology
>>>>>> that classic ND is designed for. In this operating mode,
>>>>>> its perfectly reasonable to use classic ND and it works.
>>>>>> The authors have shown
>> enough
>>>>>> lab data on the same.
>>>>>> 
>>>>>> Ideally, I agree with you that it makes lot more sense to
>>>>>> publish both
>> the
>>>>>> specs at the same time. But, for what ever reasons the WG
>>>>>> went on
>> this
>>>>>> path. Authors have spent incredible amount of efforts in
>>>>>> getting the
>> draft
>>>>>> this far and we cannot ignore that. You can see the efforts
>>>>>> from the version number; when did we last see a draft
>>>>>> version -037?
>>>>>> 
>>>>>> We also need to distill the recent ND discussions and
>>>>>> filter out the threads that are clearly motivated to insert
>>>>>> a ND protocol that is designed for a totally different
>>>>>> operating environment. An argument
>> that a
>>>>>> protocol designed for low-power environments is the
>>>>>> solution for
>> vehicular
>>>>>> characteristics, always-sleeping, occasional internet
>>>>>> connectivity, low-power, no memory, no processing power, no
>>>>>> mobility ..etc,
>> meeting
>>>>>> vehicular requirements is some thing most people in the WG
>>>>>> do not
>> get it.
>>>>>> 
>>>>>> Bottom line, IMO, we should move this forward and publish
>>>>>> the
>> document.
>>>>>> All we need is a simple statement in the spec which puts
>>>>>> some scope limits, w.r.t the missing ND pieces and issues.
>>>>>> There are other
>> proposals
>>>>>>>> If you go back and check 2017 archives, I did raise
>>>>>>>> many of these issues.  But, we clearly decided to limit
>>>>>>>> the scope excluding address configuration, DAD, ND
>>>>>>>> aspect, link models. When there is such a
>> scope
>>>>>>>> statement, it should clearly move these comments to the
>>>>>>>> draft that defines how ND works for 802.11-OCB links.
>>>>>>> 
>>>>>>> This is of course possible. In general the IETF hasn't
>>>>>>> done that, but
>> has
>>>>>>> followed the lead set by RFC 2464 with the complete
>>>>>>> without *simultaneously* publishing an RFC about ND etc
>>>>>>> would be a
>> good
>>>>>>> idea. That would leave developers absolutely unable to
>>>>>>> write useful code, and might easily lead to incompatible
>>>>>>> implementations. Since we'd presumably like Fords to be
>>>>>>> able to communicate with
>> Peugeots,

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 15 Apr 2019 13:22:07 +0200

> In fact, RFC 2119 "MUST" means "must"; there is really no semantic

So, if RFC4291 does not use MUST to require the use of a link-local 
address, and if the IP-over-OCB draft says that link-local addresses MAY 
be formed on OCB interfaces (as the current draft does) - we are fine.

Also it means one can not say that RFC4291 specifies enough about the 
link local addresses because it uses no RFC2119 keyword with respect to 
link local addresses.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 15 Apr 2019 13:26:30 +0200

Hi Brian,

>      may arise with ND in OCB mode; they are described in Appendix J.

I can agree with that formulation and put it in the text.

But I need an indicat that TBD is defined soon.  The time commitments of 
Pascal seem to be saying he is no longer interested in writing that TBD.

I wait a little for this to clarify.

>     (Address Resolution) in good conditions. However, this does not

This is an appendix.  I could put TBD there now.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 15 Apr 2019 13:54:37 +0200

Hi Brian,

[...]
> version because I lack your expert knowledge, but IMHO it should be

I do have expert knowledge on ND on OCB, although only at a certain 
level.  It works.

Other people may claim ND does not work on OCB, but have they tried OCB 
at all?

It is the people who claim ND does not work on OCB should write the new 
version of the 'TBD' text.

It is very simple to try ND on OCB.  I published a howto on the email 
list.  A Hackathon w/o me was tried following that howto.  A few other 
organisations that I work with tried it (w/o me).  I did not received 
feedback from them about ND not working.

What is difficult to try is to reproduce the ND-over-OCB problem 
imagined by Pascal.  It is difficult to try because it involves 4 cars 
(I dont have that many).  It  is also difficult to try because it seems 
to miss the fact that OCB can do high power.  Maybe that high power 
solves the problems that appear in ND over low power.

For my part, I cant put text about ND on OCB without having an 
implementation of that problem.

It is for that reason that I asked Pascal, or anybody else claiming ND 
does not work on OCB, to try it and write that text 'TBD'.

Alex

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 15 Apr 2019 07:16:04 -0700

Hello Alex and all,

I have a few comments, although I have only briefly scanned the OCB draft.

  * RFC 8505 isn't just about low power.  More to the point in this
    discussion, it's about reducing interference by reducing the number
    of multicasts needed in a multilink subnet.  Please note that I am
    neither discouraging nor advocating the use of RFC 8505 for
    v6-over-OCB, but I think it would be better to avoid suggesting that
    it is only useful for low-power mesh.

  * Even if you did have four cars to run experiments, the results could
    hardly be considered conclusive.  Simulation can be very helpful in
    such circumstances.  You know the velocities and the range of the
    signal. You have many many thousands of easily accessible real-world
    topologies, and even the interference characteristics.

  * I made a quick scan of the draft and found this: "All nodes in the
    subnet MUST be able to communicate directly using their link-local
    unicast addresses.".  Does this mean that the solution is not
    applicable for topologies exhibiting the hidden terminal problem? 
    Or, does "directly" mean something else?

I think the draft could benefit from a very clear applicability 
statement, specifically including the projected number of vehicles in 
the subnet.  If every vehicle on the subnet can expect deliver of 
multicast packets to every other vehicle on the subnet, then the problem 
is different than if hidden terminal effects occur or if multicast is 
unreliable for some other reason.  Maybe for clarity it would be helpful 
to include a diagram of a general target network with more than three or 
four vehicles.

You can also tell me that my opinion lacks relevance since I have not 
carefully read the draft.

Regards,
Charlie P.

On 4/15/2019 4:54 AM, Alexandre Petrescu wrote:
> Other people may claim ND does not work on OCB, but have they tried 
> OCB at all?
>
> It is the people who claim ND does not work on OCB should write the 
> new version of the 'TBD' text.
>
> (I dont have that many).  It  is also difficult to try because it 
> seems to miss the fact that OCB can do high power. Maybe that high 
> power solves the problems that appear in ND over low power.
>
>>>>> reasons not to
>>>>> stable topology of
>>>>> applications. For
>>>>> from the
>>>>> publish both the
>>>>> went on this
>>>>> getting the draft
>>>>> from the
>>>>> connectivity,
>>>>> do not get it.
>>>>> the document.
>>>>> some scope
>>>>>       >>If you go back and check 2017 archives, I did raise many 
>>>>> of these
>>>>>       >idea. That would leave developers absolutely unable to 
>>>>> write useful
>>>>>       >code, and might easily lead to incompatible 
>>>>> implementations. Since

---

From: 神明達哉 <[email-masked]>
Date: Mon, 15 Apr 2019 11:40:40 -0700

At Sun, 14 Apr 2019 18:59:09 +0200,

> something and (2) it does not require the link-local prefix to be on the

As for (1), see Brian's response.   And I'm afraid you misunderstood
his message; I interpret it as if
  "All interfaces are required to have at least one Link-Local unicast
   address"
should read
  "All interfaces are REQUIRED to have at least one Link-Local unicast
  address"
.  I also believe that's the commonly adopted interpretation when an
RFC is written without all CAPITAL keywords.  If you're in doubt about
it, I suggest you confirm it at, e.g. the 6man ML.

> assigned to each interface? (in addition to requiring the ll address).

Ah, so by stating "This subnet MUST use at least the link-local
prefix" you wanted to make sure, e.g., fe80::1 is always considered
on-link through a specified interface.  That intent originally wasn't
clear from this text to me.  To answer the question now that I
understand it: given that "what's the link-local prefix" (or whether
we should allow a non-0 value in the intermediate 54 bits) is now out
of scope of this doc, I personally don't see the need for explicitly
stating it.  But if you really want to emphasize something here, I'd
personally just refer to RFC4861:

      Prefix List  - A list of the prefixes that define a set of
                     addresses that are on-link.[...]
                     The link-local prefix is considered to be on the
                     prefix list with an infinite invalidation timer
                     regardless of whether routers are advertising a
                     prefix for it.

> I never heard the term single-link subnet?

Perhaps it's not a well-defined term.  If you're concerned about the
terminology matter you can just say it's not a multi-link subnet.

Anyway, any of these suggestions are completely informational in the
hope that they will help improve the readability of this document
without changing its. intent.  If you don't agree on or like any of
them, you can freely ignore them.

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Mon, 15 Apr 2019 12:02:19 -0700

At Mon, 15 Apr 2019 09:42:53 +0200,

> address.  Probably it is not all interfaces that must have at least one
ll(

Indeed, there's some subtle point here.  RFC4007 somewhat tries to
clarifies it:

   The IPv6 unicast loopback address, ::1, is treated as having link-
   local scope within an imaginary link to which a virtual "loopback
   interface" is attached.

that is, (with the assumption that the loopback interface is
configured with ::1) the loopback interface does not (necessarily)
have an 'fe80' address, but it still has a link-local scope address.
If and when 6man resumes the work of rfc4291bis we should probably
make this clarification.

BTW, whether a loopback interface has an fe80 address is actually
implementation dependent.  BSDs usually assign ::1 on a loopback
interface while also generating an fe80 address on it:

% ifconfig lo0
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
    options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
    inet6 ::1 prefixlen 128
    inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2

--
JINMEI, Tatuya

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 15 Apr 2019 19:48:53 +0000

Hello Jinmei:

The point on multilink subnet is that link local address that is limited to the link cannot reach all nodes in the MLSN. This illustrates that a link and a subnet are very different beasts, whereby the former is physical and the latter logical.

 The sentence that requires using a link local prefix on a subnet is therefore non sensical and denotes a confusion between the concepts. The text discussed below is about link not subnet.

Link local addresses are related to links, whereas global addresses are related to subnets. The link of a mobile node roams with the device across the subnets that the device visits. If the device needs a single permanent link local address then that address must be globally unique, e.g., derived from a burnin MAC address.

RFC 8505 departs from that model and a node may use many LLAs. The uniqueness of the LL address is only required within a pair of nodes that use it to communicate. This model simplifies the DAD issue to the extreme.

All the best,

Pascal

Le 15 avr. 2019 à 20:41, 神明達哉 <[email-masked]<mailto:[email-masked]>> a écrit :

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 16 Apr 2019 08:53:50 +1200

On 15-Apr-19 23:22, Alexandre Petrescu wrote:
> address, 

Huh? It uses English "must" which, excuse me for repetition,
means *exactly* the same as RFC2119 "MUST". There is no difference.

> and if the IP-over-OCB draft says that link-local addresses MAY 

Not quite, because it also says

"  An Interface ID SHOULD be of length
   64 decimal for all types of IPv6 addresses.  In the particular case
   of IPv6 link-local addresses, the length of the Interface ID MAY be
   118 decimal."

which conflicts with RFC4291.

> link local addresses because it uses no RFC2119 keyword with respect to 

I can't parse that sentence, because I cannot tell which clause "because"
applies to.

    Brian

---

From: 神明達哉 <[email-masked]>
Date: Mon, 15 Apr 2019 14:02:18 -0700

At Mon, 15 Apr 2019 19:48:53 +0000,
"Pascal Thubert (pthubert)" <[email-masked]> wrote:

> The point on multilink subnet is that link local address that is limited
to the link cannot reach all nodes in the MLSN. This illustrates that a
link and a subnet are very different beasts, whereby the former is physical
and the latter logical.

Yes, I understand that.

>  The sentence that requires using a link local prefix on a subnet is
therefore non sensical and denotes a confusion between the concepts. The
text discussed below is about link not subnet.

Agreed, that's exactly why I wondered whether the intent was to say
it's NOT a multi-link subnet.  But, it looks like the intent is to
just state somewhat obvious: "link-local addresses must be considered
on-link", so it's probably better not to bother discussing whether
it's a multi-link subnet or not.  And then, I agree that any
link-local discussion should belong to somewhere else than the
"subnet" section.

I personally still think Section 4.3 is the best place, and combining
all of my understanding of the intent, it might read, e.g.:

   [2nd paragraph unchanged]

   Any other link-local addresses than those assigned to the
   802.11-OCB interface MUST be considered on-link in terms of on-link
   determination as defined in [RFC4861].

(The added 3rd paragraph looks too obvious to say to me, but that's
what I might say if I have to say something about it).

Anyway, again, it's just an observer's suggestion for hopefully making
it more readable without changing the author's intent.  If it rather
introduce more confusion or controversy, please just ignore it.

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 16 Apr 2019 09:04:36 +1200

Excuse top posting. 

As I've said, I am no expert, but I do know some physics, and
it seems pretty clear to me that if there are multiple lanes 
of traffic, a large truck can easily shield signals between
two cars and the shielding will be intermittent, regardless
of how much wireless power is allowed, depending on traffic
movement. So it's a highly dynamic mesh network. That's a very
interesting problem that has been much studied, and it's
fundamentally different from the ND design scenario.

So I find it hard to believe that nobody can write the TBD
text.

Regards
   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 16 Apr 2019 14:18:34 +1200

Hi,

I have just discovered a useful discussion of the multi-link problem here:

https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking-08#section-5.1.1

The OCB draft doesn't refer to this draft, but only to its superseded
predecessor draft-ietf-ipwave-vehicular-networking-survey.

I think I will drop this discussion until ipwave gets its two
main drafts properly synchronized.

Regards
   Brian

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 16 Apr 2019 03:11:55 +0000

> I am no expert, but I do know some physics, and it seems pretty clear to
>me that if there are multiple lanes of traffic, a large truck can easily
>shield signals between two cars and the shielding will be intermittent,
>regardless of how much wireless power is allowed, depending on traffic
>movement. So it's a highly dynamic mesh network.

Part of the problem is that we have not clearly put some limits on the
use-cases. These unbounded limits is opening up these discussions on
ad-hoc full mesh network formations and the resulting challenging ND
scenarios. But, again I always assumed this discussion is for the ND
document and there should be no bearing on this document.

V2X communications involves V2V, V2I and V2P communication modes. From the
point of view of vehicular safety, its about exchange of BSM (Basic Safety
Messages) between vehicles as per SAEJ735 standard. These safety
communications is always one-hop communication and for very good reason
IEEE WAVE standards did not bother to require IPv6 transport for carrying
these messages. The WSMP message which carries these safety elements are
defined to be carried over layer-2 payloads. Personally, I never thought
we will replace this L2 safety communication mode with layer-3 mode
(IPv6-over-80211-OCB). But the use of IPv6 is more for allowing
applications in the vehicle to communicate with the infrastructure. For
example, a vehicle using DSRC radio to access some traffic application in
the cloud. 

In one sense, this is like a mobile node using 802.11-OCB like any other
radio technology (CDMA, LTE, Wi-Fi), and use IPv6 for its communications.
In this context, its always about vehicle to infrastructure
communications. Now, there are other interesting peer to peer use-cases,
where one vehicle is streaming some video to another vehicle without using
any infrastructure. While these later examples are very cool, personally,
I did not expect this WG to solve those use-cases day-1. For us to support
those use-cases, we need to figure out many more things including
approaches for exchanges prefixes between two vehicles that come in
proximity. In my mind, these are very forward looking and the only
relevant application is platooning. I am not interested in solving this
V2V problem, but was more interested to enable V2I communications, where
the focus is about link model, prefix hosting approaches, mobility support
(building a large L2 domain over RSU’s, or routed approaches with mobile
IP type protocols) ..etc. In one realization, there may be a P2P link
assumption between the vehicle and the RSU, eliminating most of these ND
issues. But, those discussions are for the other document and that clearly
should remove these ND concerns from this document.

Sri

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 16 Apr 2019 03:23:18 +0000

> RFC 8505 isn't just about low power.  More to the point in this discussion, it's about reducing interference by reducing the number of multicasts needed in a multilink subnet.  Please note that I am neither discouraging nor advocating the use of RFC 8505 for v6-over-OCB, but I think it would be better to avoid suggesting that it is only useful for low-power mesh.

Hi Charlie – Sure, but IMO multicast is not the only issue for vehicular communications. We need a protocol that is designed for vehicular environments. We don’t really need to force-fit some protocol which did not factor a single vehicular property in its design, just because it exists. We need to figure out many more things (RSU network topology, links models, prefix hosting approaches, mobility etc) in addition to multicast problem. In that sense, I agree we should look at all IETF specs including RFC  8505 and leverage any available protocols semantics.

Sri

From: Charlie Perkins <[email-masked]<mailto:[email-masked]>>
Date: Monday, April 15, 2019 at 7:16 AM
To: Alexandre Petrescu <[email-masked]<mailto:[email-masked]>>, Brian E Carpenter <[email-masked]<mailto:[email-masked]>>, NABIL BENAMAR <[email-masked]<mailto:[email-masked]>>, Sri Gundavelli <[email-masked]<mailto:[email-masked]>>
Cc: "Pascal Thubert (pthubert)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, nabil benamar <[email-masked]<mailto:[email-masked]>>
Subject: Re: [ipwave] Expertise on ND problems on OCB

Hello Alex and all,

  *   RFC 8505 isn't just about low power.  More to the point in this discussion, it's about reducing interference by reducing the number of multicasts needed in a multilink subnet.  Please note that I am neither discouraging nor advocating the use of RFC 8505 for v6-over-OCB, but I think it would be better to avoid suggesting that it is only useful for low-power mesh.

  *   Even if you did have four cars to run experiments, the results could hardly be considered conclusive.  Simulation can be very helpful in such circumstances.  You know the velocities and the range of the signal. You have many many thousands of easily accessible real-world topologies, and even the interference characteristics.

  *   I made a quick scan of the draft and found this: "All nodes in the subnet MUST be able to communicate directly using their link-local unicast addresses.".  Does this mean that the solution is not applicable for topologies exhibiting the hidden terminal problem?  Or, does "directly" mean something else?

I think the draft could benefit from a very clear applicability statement, specifically including the projected number of vehicles in the subnet.  If every vehicle on the subnet can expect deliver of multicast packets to every other vehicle on the subnet, then the problem is different than if hidden terminal effects occur or if multicast is unreliable for some other reason.  Maybe for clarity it would be helpful to include a diagram of a general target network with more than three or four vehicles.

You can also tell me that my opinion lacks relevance since I have not carefully read the draft.

Regards,
Charlie P.

[...]

I do have expert knowledge on ND on OCB, although only at a certain level.  It works.

Other people may claim ND does not work on OCB, but have they tried OCB at all?

It is the people who claim ND does not work on OCB should write the new version of the 'TBD' text.

It is very simple to try ND on OCB.  I published a howto on the email list.  A Hackathon w/o me was tried following that howto.  A few other organisations that I work with tried it (w/o me).  I did not received feedback from them about ND not working.

What is difficult to try is to reproduce the ND-over-OCB problem imagined by Pascal.  It is difficult to try because it involves 4 cars (I dont have that many).  It  is also difficult to try because it seems to miss the fact that OCB can do high power.  Maybe that high power solves the problems that appear in ND over low power.

For my part, I cant put text about ND on OCB without having an implementation of that problem.

It is for that reason that I asked Pascal, or anybody else claiming ND does not work on OCB, to try it and write that text 'TBD'.

Alex

Regards
     Brian

Alex

Regards
     Brian

On Sun, Apr 14, 2019, 00:06 Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]>> wrote:

      Sri

.

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 16 Apr 2019 10:56:53 +0200

Sri,

Thank you very much for the email.

I would like to take this opportunity to discuss publicly a particular
topic in your email, that we already touched upon in private a few
months ago.

I purposefully keep the other ideas of you out of this email, but I do
agree with very many of them.

Le 16/04/2019 à 05:11, Sri Gundavelli (sgundave) a écrit :
[...]
> From the point of view of vehicular safety, its about exchange of
> BSM (Basic Safety Messages) between vehicles as per SAEJ735
> standard.

Sri, but there are at least three versions of BSM.

Which BSM do you mean?

Why SAE and not ISO?  Both have 'International' in their names.

Why SAE 2016 and not SAE 2009?

- SAEJ2735 version 2009 (free access),
   (google hits "SAE J2735")
- SAEJ2735 version 2016 (paid access, cca 100 USD),
   (google hits "SAE J2735")
- and the ISO/CEN/ETSI versions (free access):
   https://www.tc278.eu/cits
   https://standards.iso.org/iso/ts/19091/addgrp_c

(remark I dont mention ETSI CAM, which is ITS safety in Europe).

The three seem to be different in contents, to a few people.  Myself I
identified the first and second to be distinct.

Ideally, safety would be just one standard, right?  Something like a
combination of all BSM versions with the CAM version running on a
transport that is common to all.

A safe car would need to be able to understand all these CAM and BSM
versions; if it misses just one because of some syntax error, well,
safety would be at stake.

> [...] and for very good reason IEEE WAVE standards did not bother to
> require IPv6 transport for carrying these messages.

I doubt that reason.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 16 Apr 2019 11:37:57 +0200

Le 15/04/2019 à 20:40, 神明達哉 a écrit :
>  > >  >    The fe80::/10 word was removed.
>  > >
> RFC is written without all CAPITAL keywords.

A commonly adopted interpretation?  I did not  know it, but I am happy 
to hear it existed.

I must share that much text in earlier versions of this IP-over-OCB 
document did not have any capitalized keyword.  I was told we must use 
capitalized keywords otherwise it wont do.  Why RFC4291 is not told to 
use capitalized keywords?

> If you're in doubt about

Yes, I would like to try that.

>                       regardless of whether routers are advertising a

Your argumentation sounds reasonable.

I thus propose in the IP-over-OCB document:

OLD:
> 	  A subnet is formed by the external 802.11-OCB interfaces of
> 	  prefix and the interfaces MUST be assigned IPv6 address(es)
> 	  of type link-local.  All nodes in the subnet MUST be able to
> 	  communicate directly using their link-local unicast
> 	  addresses.

NEW:
>    that are in close range (not by their in-vehicle interfaces).  A
>    Prefix List conceptual data structure ([RFC4861] section 5.1) is
>    maintained for each OCB interface.
> 
>    All nodes in the subnet MUST be able to communicate directly using
>    their link-local unicast addresses.

> terminology matter you can just say it's not a multi-link subnet.

I propose this:

NEW:
> 	  The subnet is not a multi-link subnet.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 16 Apr 2019 11:42:06 +0200

Brian,
Thanks for this.
It is surprising for me.

The events so happened that we are in this situation.  I am trying to 
improve it.

Alex

---

From: William Whyte <[email-masked]>
Date: Tue, 16 Apr 2019 11:40:27 +0200

I don't fully understand why IPWAVE, which is about network / transport
protocols, needs to have an opinion about what form of BSM to use.

Cheers,

William

-- 

---

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 16 Apr 2019 11:45:24 +0200

Which network/transport do BSMs use?

Alex

Le 16/04/2019 à 11:40, William Whyte a écrit :
> On Tue, Apr 16, 2019 at 10:58 AM Alexandre Petrescu

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 16 Apr 2019 10:06:57 +0000

Hello Sri

If the document was clearly scoped to P2P link local communication it would need correcting, like stop paraphrasing IEEE but it would eventually pass.

Beyond that scope it is a matter of use cases and solutions. I do not know what the WG decided for the former. The latter starts with applicability of existing work, in particular WiND.

If the group needs such functions I claim that we can already do hub and spoke subnets with either a single node as hub (a BSS at L3) or several nodes (that would be RSUs) connected by a high speed transit link. This can be done using Wireless ND and can be described in a few pages.

I claim we can already do mesh in relatively stable situations, e.g., relaying over cars in a parking lot to the RSU that provides Internet. 

I claim we can couple that with NEMO in the car and maintain global reachability while on the road.

What’s harder is to figure what’s reachable at which time. DNA and when to form new addresses. Discover services. How to use the fixed infrastructure to relay between cars while driving. These are some of the real and interesting problems left to be solved by the WG whereas reinventing the wheels could be a waste of time.

All the best,

Pascal

---

From: William Whyte <[email-masked]>
Date: Tue, 16 Apr 2019 12:12:37 +0200

That's a decision made further up the stack. It's not part of the scope of
this group.

For what it's worth: In the US, the BSM-based applications are based on SAE
J2945/1 and SAE J2735-2016 and sent over WSMP. In Europe, cooperative
awareness using CAM is based on EN 302 637-2 and sent over BTP. But even if
BSMs were sent over IP, the version of BSM used would be out of scope for
this group. That's how layered systems work.

William

- sent from my phone

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 16 Apr 2019 12:18:08 +0200

>  it is only useful for low-power mesh.

I will avoid suggesting RFC8505 is only for low-power mesh.  Ideally I
would like to know which power levels are used in these meshes, and
group them with the power levels in OCB, and maybe call them a range
where that RFC may apply.

> * Even if you did have four cars to run experiments, the results 
> could hardly be considered conclusive.  Simulation can be very 
> helpful in such circumstances.  You know the velocities and the
> range of the signal. You have many many thousands of easily
> accessible real-world topologies, and even the interference
> characteristics.

I agree, maybe both simulation and car use would be conclusive.

> Or, does "directly" mean something else?

'Directly', to me, means directly at networking layer (layer 3).  To me,
it also means these link local addresses are present in the src and dst
fields of the first IP header of a packet.

The topologies with the hidden terminal problem: I did not see them in
practice.

The hidden-terminal problem was formulated for WiFi non-OCB.

I do not know how the hidden terminal problem works.  I feel like if I
start looking into it I will grow additional white hairs.  I feel like I
better avoid  it.

I think other people have some experience with the hidden terminal
problem in non-OCB WiFi and 802.15.4.  I am listening to them.

I think nobody has any experience with the hidden terminal problem in
OCB settings.  I have some doubts, but still I think it is almost nobody.

> statement, specifically including the projected number of vehicles
> in the subnet.  If every vehicle on the subnet can expect deliver of
>  multicast packets to every other vehicle on the subnet, then the 
> problem is different than if hidden terminal effects occur or if 
> multicast is unreliable for some other reason.

I think I agree in general.

I would like to discuss details:
- is it more reasonable to put the applicability statement in the IP-
   over-OCB document, or in the vehicular-networking problem statement
   document?  I prefer the  latter.  If you prefer the former, please
   tell where in the document.
- to put the number of vehicles in subnet is reasonable to qualify the
   applicability statement.  This should be in relationship with the max
   power range and the assumed PHY propagation (antennas, etc.)
- the multicast aspects are referred to in the IP-over-OCB draft by
   pointing to [I-D.ietf-mboned-ieee802-mcast-problems.  I think this is
   sufficient.

> Maybe for clarity it would be helpful to include adiagram of a
> general target network with more than three or four vehicles.

There is such a diagram in the vehicular-networking problem statement
draft.  It is Figure 1.  There are successive dots (like '...' expansion
dots)  which suggest there are are more than a few vehicles.

Please read the draft.

Alex

> Regards, Charlie P.
>>>>> exacerbated in OCB mode.  Solutions for these problems
>>>>> SHOULD consider the OCB mode of operation.  The best of
>>>>> current knowledge indicates the kinds of issues that may
>>>>> arise with ND in OCB mode; they are described in Appendix J.
>>> 
>>> That's exactly the text that I find problematic. I can't write a 
>>> new version because I lack your expert knowledge, but IMHO it 
>>> should be more specific:
>> 
>> It is very simple to try ND on OCB.  I published a howto on the 
>> email list.  A Hackathon w/o me was tried following that howto.  A 
>> few other organisations that I work with tried it (w/o me).  I did 
>> not received feedback from them about ND not working.
>> 
>> imagined by Pascal.  It is difficult to try because it involves 4 
>> cars (I dont have that many).  It  is also difficult to try
>> because it seems to miss the fact that OCB can do high power. Maybe
>> that high power solves the problems that appear in ND over low
>> power.
>> 
>> It is for that reason that I asked Pascal, or anybody else
>> claiming ND does not work on OCB, to try it and write that text
>> 'TBD'.
>> 
>> Alex
>> 
>>> 
>>> The baseline Neighbor Discovery protocol (ND) [RFC4861] MUST be 
>>> used over 802.11-OCB links.  However, as on any wireless link, 
>>> transmission of multicast ND packets may fail in OCB. In 
>>> particular, scenarios where TBD TBD TBD are likely to be 
>>> unreliable and SHOULD NOT be deployed until an alternative 
>>> standardised solution is available. The best of current
>>> knowledge indicates the kinds of issues that may arise with ND in
>>> OCB mode; they are described in Appendix J.
>>> 
>>> IPv6 packets over OCB while relying on IPv6 ND alone for DAD and
>>> AR (Address Resolution).
>>> 
>>> Early experience indicates that it is possible to exchange IPv6 
>>> packets over OCB while relying on IPv6 ND alone for DAD and AR 
>>>>>> reasons not to delay this work.
>>>>>> 
>>>>>> stable topology of RSU¹s and OBU¹s. The regulations around 
>>>>>> 5.9 Ghz (DSRC) band allows the channel use for 
>>>>>> non-priority/non-traffic safety related applications. For 
>>>>>> There, its a stable topology that classic ND is designed 
>>>>>> for. In this operating mode, its perfectly reasonable to 
>>>>>> use classic ND and it works. The authors have shown enough
>>>>>>  lab data on the same.
>>>>>> 
>>>>>> publish both the specs at the same time. But, for what
>>>>>> ever reasons the WG went on this path. Authors have spent 
>>>>>> incredible amount of efforts in getting the draft this far 
>>>>>> and we cannot ignore that. You can see the efforts from the
>>>>>> filter out the threads that are clearly motivated to
>>>>>> insert a ND protocol that is designed for a totally
>>>>>> different operating environment. An argument that a
>>>>>> solution for vehicular environments requires some serious
>>>>>> vetting. Looking at the characteristics, always-sleeping,
>>>>>> occasional internet connectivity, low-power, no memory, no
>>>>>> processing power, no mobility ..etc, meeting vehicular
>>>>>> requirements is some thing most people in the WG do not get
>>>>>> it.
>>>>>> 
>>>>>> the document. All we need is a simple statement in the
>>>>>> spec which puts some scope limits, w.r.t the missing ND
>>>>>> pieces and issues. There are other proposals in the WG that
>>>>>> will address the gaps and bring closure to the work.
>>>>>> 
>>>>>> Sri
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> <[email-masked] 
>>>>>> <mailto:[email-masked]>> wrote:
>>>>>> 
>>>>>>>> many
>>>>>>>> configuration, DAD, ND aspect, link models. When there 
>>>>>>>> is
>>>>>> such a scope
>>>>>>> done
>>>>>>> However, I don't believe that publishing an RFC about
>>>>>>> the
>>>>>>> 
>>>>>> frame format
>>>>>>> we'd presumably like Fords to be able to communicate
>>>>>>> with
>>>>>>> 
>>>>>> Peugeots,

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 16 Apr 2019 12:28:50 +0200

Le 16/04/2019 à 12:12, William Whyte a écrit :
> That's a decision made further up the stack. It's not part of the scope 
> of this group.
> 
> For what it's worth: In the US, the BSM-based applications are based on 
> SAE J2945/1 and SAE J2735-2016 and sent over WSMP. In Europe, 
> cooperative awareness using CAM is based on EN 302 637-2 and sent over 
> BTP. But even if BSMs were sent over IP, the version of BSM used would 
> be out of scope for this group. That's how layered systems work.

I agree layered systems are good to focus, and interfaces.

I think that an overarching CAM-BSM message put on UDP/IP specified at 
IETF may get benefits beyond just layering and interfaces.

Such a spec would tell, for example, that in worst case the cars MUST 
accept both EtherTypes (dont drop either), by the principle of being 
conservative on what to accept.  And in best case expect an IPv6 
EtherType that carrying an IP datagram carrying an overarching BSM-CAM.

That could probably improve safety in some situations.

It is also true that that is a standpoint of IP packets being the same 
all over the world, whereas cars are not really the same.  E.g. in 
America the cars are allowed to have both left and right yellow lights 
turned on permanently, but not in other parts of the world.

So I am really not sure whether an idea of an overarching CAM-BSM over 
IP can ever fly, even though I like it.

Alex

> 
> William
> 
> - sent from my phone
> 
> On Tue, Apr 16, 2019, 11:45 AM Alexandre Petrescu 
>     <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>      >
>      >     Sri,
>      >
>      >      > From the point of view of vehicular safety, its about
>     exchange of
>      >      > BSM (Basic Safety Messages) between vehicles as per SAEJ735
>      >      > standard.
>      >
>      >      > [...] and for very good reason IEEE WAVE standards did not
>     bother to
>      >      > require IPv6 transport for carrying these messages.
>      >
>      >     I doubt that reason.
>      >
>      >     Alex
>      >
>      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>

---

From: William Whyte <[email-masked]>
Date: Tue, 16 Apr 2019 12:33:33 +0200

But none of that explains why the BSM type is in scope for this group. That
seems like a different work item.

- sent from my phone

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 16 Apr 2019 12:52:37 +0200

> Indeed, there's some subtle point here.  RFC4007 somewhat tries to

Well,  RFC4007 predates RFC4291, so it is little meaningful to say it 
clarifies it.

Maybe we can say that RFC4291 must be updated given all these issues.

>      inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2

Ah?  It self-forms that fe80 address without a sysadmin requesting it?

In other OSs like linux, windows, there is no fe80::1 unless the 
sysadmin adds it.

In that sense, this is an additional reason (together with the 
RFC4291-violating fe80:1::1 potentially breaking in BSD) to think that 
RFC4291 and co. are mostly for BSDs.

This is not a happy situation to be in.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 16 Apr 2019 12:58:01 +0200

Le 15/04/2019 à 22:53, Brian E Carpenter a écrit :
[...]

> which conflicts with RFC4291.

True.  I forgot that 118.  Thank you for pointing to it.

Remark, it says MAY, not MUST.

Do you stronly disagree with 118?  I can remove the phrase containing 
it, if so.  I can also remove the entire cited text altogether, such 
that to be silent about the length of the Interface ID.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 16 Apr 2019 13:01:52 +0200

Le 15/04/2019 à 23:02, 神明達哉 a écrit :
> "Pascal Thubert (pthubert)" <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>  > The point on multilink subnet is that link local address that is 
> limited to the link cannot reach all nodes in the MLSN. This illustrates 
> that a link and a subnet are very different beasts, whereby the former 
> is physical and the latter logical.
> 
> Yes, I understand that.
> 

The -41 text is in the draft.

If you feel like I should change it please let me know.

I need to understand whether Pascal agrees with the text in -41.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 16 Apr 2019 15:59:19 +0200

Le 15/04/2019 à 23:04, Brian E Carpenter a écrit :> Excuse top posting.
 >
 > As I've said, I am no expert, but I do know some physics, and it
 > seems pretty clear to me that if there are multiple lanes of traffic,
 > a large truck can easily shield signals between two cars and the
 > shielding will be intermittent, regardless of how much wireless power
 > is allowed, depending on traffic movement. So it's a highly dynamic
 > mesh network.

Well I agree with your intuitive description of the truck-between-cars 
situation. But I dont agree to call it highly dynamic mesh network, for 
any definition of this latter; there is very little dynamicity in it.  I 
dont agree to tell it has problems with ND, because I experimented it 
and it works[*]

Alex

---------------------------

[*] I can explain why. This explanation comes from practice with OCB and 
with radars/lidars with cars on road.

The intuitive description that you make is that of a blocking of signal 
by a solid separator object:

                  ----------
                 |          |
     -------     |  Truck   |    -------
    |  Car  |    |          |   |  Car  |
     -O---O-      -O-O-----O-    -O---O-
---------------------------------------------- asphalt

In this illustration, it may be difficult for Cars to talk to each other 
on OCB, because of that Truck in the middle.

But when trying it on road, we realized  the Cars do talk ok to each 
other on OCB, even if there are these solid objects separators.  (worse, 
even the radars can see each other, some times, as if the Truck was 
absent.  Note that the effect of radar or camera that sees below a truck 
is reocgnized as the main cause of a known Tesla accident, among others.)

Some expert view explained this by waves reflected by below the Truck 
(asphalt).  I heard it verbatim from a partner.

These two sequences of photos illustrate such behaviour with OCB on the 
road.  The sequences are available on the web at 
https://youtu.be/F-_4Wmyzh2c?t=161

This is not the first such experiment to 'see thru' vehicles.  Other 
organisations did it before.  The ones that I know of are Samsung and a 
University in Spain.

In the first sequence we see how two cars between two other cars dont 
obstruct the IP-over-OCB propagation of a video stream between the first 
and rearmost vehicles.

In the second sequence we see how a big truck between two cars doesnt 
obstruct the IP-over-OCB propagation of such a video stream.

1st sequence:

The photo below shows the screen in one car that contains the video 
streamed from the front car with IPv6 on OCB.  The two cars are 
immediately following each other on highway:
https://youtu.be/F-_4Wmyzh2c?t=168

In the photo below we see the front car immediately in front of this car

https://youtu.be/F-_4Wmyzh2c?t=178

In the photo below we see an intermediary small car (white) getting in 
the middle.  The streaming continues, as if the intermediary car was not 
obstructing the OCB.

In the photo below we see a 2nd intermediary small car (still white) 
that gets in the middle.  The streaming continues (at least the human 
filmer did not see a change, because it may have happened too fast).

2nd sequence:

In the photo below we see the 1st car getting further and a truck 
approaching to insert between the two:

In the photo below we see the truck obstructing the view:

In the photo below we see the video displayed in this car, that is 
streamed on IPv6-over-OCB and that does get through:

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 16 Apr 2019 16:07:48 +0200

Le 16/04/2019 à 12:06, Pascal Thubert (pthubert) a écrit :
> Hello Sri
> 
> If the document was clearly scoped to P2P link local communication it
> would need correcting, like stop paraphrasing IEEE but it would
> eventually pass.

I do not know what do you mean by P2P.

In my experiments we also used three cars with IP on a single subnet OCB.

The term I may be using is something like

       P
      P2P

if such a multidimensional term can exist.

> Beyond that scope it is a matter of use cases and solutions. I do not
> know what the WG decided for the former. The latter starts with
> applicability of existing work, in particular WiND.
> 
> If the group needs such functions I claim that we can already do hub
> and spoke subnets with either a single node as hub (a BSS at L3) or
> several nodes (that would be RSUs) connected by a high speed transit
> link. This can be done using Wireless ND and can be described in a
> few pages.
> 
> I claim we can already do mesh in relatively stable situations, e.g.,
> relaying over cars in a parking lot to the RSU that provides
> Internet.

It's great to know.

Did it use OCB?

(we define IP-RSU to be an RSU that does OCB.)

Alex

> What’s harder is to figure what’s reachable at which time. DNA and
> when to form new addresses. Discover services. How to use the fixed
> infrastructure to relay between cars while driving. These are some of
> the real and interesting problems left to be solved by the WG whereas
> reinventing the wheels could be a waste of time.
> 
> All the best,
> 
> Pascal
> 
>>> I am no expert, but I do know some physics, and it seems pretty
>>> clear to me that if there are multiple lanes of traffic, a large
>>> truck can easily shield signals between two cars and the
>>> shielding will be intermittent, regardless of how much wireless
>>> power is allowed, depending on traffic movement. So it's a highly
>>> dynamic mesh network.
>> 
>> 
>> Part of the problem is that we have not clearly put some limits on
>> the use-cases. These unbounded limits is opening up these
>> discussions on ad-hoc full mesh network formations and the
>> resulting challenging ND scenarios. But, again I always assumed
>> this discussion is for the ND document and there should be no
>> bearing on this document.
>> 
>> V2X communications involves V2V, V2I and V2P communication modes.
>> standard. These safety communications is always one-hop
>> communication and for very good reason IEEE WAVE standards did not
>> bother to require IPv6 transport for carrying these messages. The
>> WSMP message which carries these safety elements are defined to be
>> carried over layer-2 payloads. Personally, I never thought we will
>> replace this L2 safety communication mode with layer-3 mode 
>> applications in the vehicle to communicate with the infrastructure.
>> For example, a vehicle using DSRC radio to access some traffic
>> application in the cloud.
>> 
>> In one sense, this is like a mobile node using 802.11-OCB like any
>> other radio technology (CDMA, LTE, Wi-Fi), and use IPv6 for its
>> communications. In this context, its always about vehicle to
>> infrastructure communications. Now, there are other interesting
>> peer to peer use-cases, where one vehicle is streaming some video
>> to another vehicle without using any infrastructure. While these
>> later examples are very cool, personally, I did not expect this WG
>> to solve those use-cases day-1. For us to support those use-cases,
>> we need to figure out many more things including approaches for
>> exchanges prefixes between two vehicles that come in proximity. In
>> my mind, these are very forward looking and the only relevant
>> application is platooning. I am not interested in solving this V2V
>> problem, but was more interested to enable V2I communications,
>> where the focus is about link model, prefix hosting approaches,
>> mobility support (building a large L2 domain over RSU’s, or routed
>> approaches with mobile IP type protocols) ..etc. In one
>> realization, there may be a P2P link assumption between the vehicle
>> and the RSU, eliminating most of these ND issues. But, those
>> discussions are for the other document and that clearly should
>> remove these ND concerns from this document.
>> 
>> Sri
>> 
>> 
>> 
>> 
>> 
>> 
>> On 4/15/19, 2:04 PM, "Brian E Carpenter"
>> <[email-masked]> wrote:
>> 
>>> Excuse top posting.
>>> 
>>> seems pretty clear to me that if there are multiple lanes of
>>> traffic, a large truck can easily shield signals between two cars
>>> and the shielding will be intermittent, regardless of how much
>>> wireless power is allowed, depending on traffic movement. So it's
>>> a highly dynamic mesh network. That's a very interesting problem
>>> that has been much studied, and it's fundamentally different from
>>> the ND design scenario.
>>> 
>>> So I find it hard to believe that nobody can write the TBD text.
>>> 
>>> Regards Brian
>>> 
>>>> On 15-Apr-19 23:26, Alexandre Petrescu wrote: Hi Brian,
>>>> 
>>>>> Le 14/04/2019 à 22:49, Brian E Carpenter a écrit : Hi
>>>>> Alexandre,
>>>>> 
>>>>>> On 15-Apr-19 04:38, Alexandre Petrescu wrote: Brian,
>>>>>> 
>>>>>>>>> All we need is a simple statement in the spec which
>>>>>>>>> puts some scope limits, w.r.t the missing ND pieces
>>>>>>>>> and issues.
>>>>>>> 
>>>>>>> health warning that implementers must not rush ahead
>>>>>>> because of the risk of non-interoperability.
>>>>>> 
>>>>>> There is already paragraph, and an Appendix, about
>>>>>> potential ND issues. I think that text qualifies as an
>>>>>> associated health warning.
>>>>>> 
>>>>>> I do not know what do you mean about the risk of
>>>>>> interoperability. This ND that works is interoperable
>>>>>> between several OCB cards, IP Road Side Units, and linuces.
>>>>>> (I can cite brands that I al familiar with and that 
>>>>>> interoperate.
>>>>>> 
>>>>>>> The baseline Neighbor Discovery protocol (ND) [RFC4861]
>>>>>>> MUST be used over 802.11-OCB links.  Transmitting ND
>>>>>>> packets may prove to have some performance issues.  These
>>>>>>> issues may be exacerbated in OCB mode.  Solutions for
>>>>>>> these problems SHOULD consider the OCB mode of operation.
>>>>>>> The best of current knowledge indicates the kinds of 
>>>>>>> issues that may arise with ND in OCB mode; they are
>>>>>>> described in Appendix J.
>>>>> 
>>>>> That's exactly the text that I find problematic. I can't
>>>>> write a new version because I lack your expert knowledge, but
>>>>> IMHO it should be more specific:
>>>>> 
>>>>> be used over 802.11-OCB links.  However, as on any wireless
>>>>> link, transmission of multicast ND packets may fail in OCB.
>>>>> In particular, scenarios where TBD TBD TBD are likely to be
>>>> But I need an indicat that TBD is defined soon.  The time
>>>> commitments of Pascal seem to be saying he is no longer
>>>> interested in writing that TBD.
>>>> 
>>>>> Early experiences indicate that it should be possible to
>>>>> exchange IPv6 packets over OCB while relying on IPv6 ND alone
>>>>> for DAD and AR (Address Resolution).
>>>>> 
>>>>> IPv6 packets over OCB while relying on IPv6 ND alone for DAD
>>>>> and AR (Address Resolution) in good conditions. However, this
>>>>> does not apply if TBD TBD TBD...
>>>> 
>>>>>>>> I understand your point Brian, but IMO there are
>>>>>>>> enough reasons not to delay this work.
>>>>>>>> 
>>>>>>>> stable topology of RSU¹s and OBU¹s. The regulations
>>>>>>>> around 5.9 Ghz (DSRC) band allows the channel use for
>>>>>>>> non-priority/non-traffic safety related applications.
>>>>>>>> For example, a vehicle in a gas station can receive a
>>>>>>>> coupon from the 802.11-OCB radio (AP/RSU) in the gas
>>>>>>>> station. There, its a stable topology that classic ND
>>>>>>>> is designed for. In this operating mode, its perfectly 
>>>>>>>> reasonable to use classic ND and it works. The authors
>>>>>>>> have shown enough lab data on the same.
>>>>>>>> 
>>>>>>>> Ideally, I agree with you that it makes lot more sense
>>>>>>>> to publish both the specs at the same time. But, for
>>>>>>>> what ever reasons the WG went on this path. Authors
>>>>>>>> have spent incredible amount of efforts in getting the
>>>>>>>> draft this far and we cannot ignore that. You can see
>>>>>>>> the efforts from the version number; when did we last
>>>>>>>> see a draft version -037?
>>>>>>>> 
>>>>>>>> solution for vehicular environments requires some
>>>>>>>> serious vetting. Looking at the characteristics,
>>>>>>>> always-sleeping, occasional internet connectivity, 
>>>>>>>> low-power, no memory, no processing power, no mobility
>>>>>>>> ..etc, meeting vehicular requirements is some thing
>>>>>>>> most people in the WG do not get it.
>>>>>>>> 
>>>>>>>> Bottom line, IMO, we should move this forward and
>>>>>>>> publish the document. All we need is a simple statement
>>>>>>>> in the spec which puts some scope limits, w.r.t the
>>>>>>>> missing ND pieces and issues. There are other
>>>>>>>> proposals in the WG that will address the gaps and
>>>>>>>> bring closure to the work.
>>>>>>>> 
>>>>>>>> Sri
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>>> On 13-Apr-19 02:59, Sri Gundavelli (sgundave)
>>>>>>>>>> wrote: If you go back and check 2017 archives, I
>>>>>>>>>> did raise many of
>>>>>>>> these
>>>>>>>>>> issues.  But, we clearly decided to limit the
>>>>>>>>>> scope
>>>>>>>> excluding address
>>>>>>>>>> configuration, DAD, ND aspect, link models. When
>>>>>>>>>> there is
>>>>>>>> such a scope
>>>>>>>>> This is of course possible. In general the IETF
>>>>>>>>> hasn't done
>>>>>>>> that, but has
>>>>>>>>> idea. That would leave developers absolutely unable
>>>>>>>>> to write
>>>>>>>> useful

---

From: Charlie Perkins <[email-masked]>
Date: Tue, 16 Apr 2019 07:26:40 -0700

Hello Alex,

Consider the following three nodes with radio links as shown:

A----------B----------C

Suppose that A and B are at 80% of their signal range, and also that B 
and C are at 80% of their signal range.

So A and C are not in range.  So A is 'hidden' from C, and C is 'hidden' 
from A.

That's the hidden terminal problem.  It's not specific to OCB or WiFi, 
and it is not a hypothetical problem.  It's just physics. It's not at 
all difficult to understand, but it is very important to understand.

One question below...

> OCB settings.  I have some doubts, but still I think it is almost nobody.
I find this very surprising!  What do others think?

Regards,
Charlie P.

---

From: 神明達哉 <[email-masked]>
Date: Tue, 16 Apr 2019 07:30:28 -0700

At Tue, 16 Apr 2019 12:52:37 +0200,

> Well,  RFC4007 predates RFC4291, so it is little meaningful to say it

Could we be stop nitpicking?  I didn't say RFC4007 clarified RFC4291;
I meant it clarified the requirement of having a link-local address on
all interfaces, which I thought was clear from the context.  For that
matter, the above exact same text has existed since RFC2373.  Even
RFC1884 (the very first address architecture RFC) essentially says the
same thing in Section 2.7.

> Ah?  It self-forms that fe80 address without a sysadmin requesting it?

Yes.

> RFC4291 and co. are mostly for BSDs.

You're free to think so.  But that doesn't change the fact that
fe80:1::1 violates the RFC, so you'll need to update it if you want it
to be allowed.

Note also that MacOS is derived from BSD in case you don't
remember/know it.  And, in fact it also generates both "fe80::1" and
"::1" on the "lo0" interface.

Anyway, I don't think this discussion affects your draft?  If you want
to continue it, 6man would be a better place, if only to reduce the
noise in the original thread.

--
JINMEI, Tatuya

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 16 Apr 2019 16:38:39 +0200

Le 16/04/2019 à 16:30, 神明達哉 a écrit :
>  > >  > That RFC4291 section 2.1 says:
>  > >  > >    All interfaces are required to have at least one Link-Local 
> unicast
>  > >  > >    address (see Section 2.8 for additional required addresses).
>  > >  >
>  > >  > Sidenote: I think the loopback interface does not have a link-local
>  > >  > address.  Probably it is not all interfaces that must have at least
>  > > one ll(
>  > >

I would like to know from you whether the current state of the draft is 
ok with you at this time?

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 16 Apr 2019 16:46:07 +0200

> all difficult to understand, but it is very important to understand.

Such an elegant (short, easy) problem on paper, and such hard to try in 
practice.

---

From: 神明達哉 <[email-masked]>
Date: Tue, 16 Apr 2019 09:06:55 -0700

At Tue, 16 Apr 2019 16:38:39 +0200,

> ok with you at this time?

My recent comments are just for informational anyway, but to be
explicit for this particular "side note", yes, the current state of
the draft is okay with me.

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Tue, 16 Apr 2019 09:23:13 -0700

At Tue, 16 Apr 2019 11:37:57 +0200,

> use capitalized keywords?

I believe the use of capitalized words is quite strongly recommended
today, at least as a matter of practice.  As for RFC4291 (or for that
matter RFC8200), I don't know the real reason, but I suspect it's a
mixture of personal taste (of the author at that time) and historical
inertia.  The first version of these RFCs were written way before
RFC2119, at that point the convention of capitalized keywords were
less common.  We could have modernized these RFCs while we updated
them, but I *guess* the WG has just chosen to respect the seeming
intent of the original author of not using capitalized words.  (IIRC
there was even a discussion about this during the most recent
revision from RFC2460 to RFC8200).

> >    their link-local unicast addresses.

This is fine for me, although some others may rather find the phrase
"directly using" confusing.  If it's all about on-link determination,
you may just want to remove this sentence, which is also fine for me.

> >       The subnet is not a multi-link subnet.

Same for this one.  If you really want to note it's not a multi-link
subnet, this is fine for me.  But you may rather find it another
distracting (or even possibly controversial) point, and may rather not
to mention it.  That's fine for me, too.

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Tue, 16 Apr 2019 09:30:36 -0700

At Tue, 16 Apr 2019 12:58:01 +0200,

> that to be silent about the length of the Interface ID.

(Speaking for myself who just happenned to notice it - I overlooked this
118, too).  I'd say it's more consistent with the removal of "fe80::/10"
if we simply remove "In the particular case of IPv6 link-local
addresses..." sentence.  If it really has to stay here, it will
inevitably need to be an update to RFC4291 and need to pass that high
bar (quite likely delaying the publication substantially, if not
making it fail).  Unless that's absolutely necessary for this protocol
specification, it's much safer not to discuss that in this document.

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 17 Apr 2019 08:48:06 +1200

On 17-Apr-19 04:30, 神明達哉 wrote:
> Alexandre Petrescu <[email-masked] <mailto:[email-masked]>> wrote:
> 

Agreed.

    Brian

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 17 Apr 2019 09:46:30 +0200

>> specification, it's much safer not to discuss that in this document.

I propose the following:
OLD:
> 	  A randomized Interface ID has the same characteristics of a
> 	  randomized MAC address, except the length in bits.  A MAC
> 	  address SHOULD be of length 48 decimal.  An Interface ID
> 	  SHOULD be of length 64 decimal for all types of IPv6
> 	  addresses.  In the particular case of IPv6 link-local
> 	  addresses, the length of the Interface ID MAY be 118
> 	  decimal.

NEW:
> 	  A randomized Interface ID has the same characteristics of a
> 	  randomized MAC address, except the length in bits.  A MAC
> 	  address SHOULD be of length 48 decimal.  An Interface ID
> 	  SHOULD be of length specified in other documents.

Do you disagree?

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 17 Apr 2019 09:56:39 +0200

Le 16/04/2019 à 16:30, 神明達哉 a écrit :
[...]> Note also that MacOS is derived from BSD in case you don't
> "::1" on the "lo0" interface.

Right, I forgot that.

But there is something I never knew for sure.

Are BSD flavors supporting OCB options?

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 17 Apr 2019 11:41:58 +0200

Brian,

> main drafts properly synchronized.

I would like to ask you whether you disagree that we move the appendix 
titled "ND issues in wireless links" away from the IP-over-OCB draft 
into the IPWAVE Problem Statement draft?

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 17 Apr 2019 11:46:29 +0200

Hello Pascal,

You describe below a problem with DAD, and a potential solution with 
RFC8505.

We have two drafts here in IPWAVE WG: IP-over-OCB, and IPWAVE Problem 
Statement.

Do you disagree if we move the appendix titled "ND issues in wireless 
links" away from IP-over-OCB, and into the Problem Statement draft?

Maybe that draft would be a better fit for ND an DAD problems and 
suggested solutions.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 17 Apr 2019 13:12:43 +0200

Le 16/04/2019 à 05:11, Sri Gundavelli (sgundave) a écrit :
>> truck can easily shield signals between two cars and the shielding
>>  will be intermittent, regardless of how much wireless power is 
>> allowed, depending on traffic movement. So it's a highly dynamic 
>> mesh network.
> 
> 
> the use-cases. These unbounded limits is opening up these discussions
> on ad-hoc full mesh network formations and the resulting challenging
> ND scenarios. But, again I always assumed this discussion is for the
> ND document and there should be no bearing on this document.
> 

For the term V2P (Vehicle to Pedestrian) I would like to suggest
addition of term VRU as well: Vulnerable Road Users.  I suggest the new 
term V2VRU: Vehicle to VRU.

VRUs dont have OCB interfaces (smartphones's wifi interfaces cant be set
at 5.9GHz), yet they are at most risk since they are not protected by
cages like the  automobiles are.

V2VRU is a problem, because OCB-equipped vehicles can communicate to
OCB-free VRUs only by means of high-latency cellular network (50ms 4G vs
1.5ms OCB).  In safety, lower latency is preferred over higher latency.

I would like to suggest the above addition in the Problem Statement 
draft, section 3 "Use Cases".

> From the point of view of vehicular safety, its about exchange of BSM
> (Basic Safety Messages) between vehicles as per SAEJ735 standard.
> These safety communications is always one-hop communication and for
> very good reason IEEE WAVE standards did not bother to require IPv6
> transport for carrying these messages. The WSMP message which carries
> these safety elements are defined to be carried over layer-2
> payloads. Personally, I never thought we will replace this L2 safety
> communication mode with layer-3 mode (IPv6-over-80211-OCB). But the
> use of IPv6 is more for allowing applications in the vehicle to
> communicate with the infrastructure. For example, a vehicle using 
> DSRC radio to access some traffic application in the cloud.
> 
> infrastructure communications.

I would like to suggest addidion of text about "BSM" in the Problem
Statement draft.

The localisation corrections are highly needed in OCB, potentially with 
BSM and/or other V2X message.

> Now, there are other interesting peer to peer use-cases, where one 
> vehicle is streaming some video to another vehicle without using any 
> infrastructure.

I would like to suggest to add in section "V2V" in the Problem Statement
draft the following text:

NEW:
> o  see thru: streaming video from one vehicle to another vehicle 
> without using any infrastructure, to see through obstacles

> While these later examples are very cool, personally, I did not
> expect this WG to solve those use-cases day-1.

I would like to suggest the addition of the term "day-1" to the Problem
Statement draft.

> For us to support those use-cases, we need to figure out many more
> things including approaches for exchanges prefixes between two
> vehicles that come in proximity. In my mind, these are very forward
> looking and the only relevant application is platooning. I am not
> interested in solving this V2V problem, but was more interested to
> enable V2I communications, where the focus is about link model,
> prefix hosting approaches, mobility support (building a large L2
> domain over RSU’s, or routed approaches with mobile IP type
> protocols) ..etc. In one realization, there may be a P2P link
> assumption between the vehicle and the RSU, eliminating most of these
> ND issues. But, those discussions are for the other document and that
> clearly should remove these ND concerns from this document.

I agree.

Alex

---

From: NABIL BENAMAR <[email-masked]>
Date: Wed, 17 Apr 2019 12:18:42 +0100

It's a good idea to refer to Vulnerable Road Users which refer to bicycles
as well as pedestrians.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 17 Apr 2019 09:39:24 -0400

Trimmed.

On 4/17/19 3:46 AM, Alexandre Petrescu wrote:
...
>>       SHOULD be of length specified in other documents.

"SHOULD be of a length specified in other documents" wihtout any 
reference to what the other documents are or how to find them seems like 
a recipe for implementor error.  Can we be somewhat more specific?

Thank you,
Joel

---

From: Jérôme Härri <[email-masked]>
Date: Wed, 17 Apr 2019 15:47:45 +0200

Hi Alex,

Well, VRU will have OCB...but it depends on what you call VRU...for example,
motorcycles and scooters are both part of VRUs and the CAR2CAR currently
develops an adapted ITS-G5 system for them. Yet, for pedestrian, indeed no
OCB foreseen so far...so, if it is about knowing who has OCB or not (say:
can use OCB or cannot use), then V2VRU might be too large denomination..

BR,

Jérôme

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Wednesday 17 April 2019 13:13
To: Sri Gundavelli (sgundave); Brian E Carpenter; NABIL BENAMAR
Cc: Pascal Thubert (pthubert); [email-masked]; [email-masked];
[email-masked]; [email-masked]; nabil
benamar
Subject: Re: [ipwave] use-cases in Problem Statement

> domain over RSUs, or routed approaches with mobile IP type

I agree.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 17 Apr 2019 16:08:22 +0200

> a recipe for implementor error.  Can we be somewhat more specific?

One could be more specific about which document.  There is some 
individual work item (not a WG item) in 6man that one could point to.  A 
reference to a non WG item will not delay this document?

Or, rather, should I propose a new formulation above which just keeps:

NEW:
>       randomized MAC address.

Alex

---

From: Eric Gray <[email-masked]>
Date: Wed, 17 Apr 2019 14:24:09 +0000

Adding to what Joel said, why are we attempting to define how long a MAC address SHOULD be?

-----Original Message-----
From: ietf <[email-masked]> On Behalf Of Joel M. Halpern
Sent: Wednesday, April 17, 2019 9:39 AM
To: Alexandre Petrescu <[email-masked]>
Cc: <[email-masked]> <[email-masked]>; IETF Discussion <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: 118

Trimmed.

....
>>       SHOULD be of length specified in other documents.

"SHOULD be of a length specified in other documents" wihtout any reference to what the other documents are or how to find them seems like a recipe for implementor error.  Can we be somewhat more specific?

Thank you,
Joel

---

From: 神明達哉 <[email-masked]>
Date: Wed, 17 Apr 2019 07:27:10 -0700

At Wed, 17 Apr 2019 09:56:39 +0200,

> Are BSD flavors supporting OCB options?

I don't know, but I don't think it matters here anyway: this particular
sub-thread is already an off-topic for draft-ietf-ipwave-ipv6-over-80211ocb.

--
JINMEI, Tatuya

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 17 Apr 2019 16:29:24 +0200

> Adding to what Joel said, why are we attempting to define how long a MAC address SHOULD be?

We are attempting to define how long a better privacy Interface ID (not 
MAC) should be.

There is a difference between an Interface ID and a MAC address.

An Interface ID is what to put near a prefix to make an address.  For 
example, 3 in 192.168.1.3 is an Interface ID.

The longer IID the better privacy, intuitively speaking.

Why do you think we try to define how long a MAC address should be?

Alex

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 17 Apr 2019 15:33:22 +0100

> The longer IID the better privacy, intuitively speaking.

I don't understand that tbh. The longer the string or
bigger the range or numbers, the more precisely one
can identify someone would be my intuition.

S.

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 17 Apr 2019 16:33:53 +0200

Le 17/04/2019 à 16:27, 神明達哉 a écrit :
> I don't know, but I don't think it matters here anyway:

Maybe it matters, maybe it does not matter.

If BSD does not support OCB, why should we write an IP-over-OCB spec 
along the lines of BSD which does not accept fe80:1::1 in the first place?

Were BSD to support OCB then indeed we would be reluctant in writing a 
spec which outlaws fe80:1::1.

Alex

  this particular

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 17 Apr 2019 16:37:06 +0200

> can identify someone would be my intuition.

True enough.

But also the longer the string the harder is to revert back to the 
secret key.  The longer the prime the harder to tell it is prime or not.

The shorter the IID, the easier it is to brute force it into the secret key.

Variable is probably best.

Alex

---

From: 神明達哉 <[email-masked]>
Date: Wed, 17 Apr 2019 08:20:55 -0700

At Wed, 17 Apr 2019 16:33:53 +0200,

> along the lines of BSD which does not accept fe80:1::1 in the first place?

I don't get it.  This sub-thread is not about fe80:1::1 but about
whether to assign an fe80 address on a loopback interface.

But to answer the question: because we don't know if that assumption
holds in future or we don't know if there are other platforms that
strictly assume the RFC4291 format but yet implement the IP-over-OCB
spec.  We should either make IP-over-OCB compliant/consistent with
existing standards, or make it clear that IP-over-OCB makes an
exception to the existing standards by formally updating the latter.
That's, in my understanding, what a responsible spec author of an IETF
document is supposed to do, especially if they really respect the
concept of interoperability.  And that's the point of my very first
message in this entire int-dir thread.

Frankly, I'm surprised to hear that an author of a would-be standards

> along the lines of BSD which does not accept fe80:1::1 in the first place?

To me, this sounds like the author saying they don't care about
interoperabitlity beyond the platforms they are interested in.

--
JINMEI, Tatuya

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 17 Apr 2019 12:03:04 -0400

Your earlier text included the line:

"A MAC address SHOULD be of length 48 decimal."

Even if the SHOULD were not capitalized, that would look like an effort 
in this document to specify the length of a MAC address.  With the 
capitalization, it appears even more strongly to be such an effort.

One of your suggestions removed that text, which would be a good way to 
resolve this problem.  Eric's question is based on the text you sent, 
which is taken directly from the document.

Yours,
Joel

On 4/17/19 10:29 AM, Alexandre Petrescu wrote:
>> Cc: <[email-masked]> <[email-masked]>; IETF Discussion 
>> <[email-masked]>; [email-masked]; 
>> reference to what the other documents are or how to find them seems 
>> like a recipe for implementor error.  Can we be somewhat more specific?
>>
>> Thank you,
>> Joel
>>
>

---

From: 神明達哉 <[email-masked]>
Date: Wed, 17 Apr 2019 13:40:41 -0700

At Wed, 17 Apr 2019 16:08:22 +0200,

> > reference to what the other documents are or how to find them seems
like
> >       A randomized Interface ID has the same characteristics of a

In the context of the "Privacy Considerations" section, that's
probably good enough.  After all, the privacy implication of the
IID length doesn't seem to be specific to IPv6-over-COB.

But, in the context of stateless address configuration, the length
must be unambiguously specified since RFC4862 assumes it's specified
in each IPv6-over-foo specification, and without knowing this exact
length it's nearly impossible to develop an interoperable
implementation regarding SLAAC for that IPv6-over-COB.

To this end I've checked Section 4.4 (of rev 42) and found it not very
clear.  The most relevant text seems to be this one:

   The Interface Identifier for an 802.11-OCB interface is formed using
   the same rules as the Interface Identifier for an Ethernet interface;

but it's not clear if it means the same IID length as that for
Ethernet, i.e., 64 bits, especially because the draft previously
mentioned 118 bits of IID (for link-local addresses) and now (rev 42)
leaves the length to "other documents".

While stateless address autoconfiguration (RFC4862) specifies
link-specific IPv6-over-foo docs as the primary source of this
information, it's also based on the assumption that it's consistent
with the address architecture:

   interface identifier -  [...] The
      exact length of an interface identifier and the way it is created
      is defined in a separate link-type specific document that covers
      issues related to the transmission of IP over a particular link
      type (e.g., [RFC2464]).  Note that the address architecture
      [RFC4291] also defines the length of the interface identifiers for
      some set of addresses, but the two sets of definitions must be
      consistent.

so, as of today, it cannot be other value than 64 bits unless this
document makes an exception for IPv6-over-OCB by formally updating
RFC4291 so that IPv6-over-OCB and the (updated) address architecture
will still be consistent.

Now, from the discussion so far, I'm feeling the sense of a desire for
IPv6-over-OCB to use other values of IID length than 64 bits.  Perhaps
that's one background reason why this is left not so explicit.  But
since the value of IIDs is so important for the interoperability of
SLAAC, I don't think we can leave it obscure.  Whether it's in this
document or "other documents", it must be explicitly specified.  And
if it's in "other documents", it must already exist or must have been
published no later than this document.  And, if it's something other
than the status quo (i.e. 64 bits), it must formally update RFC4291
(and, needless to say, this will be extremely challenging - recall how
rfc4291bis is half-dead in limbo due to this exact debate).

If IPv6-over-OCB can live with the status quo at least for now, that
will be the easiest and fastest way forward.  If IPv6-over-OCB people
don't like to make another precedent of the use of the constant value
of 64, it might explicitly note that the appropriate length of IIDs
has been subject to hot debates and may become more flexible in
future.

To be clear: I'm not making any opinion on whether the hard fixed
value of 64 is good or bad.  I'm just pointing out procedural
constraints.

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 18 Apr 2019 09:55:52 +1200

Hi Alexandre,
> into the IPWAVE Problem Statement draft?

My understanding now is that the IP-over-OCB draft is scoped only for
single-link subnets (i.e. does not even try to cover the case of
hidden nodes). I think that needs to be stated very clearly, and
I don't quite understand whether there is a non-link-local prefix
at all. In a very fluid network situation, it isn't at all obvious
that a useful non-link-local prefix can be established. The draft
seems a bit ambiguous on that point, so perhaps that can also be
clarified.

Given those changes, I agree that moving the appendix as you
suggest would be reasonable.

By the way, where you use the word "global" to describe IPv6
addresses or prefixes, I suggest using either "Globally Reachable"
(as defined in RFC8190) or "global unicast" as defined in RFC8200.
ULA != globally reachable.
ULA == global unicast

Regards
    Brian

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 18 Apr 2019 04:43:01 +0200

> all difficult to understand, but it is very important to understand.

Yes but it has been reduced its effects of collisions by CSMA/CA, and by
using control frames,

> > start looking into it I will grow additional white hairs.  I feel like I

usually it is the IEEE problem to solve not this WG problem. I believe they
solved it.

> > problem in non-OCB WiFi and 802.15.4.  I am listening to them.

usually MIMO technology has change many issues, but 802.15.4 is big
different MAC than 802.11,

> I find this very surprising!  What do others think?

I think usually this hidden terminal is old problem now IEEE802.11 has been
updated, solving many old problems including that. It is called now hidden
station in IEEE802.11 new docs. In old sunets and terminals they have no
intelligence but now the stations are smart especially when it is a Car not
a sensor, because a Car has big storage and power capabilities that can
help to increase intelligence and decision making.

AB

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 18 Apr 2019 05:08:03 +0200

> term V2VRU: Vehicle to VRU.

two V in V2VRU with different meanings and many symbols may confuse new
users, as V2V both V same meaning. I hope we make it three symbols as V2V,
V2X,..

> 1.5ms OCB).  In safety, lower latency is preferred over higher latency.

that is important,

> draft, section 3 "Use Cases".

I agree,

> BSM and/or other V2X message.

Agree,

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 18 Apr 2019 04:25:55 +0200

Hi Charlie,

On Mon, Apr 15, 2019 at 4:17 PM Charlie Perkins <
[email-masked]> wrote:

>    - RFC 8505 isn't just about low power.
>
> The titles says that, so the authors said that and including the IETF
WG that published and examined it under such use cases.

>    - More to the point in this discussion, it's about reducing
>    interference by reducing the number of multicasts needed in a multilink
>    subnet.
>
> IMHO, there are differences when we have multilinks of low-power of short
range, and multilinks of high-power long range.

>
>    - Please note that I am neither discouraging nor advocating the use of
>    RFC 8505 for v6-over-OCB, but I think it would be better to avoid
>    suggesting that it is only useful for low-power mesh.
>
> I think it is better we focus discussion on one doc not two

>
>    -
>    - Even if you did have four cars to run experiments, the results could
>    hardly be considered conclusive.  Simulation can be very helpful in such
>    circumstances.  You know the velocities and the range of the signal. You
>    have many many thousands of easily accessible real-world topologies, and
>    even the interference characteristics.
>
> the 4G coverage is doing ok in connecting Cars in high velocity with
 interference, so we can get connectivity between V2X in transportation
environment.

>
>    -
>    - I made a quick scan of the draft and found this: "All nodes in the
>    subnet MUST be able to communicate directly using their link-local unicast
>    addresses.".  Does this mean that the solution is not applicable for
>    topologies exhibiting the hidden terminal problem?  Or, does "directly"
>    mean something else?
>
> No the topology includes hidden stations, but stations are using collision
avoidance so it is ok.

>
>    -
>
> I think the draft could benefit from a very clear applicability statement,
> specifically including the projected number of vehicles in the subnet.
>
The number of the subnet is changeable, but I expect it to be depending on
the MAC technology  CSMA/CA and frequency band/channels. Why you want to
discuss the numbers while many RFCs don't do that. The subnetwork or
OBU-number is not the issue in this draft, but the IPv6 over V2X-OCB.

>   If every vehicle on the subnet can expect deliver of multicast packets
> to every other vehicle on the subnet, then the problem is different than if
> hidden terminal effects occur or if multicast is unreliable for some other
> reason.
>
Yes it does expect, but it is seeking mostly service not neighbour
discovery, so if not delivered for some reason then it can get service from
others,

> Maybe for clarity it would be helpful to include a diagram of a general
> target network with more than three or four vehicles.
>
ok

> carefully read the draft.
no problem, thanks for your discussion,

AB

> What is difficult to try is to reproduce the ND-over-OCB problem imagined
> by Pascal.  It is difficult to try because it involves 4 cars (I dont have
> that many).  It  is also difficult to try because it seems to miss the fact
> that OCB can do high power.  Maybe that high power solves the problems that
> appear in ND over low power.
>
> On Sun, Apr 14, 2019, 00:06 Sri Gundavelli (sgundave) <[email-masked]
> <mailto:[email-masked]> <[email-masked]>> wrote:
>
> [email-masked] <mailto:[email-masked]>
> <[email-masked]>>
>       wrote:
>
> address
> but has

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 18 Apr 2019 10:20:55 +0200

Le 18/04/2019 à 04:43, Abdussalam Baryun a écrit :
> 
> 
> On Tue, Apr 16, 2019 at 5:50 PM Charlie Perkins 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
> 
>     Hello Alex,
> 

Is OCB using CSMA/CA?
Is the OFDM that I see in OCB packet dumps an alternative to CSMA/CA?
Is OFDM solving the hidden terminal problem?

In OCB there are no control frames; so the absence of the control frames 
can not help with the hidden terminal problem - on the contrary, it may 
worsen it.

> usually it is the IEEE problem to solve not this WG problem. I believe 
> they solved it.

IT's good to know if it were that way.

I agree.

> I think usually this hidden terminal is old problem now IEEE802.11 has 
> been updated, solving many old problems including that. It is called now 
> hidden station in IEEE802.11 new docs. In old sunets and terminals they 
> have no intelligence but now the stations are smart especially when it 
> is a Car not a sensor, because a Car has big storage and power 
> capabilities that can help to increase intelligence and decision making.

I think both points are worth mentioning: (1) 802.11 new docs 
(presumably year 2016) do have solutions for hidden station problem and 
(2) car may have more computing capability than a small temperature 
sensor and hence may use it to alleviate the hidden station problem.

I think there is much that can be put together about this.

Pascal described an A-B-C-D problem.
Charles described an A-B-C hidden terminal problem.
I described a hidden car problem.
You mention the IEEE hidden station problem and the IEEE 802.11 new 
solutions to it.

It makes for a beautiful section "Hidden-icity Problems" (sorry I dont 
know a good term about Hidden).

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 18 Apr 2019 13:47:53 +0200

Le 17/04/2019 à 17:20, 神明達哉 a écrit :
>  > >  > [...]> Note also that MacOS is derived from BSD in case you don't
>  > >  > > remember/know it.  And, in fact it also generates both 
> "fe80::1" and
>  > >  > > "::1" on the "lo0" interface.
>  > >  >
>  > >  > Right, I forgot that.
>  > >  >
>  > >  > But there is something I never knew for sure.
>  > >  >
>  > >  > Are BSD flavors supporting OCB options?
>  > >
> spec.

Right, we may expect a future platform to stricly abide to RFC4291, and 
implement OCB too.

For now, we know that linux supports OCB and fe80:1::1.  My trial with 
multiple single-link subnets uses fe80:1::/32, fe80:2::/32 and 
fe80:3::/32.  They are all on linux-based openwrt.

I would like this to interoperate with others and in the future too.

> We should either make IP-over-OCB compliant/consistent with

I am interested in interoperability.

I would like to test linux talk to BSD in OCB mode.

The first thing that blocks is lack of OCB support in BSD.  After that 
is fixed we can talk fe80:1::1 in BSD.

Another first thing that blocks is that I do not know how to make an 
"Update: 4291" statement on the first page of this document.

Also, the AD suggestion is to stay silent about plen like 64 or 118 or 
so, and deal with this elsewhere.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 18 Apr 2019 13:57:33 +0200

> which is taken directly from the document.

Understood. I will remove the phrase telling MAC SHOULD be 48.

(one remark though.  Some Windows people call a MAC address something 
else than what IEEE defines to be a MAC address.  For example, they 
create a MAC identifier that has nothing to do with an interface; that 
is unique across all Microsoft machines; it is useful for new devices 
like my new tablet having no RJ45 but tracked by my IT dept by a MAC 
address and disallowed to use WiFi; I forgot the name of that MAC 
address; it is called 'MAC something address'; it may be visible in 
BIOS; it is 48bit length).

Alex

>> We are attempting to define how long a better privacy Interface ID 
>> (not MAC) should be.
>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 18 Apr 2019 14:05:27 +0200

Le 17/04/2019 à 22:40, 神明達哉 a écrit :
> At Wed, 17 Apr 2019 16:08:22 +0200, Alexandre Petrescu
>> individual work item (not a WG item) in 6man that one could point
>> to.  A reference to a non WG item will not delay this document?
>> 
> probably good enough.  After all, the privacy implication of the IID
> length doesn't seem to be specific to IPv6-over-COB.
> 
> To this end I've checked Section 4.4 (of rev 42) and found it not
> very clear.  The most relevant text seems to be this one:
> 
> mentioned 118 bits of IID (for link-local addresses) and now (rev
> 42) leaves the length to "other documents".
> 
> interface identifier -  [...] The exact length of an interface
> identifier and the way it is created is defined in a separate
> link-type specific document that covers issues related to the
> transmission of IP over a particular link type (e.g., [RFC2464]).
> Note that the address architecture [RFC4291] also defines the length
> of the interface identifiers for some set of addresses, but the two
> sets of definitions must be consistent.
> 
> Now, from the discussion so far, I'm feeling the sense of a desire
> for IPv6-over-OCB to use other values of IID length than 64 bits.

The desire comes from my deployment of linux on 3 single-link subnets
needing fe80:1::1 (linux has no zone id, but supports fe80::/32).

I am not sure about the others.

> Perhaps that's one background reason why this is left not so
> explicit.  But since the value of IIDs is so important for the
> interoperability of SLAAC, I don't think we can leave it obscure.
> Whether it's in this document or "other documents", it must be
> explicitly specified.  And if it's in "other documents", it must
> already exist or must have been published no later than this
> document.  And, if it's something other than the status quo (i.e. 64
> bits), it must formally update RFC4291 (and, needless to say, this
> will be extremely challenging - recall how rfc4291bis is half-dead in
> limbo due to this exact debate).

I have two distinct LL addresses on an interface: one that is 
complicated (fe80::IID/64) and one that is easy to remember and type 
(fe80:1::/32).

"The other documents" is something that could be done in 6MAN WG.  If 
they agree.  That is a big IF.

I want this IP-over-OCB document to progress and to reflect reality as 
much as possible.

> will be the easiest and fastest way forward.  If IPv6-over-OCB
> people don't like to make another precedent of the use of the
> constant value of 64, it might explicitly note that the appropriate
> length of IIDs has been subject to hot debates and may become more
> flexible in future.

May it?

> value of 64 is good or bad.  I'm just pointing out procedural 

Ok.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 18 Apr 2019 14:23:08 +0200

Le 17/04/2019 à 23:55, Brian E Carpenter a écrit :
> Hi Alexandre, On 17-Apr-19 21:41, Alexandre Petrescu wrote:
>> Brian,
>> 
>> Le 16/04/2019 à 04:18, Brian E Carpenter a écrit : [...]
>> I would like to ask you whether you disagree that we move the 
>> appendix titled "ND issues in wireless links" away from the 
>> IP-over-OCB draft into the IPWAVE Problem Statement draft?
> 
> hidden nodes). I think that needs to be stated very clearly,

I propose this text in the Subnet Structure section of IP-over-OCB draft:
NEW:
> The subnet structure on which the Neighbor Discovery protocol (ND)
> on OCB works ok is a single-link subnet; the status of ND operation
> on a subnet that covers multiple OCB links that repeat the signal at
> PHY layer, or the messages at MAC layer, is unknown.

[...]

> and I don't quite understand whether there is a non-link-local prefix
> at all.

In my network of 3 cars no, there is no non-LL prefix at all between cars.

In my deployment of 2 cars and an IP-RSU IPv6 4G NAT66 NEMOv6 there was
a ULA prefix between the RSU and the car, on OCB.  In year 2015.

> In a very fluid network situation, it isn't at all obvious that a
> useful non-link-local prefix can be established.

I agree.

The problem is probably less in the fluidity, than in determining authority.

When there is an RSU one may associate authority to RSU that got it from
Cellular Operator who got it from the Default FRee Zone; but absent RSU
who should be trusted as authority?

It is the same problem when we try to make security between several cars
in a convoy.  We try to use quickly the OpenVPN software to achieve
security, but who's the client who's the server?  Cars are created
equal.  They are equally safe, even though some are more expensive than 
others.  We may end up with two openvpn tunnels between two cars, when 
one is normally sufficient.

> The draft seems a bit ambiguous on that point, so perhaps that can
> also be clarified.

YEs, could be, in the Problem Statement draft.

> Given those changes, I agree that moving the appendix as you suggest 
> would be reasonable.
> 
> ULA != globally reachable. ULA == global unicast

Noted.

Alex

---

From: 神明達哉 <[email-masked]>
Date: Thu, 18 Apr 2019 10:14:26 -0700

At Thu, 18 Apr 2019 14:05:27 +0200,

> I am not sure about the others.

If it's only about the convenience of your specific implementation,
I'd say it's quite weak as a reason for including it in the generic
IPv6-over-OCB specification, despite the cost of updating a change to
a 24-year standard (since RFC1884).

Unless this is something that the pure protocol nature of
IPv6-over-COB requires (which I don't know due to my lack of
full understanding), I personally suggest this specification stick to
the current status quo, i.e., 64-bit IID length, so that new
developers can develop interoperable implementations without
ambiguity.  At the very least, this approach doesn't impose any new
procedural bar and will help publish it sooner.

Separately, if you believe your cause is strong enough to change the
current standard, you can try it at 6man so a non-0 value in the
intermediate 54-bit field can be validly used.  IPv6-over-COB can be
subsequently updated to reflect that.

But, if you (WG) don't like IPv6-over-COB to be published in an
incompatible way with your own implementation for now, I don't see
other options than hold off until the separate effort at 6man is
completed.

Whether the delay due to that and the uncertainty of its success are
acceptable for IPv6-over-COB is totally up to the WG.  I have my own
personal suggestion as stated above, but it's quite possible that the
WG prefers a different option.  My bottom line is that the IPv6-over-COB
can't ship with obscuring the IID length.

--
JINMEI, Tatuya

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 18 Apr 2019 22:32:27 +0200

Le 18/04/2019 à 19:14, 神明達哉 a écrit :
> full understanding),

fe80:1::1 is not something in the pure nature of IPv6-over-OCB.

It is something I designed in the addressing architecture for convoy. 
It is implemented with the vanilla linux IP stack on top of OCB MAC and 
PHY.  The implementation is like this: ifconfig eth0 add fe80:1::1.

> I personally suggest this specification stick to

This is your recommendatio, but not the recommendation from AD.  The 
recommendation from AD, if I understand it correctly, is to stay silent 
about this, and get the IID length through 6man.

With respect to your recommendation: why do you recommend to respect the 
54 0 bits in RFC4291 when these bits are only implemented in BSD, and 
BSD does not implement OCB?  Is this recommendation appropriate?

> subsequently updated to reflect that.

YEs, let us try that.

I would like to ask you: would you support such a proposal in 6man?

OR are you redirecting me there in the hope 6man will discard my 
proposal and I come back to your initial suggestion?
(the ping pong effect)

> other options than hold off until the separate effort at 6man is

Again, if IPv6-over-OCB says fe80:1::/32 is ok it is ok with linux.

You talk about some unknown implementation (BSD) which does not 
implement OCB at all.

(I do know BSD is a widespread OS and largely used elsewhere, but it has 
no OCB support; I also know it is probably the first IPv6 implementation 
in BSD).

> can't ship with obscuring the IID length.

Let us unobscure it through 6man.

If you think you will not support this unobscuring in 6man (make 54bits 
non-zero), then I think your advice is very misleading.  It is not good 
to listen to such advice that leads to ping pong effect.

Alex

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 19 Apr 2019 09:01:13 +1200

>> PHY layer, or the messages at MAC layer, is unknown.

OK. We could argue whether it should be "unknown" or "undefined"
but I think this is a useful clarification, thanks.

OK
  Brian

---

From: 神明達哉 <[email-masked]>
Date: Thu, 18 Apr 2019 14:34:28 -0700

At Thu, 18 Apr 2019 22:32:27 +0200,

This is a verbatim copy of Shresh's word:

>> I would like to look at this from a different angle. It is clear from
the current standards that you need to be using fe80::/64 to form the LL
address as the IPv6 address architecture requires the IID to be 64 bits
long (for non b000 prefixes) and SLAAC requires the prefix and the IID
lengths to add up to 128. If you want this changed, I don’t think this is
the document where you should do it. The *burden of proof is on you* to
show why the status quo does not work in this case and IMHO it has not been
meet.

>> I would request that you keep the link-local prefix length discussion
out of this draft, and in 6man where it belongs. Here is the thread that
you started in January this year in 6man

It actually seems to be essentially the same as my own personal
suggestion: I would interpret it as: "you should use fe80::/64
according to the current standard; if you want to change it, bring it
to 6man", no?

But yes, it's still just my personal suggestion, and I'm not even an
assigned int-dir reviewer, let alone an AD.  I don't have any power
(or intent) to dictate which approach this draft must take in the end.
It's ultimately up to you and the WG.  I believe I was clear about
that in my previous message.

I still made this suggestion, since if the length of IID is kept
ambiguous I'd certainly raise the same point if and when it reaches an
IETF last call, as a co-author of RFC4862.  But if you'd rather defer
the discussion until that point, please feel free to ignore it in this
thread; I'm already feeling quite guilty about "stealing" a thread
started by a draft review by another int-dir member.

> I would like to ask you: would you support such a proposal in 6man?

Right now, I'm not convinced.  But I'm open to discussion.  That's why
I asked you to write a draft with the proposal and with detailed
explanation of why it needs to change.  Once I understand it I may or
may not support it.  So,

> proposal and I come back to your initial suggestion?

of course not.  But I expect your proposal will be quite controversial
and take a long time.  I also admit I *expect* its odds are low and it's
quite possible that you end up falling back to the status quo;
changing a long standing standard is always hard.  But that doesn't
mean I *hope* it will fail (also, my expectation can prove incorrect).

--
JINMEI, Tatuya

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 18 Apr 2019 23:44:54 +0200

Le 18/04/2019 à 23:34, 神明達哉 a écrit :
>  >> I would like to look at this from a different angle. It is clear 
> from the current standards that you need to be using fe80::/64 to form 
> the LL address as the IPv6 address architecture requires the IID to be 
> 64 bits long (for non b000 prefixes) and SLAAC requires the prefix and 
> the IID lengths to add up to 128. If you want this changed, I don’t 
> think this is the document where you should do it. The *burden of proof 
> is on you* to show why the status quo does not work in this case and 
> IMHO it has not been meet.
> 
>  >> I would request that you keep the link-local prefix length 
> discussion out of this draft, and in 6man where it belongs. Here is the 
> thread that you started in January this year in 6man
> 

No.  HE first says what he thinks as a participant (he thinks 64 is the 
rule).  Then he becomes AD and says that if I want that changed it is 
not in OCB document, but in 6man WG.

> started by a draft review by another int-dir member.

The IID len is ambiguous now in IP-over-OCB draft.
The IID len should be fixed quickly in 6man.  They cant delay this 
IP-over-OCB document with infinite discussions.

> mean I *hope* it will fail (also, my expectation can prove incorrect).

This is a structural problem.

If you direct us to 6MAN and know and assume the variable len IID gets 
stuck there then you should not direct as there.

Alex

---

From: 神明達哉 <[email-masked]>
Date: Thu, 18 Apr 2019 14:56:15 -0700

At Thu, 18 Apr 2019 23:44:54 +0200,

> stuck there then you should not direct as there.

Actually, that's exactly why my primary suggestion is to stick to the
status quo for now.  Changing the status quo needs a discussion at
6man, and it will take long time and can possibly fail, so if you want
to avoid the delay, the only feasible option for now is to stick to
the status quo and defer any incremental changes to that separate
discussion.  Hence the suggestion.  I believe I've always been clear
about it, hiding nothing.

And it's now your call.  If you don't like to go with the status quo
for now and do believe you can get a quick consensus at 6man, I just
wish you a good luck.

--
JINMEI, Tatuya

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 19 Apr 2019 00:10:21 -0400

Hi Alex,

> On Apr 18, 2019, at 5:44 PM, Alexandre Petrescu <[email-masked]> wrote:
> 
> 
> 
> No.  HE first says what he thinks as a participant (he thinks 64 is the rule).  Then he becomes AD and says that if I want that changed it is not in OCB document, but in 6man WG.

The view I expressed earlier is the same Jinmei-san is expressing above. Not sure where you see a disconnect when you respond with a “No”. The right forum for discussion is 6man. As I said before, keep this non-64 discussion off the OCB document.

> The IID len should be fixed quickly in 6man.  They cant delay this IP-over-OCB document with infinite discussions.

Use 64 in this document and it will be compliant to current standards. If you want it changed, make your case in 6man to get it changed.

> If you direct us to 6MAN and know and assume the variable len IID gets stuck there then you should not direct as there.

6man is the venue for this discussion. If nobody else shares your view (which is what I see) your document will get stuck. That *does not* mean you can use your position as the editor of the OCB document to insert your view of the IID length here.

Thanks
Suresh

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 19 Apr 2019 10:51:03 +0200

> for now and do believe you can get a quick consensus at 6man, I just

The status quo is the following: the IP-over-OCB does not specify the 
len of  IID.  It refers to "other documents".

If we go to 6man is to get 6man consensus and quickly.  Otherwise we 
dont go there.

If you, or the AD think we could not get consensus there, then you, or 
the AD, should not direct us there.

We could stay here and write IID len is 118.  At that point it should be 
6man who should come here and see whether 6man gets consensus here.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 19 Apr 2019 11:05:34 +0200

Le 19/04/2019 à 06:10, Suresh Krishnan a écrit :
>>> At Thu, 18 Apr 2019 22:32:27 +0200, Alexandre Petrescu 
>>>>> I personally suggest this specification stick to the current
>>>>>  status quo, i.e., 64-bit IID length, so that new developers
>>>>>  can develop interoperable implementations without ambiguity.
>>>>>  At the very least, this approach doesn't impose any new 
>>>> This is your recommendatio, but not the recommendation from AD.
>>>> The recommendation from AD, if I understand it correctly, is to
>>>> stay silent about this, and get the IID length through 6man.
>>>>> I would like to look at this from a different angle. It is 
>>>>> clear from the current standards that you need to be using 
>>>>> fe80::/64 to form the LL address as the IPv6 address 
>>>>> architecture requires the IID to be 64 bits long (for non 
>>>>> b000 prefixes) and SLAAC requires the prefix and the IID 
>>>>> lengths to add up to 128. If you want this changed, I don’t 
>>>>> think this is the document where you should do it. The 
>>>>> *burden of proof is on you* to show why the status quo does 
>>>>> not work in this case and IMHO it has not been meet. I would
>>>>>  request that you keep the link-local prefix length 
>>>>> discussion out of this draft, and in 6man where it belongs. 
>>>>> Here is the thread that you started in January this year in 
>>>>> 6man 
and the associated draft
> architectural change.>>> It actually seems to be essentially the same
> as my own personal
>>> according to the current standard; if you want to change it, 
>>> bring it to 6man", no?
>> 
>> No.  HE first says what he thinks as a participant (he thinks 64 is
>> the rule).  Then he becomes AD and says that if I want that changed
>> it is not in OCB document, but in 6man WG.
> 
> The view I expressed earlier is the same Jinmei-san is expressing 
> above. Not sure where you see a disconnect when you respond with a 
> “No”. The right forum for discussion is 6man. As I said before, keep
>  this non-64 discussion off the OCB document.

Ok.  The status quo is the following: the IPv6-over-OCB does not specify
the IID len.  It refers to "other documents".  I published a document in
6MAN WG, that could be qualified as "other documents".

But please allow me to ask you: do you understand there is a sense of
urgency in publishing this IPv6-over-OCB draft?  Indeed we must take the
necessary time to make it right, but there is also urgency.

It has been several years in the making; deployments are ready as we
speak (at least 3 RSUs with IPv6-over-OCB that I am aware of on the
road, two which are my work with partners, and one that is entirely out
of my control).  In a trial demonstrator running on closed track for
several months the IID len 118 was used for V2V, in addition to the LL
64bit len.

>>> But yes, it's still just my personal suggestion, and I'm not even
>>> an assigned int-dir reviewer, let alone an AD.  I don't have any
>>> power (or intent) to dictate which approach this draft must take
>>> in the end. It's ultimately up to you and the WG.  I believe I
>>> was clear about that in my previous message. I still made this 
>>> suggestion, since if the length of IID is kept ambiguous I'd 
>>> certainly raise the same point if and when it reaches an IETF 
>>> last call, as a co-author of RFC4862.  But if you'd rather defer 
>>> the discussion until that point, please feel free to ignore it in
>>> this thread; I'm already feeling quite guilty about "stealing" a
>>> thread started by a draft review by another int-dir member.
>> 
>> The IID len is ambiguous now in IP-over-OCB draft. The IID len 
>> should be fixed quickly in 6man.  They cant delay this IP-over-OCB
>>  document with infinite discussions.
> 
> Use 64 in this document and it will be compliant to current 
> standards.

If you ask me, the answer is this: No, I will not write '64' in this
document.

As you can see this is a breaking point in the making.  I would like to
inform you that if this breaks, I will retire my name from the draft.

> If you want it changed, make your case in 6man to get it changed.

YEs.  Following your recommendation, I started to do that.  I need
support for the draft I published in the 6man WG.  I need support from
co-authors, from Area Director and from key knowledgeable people in the
IPv6 field.

>>>>> Separately, if you believe your cause is strong enough to 
>>>>> change the current standard, you can try it at 6man so a 
>>>>> non-0 value in the intermediate 54-bit field can be validly 
>>>>> used.  IPv6-over-COB can be subsequently updated to reflect 
>>>>> that.
>>>> YEs, let us try that. I would like to ask you: would you 
>>>> support such a proposal in 6man?
>>> Right now, I'm not convinced.  But I'm open to discussion.
>>> That's why I asked you to write a draft with the proposal and
>>> with detailed explanation of why it needs to change.  Once I 
>>> understand it I may or may not support it.  So,
>>>> OR are you redirecting me there in the hope 6man will discard 
>>>> my proposal and I come back to your initial suggestion? (the 
>>>> ping pong effect)
>>> of course not.  But I expect your proposal will be quite 
>>> controversial and take a long time.  I also admit I *expect* its
>>>  odds are low and it's quite possible that you end up falling 
>>> back to the status quo; changing a long standing standard is 
>>> always hard.  But that doesn't mean I *hope* it will fail (also, 
>>> my expectation can prove incorrect).
>> 
>> If you direct us to 6MAN and know and assume the variable len IID 
>> gets stuck there then you should not direct as there.
> 
> 6man is the venue for this discussion. If nobody else shares your 
> view (which is what I see) your document will get stuck.

Suresh, with all due respect.

Please read the 6man emails with an open mind.

Please see that along the years there was support in 6man from several
people about a variable length IID, including for link-local addresses.
  There was indeed also pushback, but there was also support.

> That *does not* mean you can use your position as the editor of the 
> OCB document to insert your view of the IID length here.

Indeed.

Please note the  following: I am not an Editor.  I purposefully did not
put 'Ed.' next to my name.  I am the main contributor.

The document belongs to the WG.

If the tendency is to write '64' in this document then I will retire my
name from it.

(it is a common practice for people to not accept to put their names on
something they dont agree with; some times people indulge themselves in
letting their names on some draft to which they dont really agree
entirely, other times they refrain).

Alex

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 19 Apr 2019 12:26:44 +0200

> > Yes but it has been reduced its effects of collisions by CSMA/CA, and by

Yes,

> Is the OFDM that I see in OCB packet dumps an alternative to CSMA/CA?

one in PHY layer and the other protocol in MAC layer,

> Is OFDM solving the hidden terminal problem?

Yes when using MIMO and multi directional antennas, but some only think in
Omni-directional antenna use cases, and they think only in SISO use cases.

> can not help with the hidden terminal problem - on the contrary, it may

In all cases of IEEE802.11 and application there are management messages
and control messages and data messages, so Do you say there is no Control
messages and no Management messages in OCB use cases, I disagree,

IMHO, it is ok to configure OCB with RTS/CTS and poll technique to solve
some applications services needed.

AB

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 19 Apr 2019 14:08:28 +0200

Le 19/04/2019 à 12:26, Abdussalam Baryun a écrit :
> 
> 
> On Thu, Apr 18, 2019 at 10:21 AM Alexandre Petrescu 
>      > <[email-masked]
>     <mailto:[email-masked]>
>     <mailto:[email-masked]
>     <mailto:[email-masked]>>>
>      > wrote:
>      >
>      >     Hello Alex,
>      >

I did not know that.  I thought CSMA, CDMA, WCDMA and OFDM are 
alternatives.  Something like this: Ethernet uses CSMA, CDMA phones use 
CDMA, WCDMA phones use WCDMA, and 802.11a uses OFDM.

So I learn OCB uses CSMA/CA and OFDM.

Ok.

Just to let you know that my packet analyser wireshark talks only about 
OFDM at PHY layer, but it says nothing about CSMA/CA at the MAC layer; 
(the RadioTap Header (presumably PHY) displays Channel flags set to 
0x4140, meaning ÓFDM, 5GHz, half rate 10MHz; the LLC header and the 
802.11 QoS Data header (presumably MAC) dont say 'CSMA/CA' - but maybe 
it is there but I dont know it).

> Yes when using MIMO and multi directional antennas, but some only think 
> in Omni-directional antenna use cases, and they think only in SISO use 
> cases.

In my deployments I typically put MIMO antennas in the IP-RSU (multiple 
groups of MIMO antennas) and MIMO antennas (one group) on top of the 
car; for V2V I put just one antenna (no MIMO) in front bumper and one in 
rear bumper, but it can grow to more if bigger car.

Before putting these MIMO things we had many reliability problems.

What is SISO?

> and control messages and data messages, so Do you say there is no 
> Control messages and no Management messages in OCB use cases,

Yes, I say so.  Most devices I listened to have no control messages at 
all in 802.11 in OCB mode.  I dont receive them.  Some few old RSUs 
beacon 'Probe Request' with en empty ESSID.  'Empty' means that the 
programmer writes something like s/he thinks like empty: some write 
'empty', italians write 'assente' (for 'absent') and so on.  So there 
can be an empty ESSID in these old RSUs, to respect the standard.

> I disagree,

I dont know why you disagree, but I dont disagree with you.

> some applications services needed.

I dont know what is OCB with RTS/CTS and poll technique.  IS there a way 
I can try that in practice?  Maybe an 'iw' command?

Which applications/services may benefit from OCB with RTS/CTS and poll 
technique?

Alex

>      >      > ...
>      >      > I do not know how the hidden terminal problem works.  I
>     feel like
>      >     if I
>      >      > start looking into it I will grow additional white hairs. 
>     I feel
>      >     like I
>      >      > better avoid  it.
>      >
>      >
>      >      > I think other people have some experience with the hidden
>     terminal
>      >      > problem in non-OCB WiFi and 802.15.4.  I am listening to them.
>      >
>      >
>      >      > I think nobody has any experience with the hidden terminal
>     problem in
>      >      > OCB settings.  I have some doubts, but still I think it is
>     almost
>      >     nobody.
>      >      >
>      >      >

---

From: 神明達哉 <[email-masked]>
Date: Fri, 19 Apr 2019 07:42:20 -0700

At Fri, 19 Apr 2019 10:51:03 +0200,

> the AD, should not direct us there.

I didn't think you can never get consensus there, but I was pretty
sure that it would be hard and take long time and can even fail.  I
already emphasized these several times, and only suggested you go there
if you still think you want the change.  Perhaps you interpreted it as
if you just go to 6man you can quickly get an approval of whatever you
want.  If so, sorry, I probably still didn't emphasize the point enough.  I
guess it was beyond my writing ability to clarify it further, though.

It looks like you're determined to only get a quick agreement on
sticking to the IID len of 118, reusing to consider any other option
for any reason or for any discussion results at 6man.  At this point I
think we have to agree to disagree, then.  If you believe that
approach survives the AD evaluation and subsequent IETF last call and
the IESG ballot, go ahead.  I have no power to stop it.  All I can and
will do is to raise the point that it violates RFC4291 and can't be
published without updating 4291 at the time of the IETF last call, if
this doc ever reaches there.

--
JINMEI, Tatuya

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 19 Apr 2019 16:56:37 +0200

Tatuya,

Thank you very much.

See below.

Le 19/04/2019 à 16:42, 神明達哉 a écrit :
> At Fri, 19 Apr 2019 10:51:03 +0200, Alexandre Petrescu
>>> Actually, that's exactly why my primary suggestion is to stick to
>>> the status quo for now.  Changing the status quo needs a
>>> discussion at 6man, and it will take long time and can possibly
>>> fail, so if you want to avoid the delay, the only feasible option
>>> for now is to stick to the status quo and defer any incremental
>>> changes to that separate discussion.  Hence the suggestion.  I
>>> believe I've always been clear about it, hiding nothing.
>>> 
>>> And it's now your call.  If you don't like to go with the status
>>> quo for now and do believe you can get a quick consensus at 6man,
>>> I just wish you a good luck.
>> 
>> The status quo is the following: the IP-over-OCB does not specify
>> the len of  IID.  It refers to "other documents".
>> 
>> If we go to 6man is to get 6man consensus and quickly.  Otherwise
>> we dont go there.
>> 
>> If you, or the AD think we could not get consensus there, then you,
>> or the AD, should not direct us there.
> 
> already emphasized these several times, and only suggested you go
> there if you still think you want the change.  Perhaps you
> interpreted it as if you just go to 6man you can quickly get an
> approval of whatever you want.

To clarify: no, I did not interpret it as getting a quick approval from
6MAN.  Actually I know very well 6MAN backfires very strongly.  It is
the case with ND and with IID len now.

6MAN provided ND reviews a couple of times last year; each time I did my
best to address them.  It seemed as a solved issue.  Then other reviews
came in, and again ND, as if nothing was done before.

It is as if it was not 6MAN who originally redirected this IP-over-OCB
work to create another WG.

Now I understand better what happened a few years ago: actually 6MAN
wanted us to actually stop working on this; they did not ask us to
create a WG and solve it.  They just wanted that we should not do this.

The same happens now: 6MAN is not asking me to solve some problem with
this IID length - they just want this IID len work to stop.

In a sense, I agree with 6MAN that wants to slow down some too fast
evolutions of a protocol that is not deployed as expected.  In another
sense, it is difficult to keep a WG alive without any new work.

> If so, sorry, I probably still didn't emphasize the point enough.  I 
> for any reason or for any discussion results at 6man.  At this point
> I think we have to agree to disagree, then.

YEs, let us agree to disagree, as they rightfully say.

> If you believe that approach survives the AD evaluation and
> subsequent IETF last call and the IESG ballot, go ahead.  I have no
> power to stop it.  All I can and will do is to raise the point that
> it violates RFC4291 and can't be published without updating 4291 at
> the time of the IETF last call, if this doc ever reaches there.

You seem right in your intentions.

Along these lines, all I can do is this.

I posted a request for support for that I-D in 6MAN.  I wait to see
whether there is support for it.

Someone recommended to write another I-D in 6MAN, requesting the
'assignment of fe80' from IETF/IA/nA.  He does not agree with that draft
either.  I wait to see whether there is support for it, maybe from others.

I will wait a few days, no more.

After that I will give up: if there is no support in 6MAN after a few
days then I will retire from the IPv6-over-OCB draft.

Alex

---

From: Russ Housley <[email-masked]>
Date: Fri, 19 Apr 2019 15:11:59 -0400

Alex:

You have received very clear feedback on this point, and it has been consistent throughout the long history on this document.  I do not understand why you are continuing to pushback.  I declare WG consensus for staying with the  /64 boundary.

Russ

> On Apr 19, 2019, at 12:10 AM, Suresh Krishnan <[email-masked]> wrote:
> 
> Hi Alex,
> 
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 19 Apr 2019 23:57:17 +0200

Russ,

Thank you for the messge.

Following your message, I declare I retire from this IP-over-OCB draft. 
I do not want my name in it.

(this 118 vs 64 is the second reason why I request my removal from the 
draft; the first is that QoS field that is absent from the deployments I 
care about, but present in the draft.)

Alex

---

From: Russ Housley <[email-masked]>
Date: Tue, 23 Apr 2019 10:33:44 -0400

Alex:

Thanks for all of the work you have put into the document.

I'm sorry that you feel the need to withdraw as editor over this issue.  The IPWAVE WG is not the place to debate this issue; it belong in the 6MAN WG.

Russ

> On Apr 19, 2019, at 5:57 PM, Alexandre Petrescu <[email-masked]> wrote:
> 
> Russ,
> 
> Following your message, I declare I retire from this IP-over-OCB draft. I do not want my name in it.
> 
> (this 118 vs 64 is the second reason why I request my removal from the draft; the first is that QoS field that is absent from the deployments I care about, but present in the draft.)
> 
> Alex
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 24 Apr 2019 20:17:06 +0200

Russ,

I was very happy to edit the IP-over-OCB document in a place that 
accepted this idea.  I will continue to follow it and help if necessary.

In 6MAN WG I will see about the issue.

Yours,

Alex

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 25 Apr 2019 21:42:44 +0200

>> 	• RFC 8505 isn't just about low power. 
> The titles says that, so the authors said that and including the IETF WG that published and examined it under such use cases

Actually, it doesn’t.

The title is 

Registration Extensions for IPv6 over
6LoWPAN Neighbor Discovery

because 6LoWPAN Neighbor Discovery was invented for 6LoWPAN before we started applying it to the entirety of 6Lo.

The RFC editor guidelines caused this title to be expanded to:

Registration Extensions for IPv6 over
Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery

which is indeed the expansion of “6LoWPAN”, but does not help at all — it just muddies the waters by polluting the title with terms that are no longer relevant to the document at hand.

(I’m not going to go into the other parts of the current discussion; I have no idea how something like OCB can be discussed without acknowledging the hidden terminal problem, a.k.a. non-transitive connectivity, so it seems to me I won't have much to contribute.)

Grüße, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 25 Apr 2019 20:00:50 +0000

Complete and utter agreement...

Regards,

Pascal

> Le 25 avr. 2019 à 21:43, Carsten Bormann <[email-masked]> a écrit :
> 
>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Fri, 26 Apr 2019 16:31:58 +0000

I am sure you are convinced, but myself and many others in the WG have a
hard time seeing  RFC 8505 applicability to vehicular environments.  There
may be elements from RFC 8505, and many other specs, may be leveraged, but
this characterization of RFC 8505 as the ND solution is not convincing to
me, or to most people in the group (IMO); specially for a spec designed in
6lo for low-power devices, and with the problem statement documented in
RFC 4919 not identifying a single vehicular property. You may have to
start revising RFC 4919 to change the scope of 6lo work.

Sri

On 4/25/19, 12:42 PM, "its on behalf of Carsten Bormann"
<[email-masked] on behalf of [email-masked]> wrote:

>
>>> 	€ RFC 8505 isn't just about low power.
>>WG that published and examined it under such use cases
>
>Actually, it doesn¹t.
>
>The title is 
>
>because 6LoWPAN Neighbor Discovery was invented for 6LoWPAN before we
>started applying it to the entirety of 6Lo.
>
>which is indeed the expansion of ³6LoWPAN², but does not help at all ‹ it
>just muddies the waters by polluting the title with terms that are no
>longer relevant to the document at hand.
>
>(I¹m not going to go into the other parts of the current discussion; I
>have no idea how something like OCB can be discussed without
>acknowledging the hidden terminal problem, a.k.a. non-transitive
>connectivity, so it seems to me I won't have much to contribute.)
>
>Grüße, Carsten
>

---

From: Charlie Perkins <[email-masked]>
Date: Fri, 26 Apr 2019 10:30:59 -0700

Hello Sri,

Forget about RFC 8505.

What about a solution resident on relatively fixed infrastructure that 
performs proxy ND services for vehicles in the neighborhood?

To me that sounds like an attractive sort of solution.  It could relieve 
the vehicles of their requirement to carry out RFC 4861 on-link ND 
protocol operations.   Moreover, it seems to me that unicast might be 
preferable to multicast in vehicular ND protocols, because of the issues 
outlined in previous emails and drafts.  Do you disagree?

We shouldn't get stuck talking about low power when that issue isn't 
germane to the discussion.

Regards,
Charlie P.

PS. I hope it's O.K. if I trimmed the long list of respondents. Does 
every message need to go to [email-masked] too??

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Fri, 26 Apr 2019 17:39:35 +0000

Hi Charlie,

Keeping some centralized ND cache is a very minor semantic. I don’t think that is everything.

We need to identify what all scenarios to cover. From my point of view, I am interested in brining IPv6 to OCB, so the applications in the CV can connect to infra. I am not too excited about this Star Trek type use-cases, with 2 vehicles come in proximity and have a date to exchange some prefixes, and start some live video __. The goal here is to use the radio for non-priority traffic. 

> Moreover, it seems to me that unicast might be preferable to multicast in vehicular ND protocols

We have this covered in:  https://tools.ietf.org/html/rfc6085
But, I did not say till now this is the solution. It’s one of the many semantics useful in this context.

Sri

On 4/26/19, 10:31 AM, "Charlie Perkins" <[email-masked]> wrote:

    Hello Sri,
    
    Forget about RFC 8505.

    
    
    Regards,
    Charlie P.