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

["Pascal Thubert (pthubert)" <[e-mail]>]

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]>
> Sent: mercredi 10 avril 2019 20:41
> To: Alexandre Petrescu <[e-mail]>
> Cc: Pascal Thubert (pthubert) <[e-mail]>; [e-mail];
> [e-mail]; [e-mail]; draft-ietf-ipwave-ipv6-over-
> [e-mail]; Brian E Carpenter <[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]> 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]
> >>> https://www.ietf.org/mailman/listinfo/int-dir
> >
> > _______________________________________________
> > Int-dir mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/int-dir