Re: [ipwave] ND an link-layer acks

[Alexandre Petrescu <[e-mail]>]

Never saw something else than OCB at 5.9GHz (no FILS messages)

Le 06/12/2018 à 19:10, Dick Roy a écrit :
> FILS is frequency band agnostic.  It's really a session layer functionality.
> 
> 
> 
> -----Original Message-----
> From: its [mailto:[e-mail]] On Behalf Of Alexandre Petrescu
> Sent: Thursday, December 6, 2018 9:02 AM
> To: [e-mail]; 'Brian E Carpenter'; 'Dorothy Stanley'
> Cc: [e-mail]; [e-mail]; [e-mail]; 'John
> Kenney'; [e-mail];
> lorenzo=[e-mail]
> Subject: Re: [ipwave] ND an link-layer acks - text
> 
> 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:[e-mail]] On Behalf Of Alexandre Petrescu
>> Sent: Thursday, December 6, 2018 8:22 AM
>> To: [e-mail]; 'Brian E Carpenter'; 'Dorothy Stanley'
>> Cc: [e-mail]; [e-mail]; 'John Kenney';
>> [e-mail];
> [e-mail];
>> lorenzo=[e-mail]
>> 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:[e-mail]] On Behalf Of Alexandre Petrescu
>>> Sent: Thursday, December 6, 2018 2:26 AM
>>> To: Brian E Carpenter; Dorothy Stanley
>>> Cc: [e-mail]; [e-mail]; [e-mail]; John
>> Kenney;
>>> [e-mail];
>>> lorenzo=[e-mail]
>>> 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,
>>>>>> [e-mail] <mailto:[e-mail]> Hewlett Packard
>>>>>> Enterprise [e-mail]
>>>>>> <mailto:[e-mail]> [e-mail]
>>>>>> <mailto:[e-mail]> [phone] <tel:[phone]>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Dec 5, 2018 at 2:52 AM Alexandre Petrescu
>>>>>> <[e-mail] <mailto:[e-mail]>>
>>>>>> 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:[e-mail]
>>>>>> <mailto:[e-mail]>] *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
>>>>>>> <[e-mail]
>>>>>> <mailto:[e-mail]>
>>>>>> <mailto:[e-mail]
>>>>>> <mailto:[e-mail]>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Le 04/12/2018 à 16:04, Dorothy Stanley a écrit :
>>>>>>>> Hello Alexandre, all,
>>>>>>>>
>>>>>>>> I am sharing the following information from John Kenny (
>>>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>> <mailto:[e-mail]
>>>>>> <mailto:[e-mail]>>
>>>>>>> <mailto:[e-mail]
>>>>>>> <mailto:[e-mail]>
>>>>>>> <mailto:[e-mail]
>>>>>> <mailto:[e-mail]>>>), 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,
>>>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>> <mailto:[e-mail] <mailto:[e-mail]>>
>>>>>>> <mailto:[e-mail] <mailto:[e-mail]>
>>>>>> <mailto:[e-mail] <mailto:[e-mail]>>> Hewlett
>>>>>>> Packard
>>>>>>>> Enterprise [e-mail]
>>>>>> <mailto:[e-mail]> <mailto:[e-mail]
>>>>>> <mailto:[e-mail]>>
>>>>>>>> <mailto:[e-mail]
>>>>>> <mailto:[e-mail]>
>>>>>>> <mailto:[e-mail]
>>>>>> <mailto:[e-mail]>>> [e-mail]
>>>>>> <mailto:[e-mail]>
>>>>>>> <mailto:[e-mail] <mailto:[e-mail]>>
>>>>>>>> <mailto:[e-mail] <mailto:[e-mail]>
>>>>>> <mailto:[e-mail] <mailto:[e-mail]>>>
>>>>>>> [phone] <tel:[phone]>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Nov 19, 2018 at 10:07 AM Alexandre Petrescu
>>>>>>>> <[e-mail]
>>>>>>>> <mailto:[e-mail]>
>>>>>>> <mailto:[e-mail]
>>>>>> <mailto:[e-mail]>>
>>>>>>> <mailto:[e-mail]
>>>>>> <mailto:[e-mail]>
>>>>>>> <mailto:[e-mail]
>>>>>> <mailto:[e-mail]>>>>
>>>>>>>> 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 :
>>>>>>>> [e-mail]
>>>>>> <mailto:[e-mail]>
>>>>>>> <mailto:[e-mail]
>>>>>>> <mailto:[e-mail]>>
>>>>>>>> <mailto:[e-mail]
>>>>>>>> <mailto:[e-mail]>
>>>>>>> <mailto:[e-mail]
>>>>>> <mailto:[e-mail]>>> Pour : Jerome Haerri
>>>>>>>> <[e-mail] <mailto:[e-mail]>
>>>>>> <mailto:[e-mail] <mailto:[e-mail]>>
>>>>>>> <mailto:[e-mail] <mailto:[e-mail]>
>>>>>>> <mailto:Jerome.Haerri@eurecom.
>>>>>>> <mailto:Jerome.Haerri@eurecom.>.fr>>>,
>>>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>> <mailto:[e-mail] <mailto:[e-mail]>>
>>>>>>> <mailto:[e-mail] <mailto:[e-mail]>
>>>>>> <mailto:[e-mail] <mailto:[e-mail]>>>,
>>>>>>> Jerome Haerri
>>>>>>>> <[e-mail] <mailto:[e-mail]>
>>>>>> <mailto:[e-mail] <mailto:[e-mail]>>
>>>>>>> <mailto:[e-mail] <mailto:[e-mail]>
>>>>>>> <mailto:jerome.haerri@eurecom.
>>>>>>> <mailto:jerome.haerri@eurecom.>.fr>>>,
>>>>>>>> Alexandre Petrescu <[e-mail]
>>>>>> <mailto:[e-mail]>
>>>>>>> <mailto:[e-mail]
>>>>>>> <mailto:[e-mail]>>
>>>>>>>> <mailto:[e-mail]
>>>>>>>> <mailto:[e-mail]>
>>>>>>> <mailto:[e-mail]
>>>>>> <mailto:[e-mail]>>>>, Alexandre Petrescu
>>>>>>>> <[e-mail] <mailto:[e-mail]>
>>>>>> <mailto:[e-mail]
>>>>>> <mailto:[e-mail]>>
>>>>>>> <mailto:[e-mail]
>>>>>>> <mailto:[e-mail]>
>>>>>>> <mailto:[e-mail]
>>>>>> <mailto:[e-mail]>>>>, Nabil
>>>>>>>> Benamar <[e-mail]
>>>>>> <mailto:[e-mail]> <mailto:[e-mail]
>>>>>> <mailto:[e-mail]>>
>>>>>>> <mailto:[e-mail] <mailto:[e-mail]>
>>>>>> <mailto:[e-mail] <mailto:[e-mail]>>>>,
>>>>>>>> Thierry Ernst <[e-mail]
>>>>>> <mailto:[e-mail]>
>>>>>>> <mailto:[e-mail] <mailto:[e-mail]>>
>>>>>>>> <mailto:[e-mail] <mailto:[e-mail]>
>>>>>>> <mailto:[e-mail]
>>>>>> <mailto:[e-mail]>>>>, Jong-Hyouk Lee
>>>>>>>> <[e-mail] <mailto:[e-mail]>
>>>>>> <mailto:[e-mail] <mailto:[e-mail]>>
>>>>>>> <mailto:[e-mail] <mailto:[e-mail]>
>>>>>> <mailto:[e-mail] <mailto:[e-mail]>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 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
>>>>>>>> [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>>>>>> <mailto:[e-mail]>> <mailto:[e-mail] <mailto:[e-mail]>
>>>>>>> <mailto:[e-mail] <mailto:[e-mail]>>>
>>>>>>>> https://www.ietf.org/mailman/listinfo/its
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________ its mailing list
>>>>>>> [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>>>>>> <mailto:[e-mail]>>
>>>>>>> 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: [phone]. Mobile: [phone]
>>>>>>>
>>>>>>
>>>>>> _______________________________________________ its mailing list
>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>> https://www.ietf.org/mailman/listinfo/its
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> its mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/its
>>>
>>>
>>
>> _______________________________________________
>> its mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/its
>>
>>
> 
> _______________________________________________
> its mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/its
> 
>