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

[NABIL BENAMAR <[e-mail]>]

Do we still talk about broadcast in IPv6 ?

On Wed, Apr 10, 2019, 14:45 Pascal Thubert (pthubert) <[e-mail]>
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 <[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
>
>