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 Brian

I meant broadcast at layer 2 not layer 3. L3 uses multicast but it requires a service at the lower layer to implement it. This is rarely if ever a real L2 multicast service. IOW the IETF has thrown the problem over the fence to the IEEE but it is not really solved to this day.

In practice, the service that is performed on IEEE std 802.3 is a broadcast over a broadcast domain, and the subnet has to be contained within that domain. The broadcast operation is emulated on IEEE std 802.11 by the BSS operation whereby the AP reflects the message to be broadcasted, so the broadcast domain is that of the AP as opposed to that of the source STA. 

By the proposed definition, if car A sees car B they are in the same subnet. If car B sees car C they are in the same subnet. Transitively Car A is in the same subnet as car C. But car C may not be in the radio broadcast domain of car A, and there is no BSS by definition of OCB to emulate a broadcast domain between them via an AP. End result is that a DAD or a lookup by car A will not reach car C. 

By traditional MANET and 6lo definition, the radio broadcast domain of a node is his link. In you lab you can arrange that the broadcast domains of 3 cars fully overlap. In that case, the link appears to match the common sense of a link in wires and the classical IPv6 operations will work pretty much the same as in a BSS over that Link. It is for example easy to place a subnet that matches that Link. It is also easy to confuse a Link with a Subnet, which is what the definition does. As soon as the broadcast domains start diverging, things get hairy, see all the work by Erik about split subnet etc...

The IETF has studied this situations for 10+ years at MANET, 6TiSCH and 6lo. We have an architecture that cover single link and multilink subnets. In the former case, the link is defined by one node that owns the prefix. In the latter case, routing is required inside the subnet and we created RPL to cover the situation. We created RFC 8505 for an host to connect to the network in either situation, without the requirement that the L2 broadcast domain of the host (its Link) overlaps with that of other nodes in the subnet (because they don't). We have made RFC 8505 abstract to the routing protocol if any, IOW without the requirement that the host knows there is a MLSN, understands RPL or whatever other routing is used to put together the MLSN. To get there we had to abandon the dependency that a L2 broadcast from the host reaches all nodes in the subnet, IOW that the subnet is contained within the Link of all of its members, IOW that the Links of all the nodes in the subnet fully overlap. This meant we had to abandon the idea of using multicast in ND for DAD and AR. 

Maybe someone can explain that better than I did. I so please be my guest. I really tried but I'm not convinced I did not waste my time with the authors of the draft.

All the best,

Pascal

> -----Original Message-----
> From: Int-dir <[e-mail]> On Behalf Of Brian E Carpenter
> Sent: jeudi 11 avril 2019 09:54
> To: NABIL BENAMAR <[e-mail]>; Pascal Thubert (pthubert)
> <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail]; draft-ietf-ipwave-ipv6-over-
> [e-mail]; Alexandre Petrescu <[e-mail]>;
> Ole Troan <[e-mail]>
> Subject: Re: [Int-dir] Intdir early review of draft-ietf-ipwave-ipv6-over-
> 80211ocb-34 - 'conforming IPv6' - fe80::/10 vs fe80::/64
> 
> Hi Nabil,
> 
> On 11-Apr-19 03:40, NABIL BENAMAR wrote:
> > Do we still talk about broadcast in IPv6 ?
> 
> No, we talk about multicast. Pascal was using shorthand. But if multicast fails
> with high probability, several aspects of IPv6 will fail too, unless the LAN
> provides an NBMA (non-broadcast multiple access) emulation of multicast, or
> suitable alternatives to SLAAC, ND, NUD, and RA.
> 
> An earlier draft of this spec mentioned this problem:
> 
> >>>    The operation of the Neighbor Discovery protocol (ND) over 802.11-OCB
> >>>    links is different than over 802.11 links.  In OCB, the link layer
> >>>    does not ensure that all associated members receive all messages,
> >>>    because there is no association operation.  Neighbor Discovery (ND)
> >>>    is used over 802.11-OCB.
> 
> but it was inconsistent and was removed. If Ole is correct below about real-life
> conditions, the *problem* was not removed and the draft is not going to work
> in the real world.
> 
>     Brian
> 
> >
> > On Wed, Apr 10, 2019, 14:45 Pascal Thubert (pthubert)
> <[e-mail] <mailto:[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]
> <mailto:[e-mail]>>
> >     > Sent: mercredi 10 avril 2019 20:41
> >     > To: Alexandre Petrescu <[e-mail]
> <mailto:[e-mail]>>
> >     > Cc: Pascal Thubert (pthubert) <[e-mail]
> <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>;
> >     > [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:int-
> [e-mail]>; draft-ietf-ipwave-ipv6-over-
> >     > [e-mail] <mailto:[e-mail]>; Brian E
> Carpenter <[e-mail]
> <mailto:[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]
> <mailto:[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] <mailto:[e-mail]>
> >     > >>> https://www.ietf.org/mailman/listinfo/int-dir
> >     > >
> >     > > _______________________________________________
> >     > > Int-dir mailing list
> >     > > [e-mail] <mailto:[e-mail]>
> >     > > https://www.ietf.org/mailman/listinfo/int-dir
> >
> 
> _______________________________________________
> Int-dir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/int-dir