> 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
