Re: [Int-dir] Intdir early review of draft-ietf-ipwave-ipv6-over-80211ocb-34 - ND and subnet structure

[Alexandre Petrescu <[e-mail]>]

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

Le 11/04/2019 à 03:53, Brian E Carpenter a écrit :
> Hi Nabil,
> 
> On 11-Apr-19 03:40, NABIL BENAMAR wrote:
>> 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,

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



> 
> Brian
> 
>> 
>> On Wed, Apr 10, 2019, 14:45 Pascal Thubert (pthubert)
>> <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> 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
>> 
>>> -----Original Message----- From: Ole Troan <[e-mail]
>>> <mailto:[e-mail]>> Sent: mercredi 10 avril 2019
>>> 20:41 To: Alexandre Petrescu <[e-mail]
>>> <mailto:[e-mail]>> Cc: Pascal Thubert
>>> (pthubert) <[e-mail] <mailto:[e-mail]>>;
>>> [e-mail] <mailto:[e-mail]>; [e-mail]
>>> <mailto:[e-mail]>; [e-mail]
>>> <mailto:[e-mail]>; draft-ietf-ipwave-ipv6-over- 
>>> [e-mail] <mailto:[e-mail]>; Brian E
>>> Carpenter <[e-mail]
>>> <mailto:[e-mail]>> Subject: Re: [Int-dir]
>>> Intdir early review of draft-ietf-ipwave-ipv6-over- 80211ocb-34 -
>>> 'conforming IPv6' - fe80::/10 vs fe80::/64
>>> 
>>>> 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.
>>> 
>>> Why?
>>> 
>>>> Now, you give a different conclusion.
>>>> 
>>>> 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: 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.
>>> 
>>> Not quite sure what value that paragraph adds in the first place.
>>> You could probable remove it.
>>> 
>>> Cheers, Ole
>>> 
>>> 
>>>> 
>>>> Alex
>>>> 
>>>> Le 10/04/2019 à 12:28, Ole Troan a écrit :
>>>>> 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
>>> <[e-mail]
>>> <mailto:[e-mail]>> wrote:
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Le 10/04/2019 à 11:04, Ole Troan a écrit :
>>>>>>>>>>> "At least" does not mean "the value should be at
>>>>>>>>>>> least 10" in that
>>> phrase.
>>>>>>>>>>> 
>>>>>>>>>>> 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.
>>>>>>>>> Indeed. If you absoultely must cut and paste text
>>>>>>>>> from 2464:
>>>>>>>> 
>>>>>>>> YEs, that is how we started.  We cut and paste 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 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
>>>>>> 
>>>>>> [...]
>>>>>> 
>>>>>>>>> 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.
>>>>>>> Ole
>>>>>> 
>>>>>> _______________________________________________ Int-dir
>>>>>> mailing list [e-mail] <mailto:[e-mail]> 
>>>>>> https://www.ietf.org/mailman/listinfo/int-dir
>>>> 
>>>> _______________________________________________ Int-dir mailing
>>>> list [e-mail] <mailto:[e-mail]> 
>>>> https://www.ietf.org/mailman/listinfo/int-dir
>> 
> 
>