On 12-Apr-19 20:42, Alexandre Petrescu wrote: > > > Le 11/04/2019 à 22:49, Brian E Carpenter a écrit : >> Hi, >> >> If there are multiple interfaces, it seems to me that you >> automatically have the situation described by Pascal, in which >> traditional Ethernet-like multicast ND, DAD and RA simply do not >> work. > > Brian, > > IPv6 ND on multiple OCB interfaces of an IP-OBU Router works ok. Each > interface has its own subnet, with its own ND, DAD and RA. The router > forwards IP packets between these interfaces. It has a routing table. So you mean that every car is a router? Sure, that can work. But this wasn't clear from Section 3 of the draft or the discussion here. So do you plan to use RPL? And some method of dynamic prefix assignment? I realise that these questions are out of scope for the present draft, but they are important context that could be mentioned in Section 3. Brian > > I do not understand what do you mean when you say that EThernet-like > multicast ND, DAD and RA simply do not work. > >>> a standard that works even if there's a single OCB interface. >> >> That's the easy case. > > I agree. > > Alex > >> >> Regards Brian >> >> On 12-Apr-19 03:15, William Whyte wrote: >>> Hi Alex -- there *can* be multiple OCB interfaces in one car, but >>> should the standard be written assuming that there are multiple OCB >>> interfaces? I would have thought that the goal would be to write a >>> standard that works even if there's a single OCB interface. >>> >>> If we're relying on multiple OCB interfaces to make this work, how >>> many of those interfaces per car are we relying on? We can't >>> presumably be assuming a distinct interface for each remote car >>> that the local car is communicating with. If we aren't assuming a >>> distinct interface for each remote car, then doesn't the problem >>> that Pascal identifies come up? >>> >>> (You also mention that the antenna at the front of car B >>> communicates with the one at back of car A -- but what if A >>> overtakes B? And to be clear, I'm not asking for a direct answer to >>> that question, I'm saying that if there are assumptions about the >>> physical topology that we're relying on, we need to make those >>> assumptions very clear and make them clear up front) >>> >>> I'd be very concerned if we were writing a standard that didn't >>> work if there was only one OCB interface in the car. Can you >>> reassure me on that? >>> >>> Cheers, >>> >>> William >>> >>> >>> >>> >>> On Thu, Apr 11, 2019 at 5:25 AM Alexandre Petrescu >>> <alexandre.petrescu@xxxxxxxxx >>> <mailto:alexandre.petrescu@xxxxxxxxx>> wrote: >>> >>> Pascal, >>> >>> Do you agree there can be multiple IP OCB interfaces in one car? >>> >>> Alex >>> >>> Le 11/04/2019 à 11:23, Alexandre Petrescu a écrit : >>>> Pascal, >>>> >>>> Please allow me to change the subject of this, to reflect the >>>> content. It helps tracking the discussion. >>>> >>>> Le 11/04/2019 à 04:36, Pascal Thubert (pthubert) a écrit : >>>>> 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. >>>> >>>> I can agree. >>>> >>>>> IOW the IETF has thrown the problem over the fence to the IEEE >>>>> but it is not really solved to this day. >>>> >>>> I think indeed there is redirection of responsability to IEEE. >>>> Maybe IEEE does not like to do it, because of some reasons. >>>> >>>> With respect to link-layer multicast: there is indeed no IEEE >>>> messaging for creation or removal of link-layer multicast groups >>>> (like in IP there is MLDv2). But there is concept of link-layer >>>> multicast groups at IEEE. This is used extensively by mapping IP >>>> groups into link-layer groups, and it helps IP. >>>> >>>> Should IEEE develop a mechanism using messages (not just local >>>> filters) for creating these link-layer groups? >>>> >>>>> 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. >>>> >>>> Well yes and no. >>>> >>>> Yes it is a broadcast on 802.3 if we talk IPv4, but it is still >>>> link-layer multicast on 802.3 if we talk IPv6: the link-layer >>>> addresses ofIPv6 on Ethernet are link-layer multicast addresses. >>>> >>>>> 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. >>>> >>>> I agree. >>>> >>>>> 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. >>>> >>>> PAscal, again, this depends on how you set up the OCB interfaces >>>> on cars A, B and C. >>>> >>>> There are two options: - use a single OCB interface with antenna >>>> sitting on top of each automobile. Make them all in the same >>>> channel frequency (e.g. CCH - Control Channel). That indeed has >>>> that A-B-C transitivity aspect. Worse, it has scalability issues: >>>> one cant grow a convoy beyond a few tens of meters and be sure >>>> the frontmost talks directly to the rearmost. One never knows >>>> whether somebody in the middle repeats, or not. Or one needs to >>>> rely on MANET protocols that may forward on a single interface. >>>> It has some PHY issues as well, that I can describe. The >>>> powerpoint is readily filled with my last PHY experiments of >>>> propagation. - use multiple OCB antennas situated at some >>>> strategic places in a car. This is in the same way as when >>>> placing the other ultra sound, radar and lidar sensors in the >>>> automobile. >>>> >>>> An OCB interface in the front bumper of one car forms a subnet >>>> with another OCB interface in the rear bumper of another car, on >>>> a particular channel (SCHx - service channel number x). The >>>> front and rear subnets of a car are in distinct channels. There >>>> is no A-B-C transitivity. There is IP forwarding between front >>>> and rear interfaces of a car. >>>> >>>> This can be described. But I dont think it should be described >>>> in the IP-over-OCB document. It is a PHY MAC setting for OCB. >>>> >>>>> 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. >>>> >>>> That may be true, but it is true mostly in a setting where each >>>> car uses a single OCB interface whose antenna is placed on the >>>> roof of the car (placed at same place as the the GPS, LTE, FM or >>>> DVB-T antennas are placed). >>>> >>>> In settings where each car has multiple OCB interfaces and >>>> multiple antennas placed at strategic places (strategic: places >>>> that are relevant to PHY propagation conditions), rather than >>>> simply on the roof, the issue you describe in the above >>>> paragraph. >>>> >>>> Now, if you read up to here, I would like to ask you (without >>>> claiming to be all-knowing), whether you think a car could have >>>> several OCB interfaces? >>>> >>>>> By traditional MANET and 6lo definition, the radio broadcast >>>>> domain of a node is his link. >>>> >>>> It is good, and I agree with it. >>>> >>>> For my part, I do not use the traditional MANET and 6lo >>>> definitions because I believe they are not sufficient for >>>> vehicular environments. >>>> >>>>> In you lab you can arrange that the broadcast domains of 3 cars >>>>> fully overlap. >>>> >>>> I agree, people do that. It is in small lab, with size in the >>>> range of a few meters; there is much reflexion from the walls. >>>> It is not outdoors. >>>> >>>>> 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... >>>> >>>> I fully agree with this paragraph. >>>> >>>> I think if one puts several interfaces and antennas in a car, >>>> and carefully design the use of the propagation models (e.g. >>>> avoid 'omni', consider 'directional', etc) then one can avoid >>>> many problems forbidding IP from running on wireless. >>>> >>>>> 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. >>>> >>>> Yes, there is. >>>> >>>>> 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. >>>> >>>> YEs, but these are departures from what might be called >>>> traditional IP forwarding. That forwarding happens between two >>>> distinct interfaces. >>>> >>>> In practice it means little software for MANET-6lo-multilink is >>>> publicly available, and the engineer skill about them is hard to >>>> find. This translates to equipment being very expensive. >>>> >>>> I want to tell you that communication equipment for cars is >>>> already very high compared to an off-the-shelf WiFi router. That >>>> high price tag is due also to specification of things that are >>>> too intelligent and that require high skills from few people. >>>> This is the case of V2X stacks doing ETSI CAM with GeoNetworking >>>> and similar. You end up with a 3000Eur IP-OBU when its >>>> underlying hardware with linux and traditional IP forwarding >>>> costs around 700Eur. >>>> >>>> To that 3000Eur one may need to add costs of complexity of MANET >>>> protocols and 6lo multilink subnet moels you arrive at a cost >>>> per communication box that is the equivalent of a small car. >>>> >>>> This high cost is less and less acceptable. >>>> >>>> Compare that to the 1Eur LTE-WiFi dongle retrofitted recently in >>>> some cars. >>>> >>>>> 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 >>>> >>>> MLSN? >>>> >>>>> 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 >>>> >>>> IOW? >>>> >>>>> 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. >>>> >>>> You did not waste your time, no more than I did. >>>> >>>> Alex >>>> >>>>> >>>>> All the best, >>>>> >>>>> Pascal >>>>> >>>>>> -----Original Message----- From: Int-dir >>>>>> <int-dir-bounces@xxxxxxxx> <mailto:int-dir-bounces@xxxxxxxx> >>>>>> On Behalf Of Brian E Carpenter Sent: jeudi 11 avril 2019 >>>>>> 09:54 To: NABIL BENAMAR <n.benamar@xxxxxxxxxxxxx> >>>>>> <mailto:n.benamar@xxxxxxxxxxxxx>; Pascal Thubert (pthubert) >>>>>> <pthubert@xxxxxxxxx> <mailto:pthubert@xxxxxxxxx> Cc: >>>>>> ietf@xxxxxxxx <mailto:ietf@xxxxxxxx>; its@xxxxxxxx >>>>>> <mailto:its@xxxxxxxx>; int-dir@xxxxxxxx >>>>>> <mailto:int-dir@xxxxxxxx>; draft-ietf-ipwave-ipv6-over- >>>>>> 80211ocb.all@xxxxxxxx <mailto:80211ocb.all@xxxxxxxx>; >>>>>> Alexandre Petrescu <alexandre.petrescu@xxxxxxxxx> >>>>>> <mailto:alexandre.petrescu@xxxxxxxxx>; Ole Troan >>>>>> <otroan@xxxxxxxxxxxxx> <mailto:otroan@xxxxxxxxxxxxx> 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) >>>>>> <pthubert@xxxxxxxxx <mailto:pthubert@xxxxxxxxx> >>>>>> <mailto:pthubert@xxxxxxxxx> <mailto:pthubert@xxxxxxxxx>> >>>>>> 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 >>>>>>>> <otroan@xxxxxxxxxxxxx <mailto:otroan@xxxxxxxxxxxxx> >>>>>> <mailto:otroan@xxxxxxxxxxxxx> <mailto:otroan@xxxxxxxxxxxxx>> >>>>>>>> Sent: mercredi 10 avril 2019 20:41 To: Alexandre Petrescu >>>>>>>> <alexandre.petrescu@xxxxxxxxx >>>>>>>> <mailto:alexandre.petrescu@xxxxxxxxx> >>>>>> <mailto:alexandre.petrescu@xxxxxxxxx> >>>>>> <mailto:alexandre.petrescu@xxxxxxxxx>> >>>>>>>> Cc: Pascal Thubert (pthubert) <pthubert@xxxxxxxxx >>>>>>>> <mailto:pthubert@xxxxxxxxx> >>>>>> <mailto:pthubert@xxxxxxxxx> <mailto:pthubert@xxxxxxxxx>>; >>>>>> ietf@xxxxxxxx <mailto:ietf@xxxxxxxx> <mailto:ietf@xxxxxxxx> >>>>>> <mailto:ietf@xxxxxxxx>; >>>>>>>> its@xxxxxxxx <mailto:its@xxxxxxxx> <mailto:its@xxxxxxxx> >>>>>>>> <mailto:its@xxxxxxxx>; int-dir@xxxxxxxx >>>>>>>> <mailto:int-dir@xxxxxxxx> <mailto:int- >>>>>> dir@xxxxxxxx <mailto:dir@xxxxxxxx>>; >>>>>> draft-ietf-ipwave-ipv6-over- >>>>>>>> 80211ocb.all@xxxxxxxx <mailto:80211ocb.all@xxxxxxxx> >>>>>>>> <mailto:80211ocb.all@xxxxxxxx> >>>>>>>> <mailto:80211ocb.all@xxxxxxxx>; Brian E >>>>>> Carpenter <brian.e.carpenter@xxxxxxxxx >>>>>> <mailto:brian.e.carpenter@xxxxxxxxx> >>>>>> <mailto:brian.e.carpenter@xxxxxxxxx> >>>>>> <mailto:brian.e.carpenter@xxxxxxxxx>> >>>>>>>> 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 >>>>>>>> <alexandre.petrescu@xxxxxxxxx >>>>>>>> <mailto:alexandre.petrescu@xxxxxxxxx> >>>>>> <mailto:alexandre.petrescu@xxxxxxxxx> >>>>>> <mailto: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 >>>>>>>>>>> <mailto:Int-dir@xxxxxxxx> <mailto:Int-dir@xxxxxxxx> >>>>>>>>>>> <mailto:Int-dir@xxxxxxxx> >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/int-dir >>>>>>>>> >>>>>>>>> _______________________________________________ Int-dir >>>>>>>>> mailing list Int-dir@xxxxxxxx <mailto:Int-dir@xxxxxxxx> >>>>>>>>> <mailto:Int-dir@xxxxxxxx> <mailto:Int-dir@xxxxxxxx> >>>>>>>>> https://www.ietf.org/mailman/listinfo/int-dir >>>>>>> >>>>>> >>>>>> _______________________________________________ Int-dir >>>>>> mailing list Int-dir@xxxxxxxx <mailto:Int-dir@xxxxxxxx> >>>>>> https://www.ietf.org/mailman/listinfo/int-dir >>> _______________________________________________ its mailing list >>> its@xxxxxxxx <mailto:its@xxxxxxxx> >>> https://www.ietf.org/mailman/listinfo/its >>> >>> >>> >>> -- >>> >>> --- >>> >>> I may have sent this email out of office hours. I never expect a >>> response outside yours. >> >> > . >
