Re: [ipwave] [Int-dir] Intdir early review of draft-ietf-ipwave-ipv6-over-80211ocb-34 - 'conforming IPv6' - fe80::/10 vs fe80::/64

[Brian E Carpenter <[e-mail]>]

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

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