Re: [ipwave] ND an link-layer acks

Until 802.11ai Fast Initial Link Setup implementations become readily 
available on off-the-shelf cheap wifi cards at 5.9GHz we will continue 
to rather use OCB for IP.

(2.4GHz and 5.4GHz is restricted to indoor use, and I suppose 802.11ai 
does not work on 5.9GHz)

Alex

Le 06/12/2018 à 17:46, Dick Roy a écrit :
> All true :^))) As for "what is FIPS?  ANSWER: a TYPO!  I meant FILS, Fast
> Initial Link Setup (IEEE 802.11 TGai) :^))) I didn't mean:
> 
> " FIPS (Federal Information Processing Standards) are a set of standards
> that describe document processing, encryption algorithms and other
> information technology standards for use within non-military government
> agencies and by government contractors and vendors who work with the
> agencies."
> 
> :^)))
> 
> 
> 
> -----Original Message-----
> From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu
> Sent: Thursday, December 6, 2018 8:22 AM
> To: dickroy@alum.mit.edu; 'Brian E Carpenter'; 'Dorothy Stanley'
> Cc: nordmark@sonic.net; its@ietf.org; 'John Kenney';
> jerome.haerri@eurecom.fr; draft-ietf-mboned-ieee802-mcast-problem@ietf.org;
> lorenzo=40google.com@dmarc.ietf.org
> Subject: Re: [ipwave] ND an link-layer acks - text
> 
> 
> 
> Le 06/12/2018 à 14:36, Dick Roy a écrit :
>> " In WiFi networks there is no such variability because there is
>> Association, there is an Access Point and the Hosts are relatively
>> stable (WiFi range is 50m, smartphones cant move that fast in there), so
>> the IP multicast groups like 'all-nodes' are stable."
>>
>> Actually, not so anymore.  WiFi range can be 100's of meters (Xfinity WiFi
>> on street poles) and I can associate with those BSSes while driving my car
>> down the street.
> 
> YEs, it is possible to associate to BSSes while in car, and maybe while
> driving a little bit, slowly.  But certainly not while driving full
> speed on highway.
> 
> E.g.: a car at gas station can associate to WiFi, while filling in gas;
> a car near one's home can associate to that home WiFi while driver is
> sleeping.
> 
> One should not extend this to a situation where a car drives around and
> associates to WiFi RSUs along the road and maintains an IP connection
> open while doing skype.  That does not work.  And it's not because of IP.
> 
>> It doesn't work so well yet, if I'm doing 50kph down the
>> street however:^))
> 
> I agree.
> 
>> Once FIPS gets deployed that may improve:^))
> 
> What means FIPS?  (Federal... something Standards?)
> 
> Or FMIP?  Fast Mobile IP is good solution for fast IP mobility, but it
> was experimented only on WiFi (not on OCB).  It was still slow because
> WiFi Associations were there.  There is no FMIP experiment on OCB.
> 
> Alex
> 
>>
>> -----Original Message-----
>> From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu
>> Sent: Thursday, December 6, 2018 2:26 AM
>> To: Brian E Carpenter; Dorothy Stanley
>> Cc: nordmark@sonic.net; its@ietf.org; jerome.haerri@eurecom.fr; John
> Kenney;
>> draft-ietf-mboned-ieee802-mcast-problem@ietf.org;
>> lorenzo=40google.com@dmarc.ietf.org
>> Subject: Re: [ipwave] ND an link-layer acks - text
>>
>>
>>
>> Le 05/12/2018 à 20:40, Brian E Carpenter a écrit :
>>> Alexandre,
>>>
>>> Now I am totally confused. I got into this topic because the earlier
>>> text in draft-ietf-ipwave-ipv6-over-80211ocb seemed to make it clear
>>> that OCB was significantly less reliable than BSS for the delivery of
>>> multicast packets. If that is true, ND (and presumably DAD) will work
>>> significantly less reliably and quickly for OCB. Is that true or not?
>>> If it's true, surely it needs to be documented.
>>
>> Brian,
>>
>> Sorry if there was confusion.
>>
>> 802.11-OCB is significantly less reliable than Ethernet, just like
>> 802.11 BSS is.  Both link-layer unicast and link-layer multicast in
>> 802.11-OCB and in BSS are significantly less reliable than Ethernet.
>>
>> The earlier text may have been misleading, because it's hard to write
>> excellently clear text agreed by many.
>>
>> It is also true that sending IP packets to IP link-local scoped
>> multicast groups in OCB mode, and expecting receivers to get them may
>> not be straightforward.  Forming link-scoped IP multicast groups
>> (including the 'all-nodes' group) involves the use of MLDv2 protocol;
>> this protocol forms the 'all-nodes' group by sending a REPORT message to
>> IP all-nodes address which is mapped on MAC all-nodes. This group MAC
>> all-nodes is very variable from one moment to another (cars come and go
>> at high speed).  As such it's almost impossible to be sure the groups
>> are stable and their members receive packets addressed to group at some
>> moment.
>>
>> That's my IP explanation of Dick's idea of variability in OCB networks.
>>
>> In WiFi networks there is no such variability because there is
>> Association, there is an Access Point and the Hosts are relatively
>> stable (WiFi range is 50m, smartphones cant move that fast in there), so
>> the IP multicast groups like 'all-nodes' are stable.
>>
>>>
>>> I also just discovered this draft:
>>> https://tools.ietf.org/html/draft-ietf-mboned-ieee802-mcast-problems
>>>
>>> It says nothing about OCB. Perhaps it should. Do the 802 mitigations
>>> for multicast unreliability that are described there also apply to OCB?
>>
>> I didnt know that draft.  It's good to see.
>>
>> When they talk about multicast unreliability in section 3.1.1 I think
>> they mean like in video stream: send an UDP packet to multicast group
>> but there is no Ack like TCP, so there is no reliability in multicast.
>>
>> To give a solution to that problem (make multicast reliable) there would
>> be a need of a reverse multicast concept: send packets from multicast
>> group to unicast address and ask for an Ack from that unicast address,
>> which would be sent back to all members of the group.
>>
>> But probably the reverse multicast concept is impossible simply because
>> 'cast' in multicast comes from 'broadcast' which means to cast broadly.
>> One casts a shadow of a small object over a much wider area, or one
>> 'broadcasts' TV waves to people.  So instead of 'reverse multicast'
>> maybe one can talk about 'focus' multiple sources to one destination.
>> Or something else.
>>
>> Alex
>>
>>>
>>> Regards
>>>       Brian
>>>
>>>
>>> On 2018-12-06 04:13, Alexandre Petrescu wrote:
>>>> Hello Dorothy,
>>>>
>>>> I thus suggest the following text.  Do you agree with this text?
>>>>
>>>> NEW:
>>>>     > The Neighbor Discovery protocol (ND) [RFC4861] is used over
>>>>     > 802.11-OCB links.
>>>>
>>>> OLD:
>>>>> The Neighbor Discovery protocol (ND) [RFC4861] is used over
>>>>> 802.11-OCB links.  Due to lack of link-layer acknowledgements in
>>>>> 802.11-OCB for both unicast and multicast, we can expect higher
>>>>> unicast loss than for 802.11 BSS.  The ND retransmissions are
>>>>> supposed to handle loss of unicast and/or multicast just as it does
>>>>> for other link types.
>>>>
>>>> Alex
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>> -------------------------ignore-------------------------------------------
>>>> Because:
>>>> Yous suggest one might mention DSRC apps rarely rely on Acks: I think
>>>> it's hard to talk about DSRC applications in a network-layer document;
>>>> but I tend to agree with you about the presence of Acks in OCB
>>>> implementations, some times (not always); for the broadcast/multicast
>>>> term: I find the term ambiguous: IPv6 does not know about 'broadcast' at
>>>> all (and that's an IPv6-over-WiFi matter, not OCB in particular).
>>>>
>>>>
>>>> Le 05/12/2018 à 15:24, Dorothy Stanley a écrit :
>>>>> Hello Alexandre,
>>>>>
>>>>> The sentence " Due to lack of association operations in 802.11-OCB,
>>>>> we can expect higher packet loss than for 802.11 BSS."
>>>>>
>>>>> is not correct.  The lack of acknowledgements for broadcast/multicast
>>>>>     traffic is the same in OCB and BSS operation. The presence of
>>>>> acknowledgements for unicast trafic is the same in OCB and BSS
>>>>> operation. The lack of asssociation operation is irrelevant.
>>>>>
>>>>> If the intent is to say that unacknowledged broadcast traffic is
>>>>> heavily used in DSRC applications, then just say that.
>>>>>
>>>>> I suggest deleting the current sentence.
>>>>>
>>>>> Dorothy
>>>>>
>>>>> ---------------------- Dorothy Stanley IEEE 802.11 WG Chair,
>>>>> dstanley@ieee.org <mailto:dstanley@ieee.org> Hewlett Packard
>>>>> Enterprise dorothy.stanley@hpe.com
>>>>> <mailto:dstanley@arubanetworks.com> dstanley1389@gmail.com
>>>>> <mailto:dstanley1389@gmail.com> +1 630-363-1389 <tel:630-363-1389>
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Dec 5, 2018 at 2:52 AM Alexandre Petrescu
>>>>> <alexandre.petrescu@gmail.com <mailto:alexandre.petrescu@gmail.com>>
>>>>> wrote:
>>>>>
>>>>> John, Jérôme :  you seem to be agreeing.
>>>>>
>>>>> So, how about this text proposal?
>>>>>
>>>>> NEW:
>>>>>> The Neighbor Discovery protocol (ND) [RFC4861] is used over
>>>>>> 802.11-OCB links.  Due to lack of association operations in
>>>>>> 802.11-OCB, we can expect higher packet loss than for 802.11 BSS.
>>>>>> The ND retransmissions are supposed to handle loss of IP unicast
>>>>>> and/or IP multicast just as it does for other link types.
>>>>>
>>>>> (remark 'lack of association operations' instead of 'lack of
>>>>> link-layer acks')
>>>>>
>>>>> OLD:
>>>>>> The Neighbor Discovery protocol (ND) [RFC4861] is used over
>>>>>> 802.11-OCB links.  Due to lack of link-layer acknowledgements in
>>>>>> 802.11-OCB for both unicast and multicast, we can expect higher
>>>>>> unicast loss than for 802.11 BSS.  The ND retransmissions are
>>>>>> supposed to handle loss of unicast and/or multicast just as it
>>>>>> does for other link types.
>>>>> I will not modify this text until I dont have agreements and from
>>>>> you and from a representative of 6MAN WG.  It's a text that has been
>>>>> crafted in fine detail.
>>>>>
>>>>> Alex
>>>>>
>>>>> Le 05/12/2018 à 03:09, Jérôme Härri a écrit :
>>>>>> Hi All,
>>>>>>
>>>>>> I support John's comment. ITS-G5/DSRC/OCB can fully do unicast
>>>>>> with acks. It is the application that chose not to use this but
>>>>>> rather broadcast. And even considering broadcast, I do not think we
>>>>>> have higher packet losses. Just that we do not retransmit, as it
>>>>>> is broadcast. Maybe we should mention reduced 'application-layer
>>>>>> reliability' so something in that direction..
>>>>>>
>>>>>>
>>>>>> BR,
>>>>>>
>>>>>> Jérôme
>>>>>>
>>>>>> *From:*its [mailto:its-bounces@ietf.org
>>>>> <mailto:its-bounces@ietf.org>] *On Behalf Of *John Kenney
>>>>>> *Sent:* Tuesday 04 December 2018 16:38 *To:* Alexandre Petrescu
>>>>>> *Cc:* its; Dorothy Stanley *Subject:* Re: [ipwave] Fwd: New
>>>>>> Version Notification for
>>>>>> draft-ietf-ipwave-ipv6-over-80211ocb-31.txt
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Caveat: I know nothing about Neighbor Discovery protocol.
>>>>>>
>>>>>> I see this in the proposed new text:
>>>>>>
>>>>>> Due to lack of link-layer acknowledgements in 802.11-OCB, we can
>>>>>> expect higher packet loss than for 802.11 BSS.
>>>>>>
>>>>>> I don't understand why it is expected that OCB has a lack of
>>>>>> link-layer acknowledgments.  OCB uses link layer acks the same way
>>>>>> as 802.11 BSS uses them.   If I send a unicast 802.11 packet
>>>>>> outside the context of a BSS, I expect an 802.11 ACK. If I don't
>>>>>> get the 802.11 ACK, I go through exponential backoff and
>>>>>> retransmit.  Just like normal 802.11.  Maybe I'm missing
>>>>>> something.
>>>>>>
>>>>>> Best Regards,
>>>>>>
>>>>>> John
>>>>>>
>>>>>> On Tue, Dec 4, 2018 at 7:11 AM Alexandre Petrescu
>>>>>> <alexandre.petrescu@gmail.com
>>>>> <mailto:alexandre.petrescu@gmail.com>
>>>>> <mailto:alexandre.petrescu@gmail.com
>>>>> <mailto:alexandre.petrescu@gmail.com>>>
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Le 04/12/2018 à 16:04, Dorothy Stanley a écrit :
>>>>>>> Hello Alexandre, all,
>>>>>>>
>>>>>>> I am sharing the following information from John Kenny (
>>>>>>> jkenney@us.toyota-itc.com <mailto:jkenney@us.toyota-itc.com>
>>>>> <mailto:jkenney@us.toyota-itc.com
>>>>> <mailto:jkenney@us.toyota-itc.com>>
>>>>>> <mailto:jkenney@us.toyota-itc.com
>>>>>> <mailto:jkenney@us.toyota-itc.com>
>>>>>> <mailto:jkenney@us.toyota-itc.com
>>>>> <mailto:jkenney@us.toyota-itc.com>>>), who is
>>>>>>> actively involved in 802.11p implementation and deployments:
>>>>>>> "OCB can use unicast in the same way as other flavors of 802.11
>>>>>>> ( individually addressed 802.11 MAC PDU that is ACKed using
>>>>>>> 802.11 procedures ). I find this is a common misunderstanding
>>>>>>> (indeed, I am in a meeting right now where this very point came
>>>>>>> up about 20 minutes ago). Probably the confusion is partly due to
>>>>>>> the fact that a great deal of DSRC attention is focused on the
>>>>>>> broadcast Basic Safety Message. Some people think that DSRC is
>>>>>>> only BSMs, or only broadcast messages. But, there are some
>>>>>>> important unicast applications as well."
>>>>>>>
>>>>>>> Thus a change is needed in 4.7, either delete the second
>>>>>>> sentence or modify to reflect that unicast is acknowledged.
>>>>>>
>>>>>> I propose
>>>>>>
>>>>>> NEW:
>>>>>>> The Neighbor Discovery protocol (ND) [RFC4861] is used over
>>>>>>> 802.11-OCB links.  Due to lack of link-layer acknowledgements in
>>>>>>> 802.11-OCB, we can expect higher packet loss than for 802.11
>>>>>>> BSS. The ND retransmissions are supposed to handle loss of IP
>>>>>>> unicast and/or IP multicast just as it does for other link
>>>>>>> types.
>>>>>>
>>>>>> (remark disappeared 'unicast' and 'multicast' from 2nd phrase, and
>>>>>> added 'IP' in front of unicast and multicast in 3rd phrase).
>>>>>>
>>>>>> OLD:
>>>>>>> The Neighbor Discovery protocol (ND) [RFC4861] is used over
>>>>>>> 802.11-OCB links.  Due to lack of link-layer acknowledgements in
>>>>>>> 802.11-OCB for both unicast and multicast, we can expect higher
>>>>>>> unicast loss than for 802.11 BSS.  The ND retransmissions are
>>>>>>> supposed to handle loss of unicast and/or multicast just as it
>>>>>>> does for other link types.
>>>>>>
>>>>>> Would this be agreed by John Kenney.
>>>>>>
>>>>>> Alex
>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Dorothy
>>>>>>>
>>>>>>> ---------------------- Dorothy Stanley IEEE 802.11 WG Chair,
>>>>>>> dstanley@ieee.org <mailto:dstanley@ieee.org>
>>>>> <mailto:dstanley@ieee.org <mailto:dstanley@ieee.org>>
>>>>>> <mailto:dstanley@ieee.org <mailto:dstanley@ieee.org>
>>>>> <mailto:dstanley@ieee.org <mailto:dstanley@ieee.org>>> Hewlett
>>>>>> Packard
>>>>>>> Enterprise dorothy.stanley@hpe.com
>>>>> <mailto:dorothy.stanley@hpe.com> <mailto:dorothy.stanley@hpe.com
>>>>> <mailto:dorothy.stanley@hpe.com>>
>>>>>>> <mailto:dstanley@arubanetworks.com
>>>>> <mailto:dstanley@arubanetworks.com>
>>>>>> <mailto:dstanley@arubanetworks.com
>>>>> <mailto:dstanley@arubanetworks.com>>> dstanley1389@gmail.com
>>>>> <mailto:dstanley1389@gmail.com>
>>>>>> <mailto:dstanley1389@gmail.com <mailto:dstanley1389@gmail.com>>
>>>>>>> <mailto:dstanley1389@gmail.com <mailto:dstanley1389@gmail.com>
>>>>> <mailto:dstanley1389@gmail.com <mailto:dstanley1389@gmail.com>>>
>>>>>> +1 630-363-1389 <tel:630-363-1389>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Nov 19, 2018 at 10:07 AM Alexandre Petrescu
>>>>>>> <alexandre.petrescu@gmail.com
>>>>>>> <mailto:alexandre.petrescu@gmail.com>
>>>>>> <mailto:alexandre.petrescu@gmail.com
>>>>> <mailto:alexandre.petrescu@gmail.com>>
>>>>>> <mailto:alexandre.petrescu@gmail.com
>>>>> <mailto:alexandre.petrescu@gmail.com>
>>>>>> <mailto:alexandre.petrescu@gmail.com
>>>>> <mailto:alexandre.petrescu@gmail.com>>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Hi IPWAVErs,
>>>>>>>
>>>>>>> Following the discussion during presentation of the IPv6/OCB
>>>>>>> slides by Nabil during IPWAVE WG meeting, I have updated the
>>>>>>> IPv6/OCB draft.
>>>>>>>
>>>>>>> This is the ChangeLog:
>>>>>>>
>>>>>>> - filled in the section titled "Pseudonym Handling"; - removed a
>>>>>>> 'MAY NOT' phrase about possibility of having other prefix than
>>>>>>> the LL on the link between cars; - shortened and improved the
>>>>>>> paragraph about Mobile IPv6, now with DNAv6; - improved the ND
>>>>>>> text about ND retransmissions with relationship to packet loss;
>>>>>>> - changed the title of an appendix from 'EPD' to 'Protocol
>>>>>>> Layering'; - improved the 'Aspects introduced by OCB' appendix
>>>>>>> with a few phrases about the channel use and references.
>>>>>>>
>>>>>>> This fixes all issues about ND and pseudonym handling.
>>>>>>>
>>>>>>> Alex
>>>>>>>
>>>>>>> -------- Message transféré -------- Sujet : New Version
>>>>>>> Notification for draft-ietf-ipwave-ipv6-over-80211ocb-31.txt
>>>>>>> Date : Mon, 19 Nov 2018 10:01:52 -0800 De :
>>>>>>> internet-drafts@ietf.org
>>>>> <mailto:internet-drafts@ietf.org>
>>>>>> <mailto:internet-drafts@ietf.org
>>>>>> <mailto:internet-drafts@ietf.org>>
>>>>>>> <mailto:internet-drafts@ietf.org
>>>>>>> <mailto:internet-drafts@ietf.org>
>>>>>> <mailto:internet-drafts@ietf.org
>>>>> <mailto:internet-drafts@ietf.org>>> Pour : Jerome Haerri
>>>>>>> <Jerome.Haerri@eurecom.fr <mailto:Jerome.Haerri@eurecom.fr>
>>>>> <mailto:Jerome.Haerri@eurecom.fr <mailto:Jerome.Haerri@eurecom.fr>>
>>>>>> <mailto:Jerome.Haerri@eurecom.fr <mailto:Jerome.Haerri@eurecom.fr>
>>>>>> <mailto:Jerome.Haerri@eurecom.
>>>>>> <mailto:Jerome.Haerri@eurecom.>.fr>>>,
>>>>>>> ipwave-chairs@ietf.org <mailto:ipwave-chairs@ietf.org>
>>>>> <mailto:ipwave-chairs@ietf.org <mailto:ipwave-chairs@ietf.org>>
>>>>>> <mailto:ipwave-chairs@ietf.org <mailto:ipwave-chairs@ietf.org>
>>>>> <mailto:ipwave-chairs@ietf.org <mailto:ipwave-chairs@ietf.org>>>,
>>>>>> Jerome Haerri
>>>>>>> <jerome.haerri@eurecom.fr <mailto:jerome.haerri@eurecom.fr>
>>>>> <mailto:jerome.haerri@eurecom.fr <mailto:jerome.haerri@eurecom.fr>>
>>>>>> <mailto:jerome.haerri@eurecom.fr <mailto:jerome.haerri@eurecom.fr>
>>>>>> <mailto:jerome.haerri@eurecom.
>>>>>> <mailto:jerome.haerri@eurecom.>.fr>>>,
>>>>>>> Alexandre Petrescu <Alexandre.Petrescu@cea.fr
>>>>> <mailto:Alexandre.Petrescu@cea.fr>
>>>>>> <mailto:Alexandre.Petrescu@cea.fr
>>>>>> <mailto:Alexandre.Petrescu@cea.fr>>
>>>>>>> <mailto:Alexandre.Petrescu@cea.fr
>>>>>>> <mailto:Alexandre.Petrescu@cea.fr>
>>>>>> <mailto:Alexandre.Petrescu@cea.fr
>>>>> <mailto:Alexandre.Petrescu@cea.fr>>>>, Alexandre Petrescu
>>>>>>> <alexandre.petrescu@cea.fr <mailto:alexandre.petrescu@cea.fr>
>>>>> <mailto:alexandre.petrescu@cea.fr
>>>>> <mailto:alexandre.petrescu@cea.fr>>
>>>>>> <mailto:alexandre.petrescu@cea.fr
>>>>>> <mailto:alexandre.petrescu@cea.fr>
>>>>>> <mailto:alexandre.petrescu@cea.fr
>>>>> <mailto:alexandre.petrescu@cea.fr>>>>, Nabil
>>>>>>> Benamar <n.benamar@est.umi.ac.ma
>>>>> <mailto:n.benamar@est.umi.ac.ma> <mailto:n.benamar@est.umi.ac.ma
>>>>> <mailto:n.benamar@est.umi.ac.ma>>
>>>>>> <mailto:n.benamar@est.umi.ac.ma <mailto:n.benamar@est.umi.ac.ma>
>>>>> <mailto:n.benamar@est.umi.ac.ma <mailto:n.benamar@est.umi.ac.ma>>>>,
>>>>>>> Thierry Ernst <thierry.ernst@yogoko.fr
>>>>> <mailto:thierry.ernst@yogoko.fr>
>>>>>> <mailto:thierry.ernst@yogoko.fr <mailto:thierry.ernst@yogoko.fr>>
>>>>>>> <mailto:thierry.ernst@yogoko.fr <mailto:thierry.ernst@yogoko.fr>
>>>>>> <mailto:thierry.ernst@yogoko.fr
>>>>> <mailto:thierry.ernst@yogoko.fr>>>>, Jong-Hyouk Lee
>>>>>>> <jonghyouk@smu.ac.kr <mailto:jonghyouk@smu.ac.kr>
>>>>> <mailto:jonghyouk@smu.ac.kr <mailto:jonghyouk@smu.ac.kr>>
>>>>>> <mailto:jonghyouk@smu.ac.kr <mailto:jonghyouk@smu.ac.kr>
>>>>> <mailto:jonghyouk@smu.ac.kr <mailto:jonghyouk@smu.ac.kr>>>>
>>>>>>>
>>>>>>>
>>>>>>> A new version of I-D,
>>>>>>> draft-ietf-ipwave-ipv6-over-80211ocb-31.txt has been successfully
>>>>>>> submitted by Alexandre Petrescu and posted to the IETF
>>>>>>> repository.
>>>>>>>
>>>>>>> Name:           draft-ietf-ipwave-ipv6-over-80211ocb Revision:
>>>>>>> 31 Title:          Transmission of IPv6 Packets over IEEE 802.11
>>>>>>> Networks operating in mode Outside the Context of a Basic
>>>>>>> Service Set (IPv6-over-80211-OCB) Document date:  2018-11-19
>>>>>>> Group: ipwave Pages: 41 URL:
>>>>>>>
>>>>>>
>>>>>
>>
> https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb-31
>> .txt
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> Status:
>>>>>>>
>>>>>>
>>>>> https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> Htmlized:
>>>>>>> https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-31
>>>>>
>>>>>>>
>>>>>
>>>>>>>
>>>>>>>
>>>>>> Htmlized:
>>>>>>>
>>>>>>
>>>>>
>> https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> Diff:
>>>>>>>
>>>>>>
>>>>>
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-31
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> Abstract: In order to transmit IPv6 packets on IEEE 802.11
>>>>>> networks
>>>>>>> running outside the context of a basic service set (OCB, earlier
>>>>>>> "802.11p") there is a need to define a few parameters such as
>>>>>>> the supported Maximum Transmission Unit size on the 802.11-OCB
>>>>>>> link, the header format preceding the IPv6 header, the Type value
>>>>>>> within it, and others.  This document describes these parameters
>>>>>>> for IPv6 and IEEE 802.11-OCB networks; it portrays the layering
>>>>>>> of IPv6 on 802.11-OCB similarly to other known 802.11 and
>>>>>>> Ethernet layers - by using an Ethernet Adaptation Layer.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Please note that it may take a couple of minutes from the time
>>>>>>> of submission until the htmlized version and diff are available
>>>>>>> at tools.ietf.org <http://tools.ietf.org>
>>>>>>> <http://tools.ietf.org>
>>>>> <http://tools.ietf.org>.
>>>>>>>
>>>>>>> The IETF Secretariat
>>>>>>>
>>>>>>> _______________________________________________ its mailing list
>>>>>>> its@ietf.org <mailto:its@ietf.org> <mailto:its@ietf.org
>>>>> <mailto:its@ietf.org>> <mailto:its@ietf.org <mailto:its@ietf.org>
>>>>>> <mailto:its@ietf.org <mailto:its@ietf.org>>>
>>>>>>> https://www.ietf.org/mailman/listinfo/its
>>>>>>>
>>>>>>
>>>>>> _______________________________________________ its mailing list
>>>>>> its@ietf.org <mailto:its@ietf.org> <mailto:its@ietf.org
>>>>> <mailto:its@ietf.org>>
>>>>>> https://www.ietf.org/mailman/listinfo/its
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> John Kenney
>>>>>>
>>>>>> Director and Principal Researcher
>>>>>>
>>>>>> Toyota InfoTechnology Center, USA
>>>>>>
>>>>>> 465 Bernardo Avenue
>>>>>>
>>>>>> Mountain View, CA 94043
>>>>>>
>>>>>> Tel: 650-694-4160. Mobile: 650-224-6644
>>>>>>
>>>>>
>>>>> _______________________________________________ its mailing list
>>>>> its@ietf.org <mailto:its@ietf.org>
>>>>> https://www.ietf.org/mailman/listinfo/its
>>>>>
>>>>
>>>
>>>
>>
>> _______________________________________________
>> its mailing list
>> its@ietf.org
>> https://www.ietf.org/mailman/listinfo/its
>>
>>
> 
> _______________________________________________
> its mailing list
> its@ietf.org
> https://www.ietf.org/mailman/listinfo/its
> 
> 