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