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) <pthubert@xxxxxxxxx <mailto:pthubert@xxxxxxxxx>> 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 <otroan@xxxxxxxxxxxxx <mailto:otroan@xxxxxxxxxxxxx>>
> > Sent: mercredi 10 avril 2019 20:41
> > To: Alexandre Petrescu <alexandre.petrescu@xxxxxxxxx <mailto:alexandre.petrescu@xxxxxxxxx>>
> > Cc: Pascal Thubert (pthubert) <pthubert@xxxxxxxxx <mailto:pthubert@xxxxxxxxx>>; ietf@xxxxxxxx <mailto:ietf@xxxxxxxx>;
> > its@xxxxxxxx <mailto:its@xxxxxxxx>; int-dir@xxxxxxxx <mailto:int-dir@xxxxxxxx>; draft-ietf-ipwave-ipv6-over-
> > 80211ocb.all@xxxxxxxx <mailto:80211ocb.all@xxxxxxxx>; Brian E Carpenter <brian.e.carpenter@xxxxxxxxx <mailto:brian.e.carpenter@xxxxxxxxx>>
> > 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
> > <alexandre.petrescu@xxxxxxxxx <mailto:alexandre.petrescu@xxxxxxxxx>> 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
> > >>> Int-dir@xxxxxxxx <mailto:Int-dir@xxxxxxxx>
> > >>> https://www.ietf.org/mailman/listinfo/int-dir
> > >
> > > _______________________________________________
> > > Int-dir mailing list
> > > Int-dir@xxxxxxxx <mailto:Int-dir@xxxxxxxx>
> > > https://www.ietf.org/mailman/listinfo/int-dir
>
