Alexandre, >>> 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? > > You said if OCB-Ethernet bridging then no need of update. Then you > concluded differently. That needs clarification. No need to update 4291. >> That a link-layer that looks an awfully lot like Ethernet > > It looks an awful lot like Ethernet, but it can not be bridged to it. The 'brctl' and 'brconf' software issue errors when trying to link OCB interface to Ethernet interface. > >> [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. > > If OCB can not be bridged to Ethernet then OCB interfaces are free to have a 65bit IID, without fearing lack of interoperability to an Ethernet interface with 64bit IID. The IP forwarding does not care about IID length, and there is no bridging. Rathole. >> 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. > > Makes sense, I will add it. > > Then somebody will ask what is the prefix length of the LL prefix on OCB? What reference should I give to the person asking? > > The reference is RFC2464 that says 64bit IID. But that is for Ethernet and EThernet can not be bridged to OCB. > >> Not quite sure what value that paragraph adds in the first place. You >> could probable remove it. > > The value in mentioning /10 is that it works on OCB (it works also on Ethernet but not on all OSs, and so it may risk violating a section). Because some implementations can handle it, is not a reason to diverge from RFC2464. Stick with the RFC2464 definition. Remove the paragraph and just reference 2464, and you should be fine (at least from the link-local perspective) in this draft. Anyone else see a problem with that solution? Cheers, Ole
