Re: [ipwave] rereview of draft-ietf-ipwave-ipv6-over-80211ocb-45

Nabil Benamar <benamar73@gmail.com> Tue, 28 May 2019 12:47 UTC

Return-Path: <benamar73@gmail.com>
X-Original-To: its@ietfa.amsl.com
Delivered-To: its@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 117FC120125 for <its@ietfa.amsl.com>; Tue, 28 May 2019 05:47:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.736
X-Spam-Level:
X-Spam-Status: No, score=-0.736 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MANY_SPAN_IN_TEXT=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m0OgSyDBVri0 for <its@ietfa.amsl.com>; Tue, 28 May 2019 05:47:02 -0700 (PDT)
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8307512004E for <its@ietf.org>; Tue, 28 May 2019 05:47:01 -0700 (PDT)
Received: by mail-lj1-x229.google.com with SMTP id e13so17521313ljl.11 for <its@ietf.org>; Tue, 28 May 2019 05:47:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LdSjNs1oAfA9q91Qa+pVf2lvl2aAHjmpQ7gTZxECjpo=; b=LVKMKfoklWpcqQyQM+g91HU5zbpKVo1XoCDHjW0BNY+hc4WvwO1bW5zV+FCywFyP+l mpdnSMOOFv4oG4iZX6J9Tegq9qxEyN1MhPXccOYf4m9DueNYBCie7vgfKmefFO2zDVeV WJacjS4moKqrovhDyCPUL5jHqNcba9VkFzEg4EBybUkWZpZc+S8l+xCsd1eXGTYxpQkX doesjJINJkoVNEi0x241w4MDCRfM8/UMjIDBNqZCukzPJsPGyku0oQqg0F8Xe5eat2Qp xeWztlTPOqc2fHQ2uztuc4LhqHMgGGB8QE5xDY/Yk/QXQMt3M6WpcJEvt6tA4FuG8LH6 Db/Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LdSjNs1oAfA9q91Qa+pVf2lvl2aAHjmpQ7gTZxECjpo=; b=O2WfvIHxrQL3Q5XnQiFcWZprDJReqv1UoUOwir0/yp4AOzofwe4xu0Nsk2gS5ghq42 siTb86GAW5SxbpbgzpO7/lFaZn2LiOiIoHTh58ofv2Nr17ILZqIIT0C7BFypQDD+fft4 yKaUZQJzoIsaxefTTDVnT7esXf3M25AdCqVtiqLfkPu+Qn7HubMES2BhAYHE3qVq5xpS D64XUVBJ5y/9wtVwvNvDyVH7xcuDCh6PikFQGiF5LP5mm2aj2b+JJaZJje/9JWg3B1Lh wjFXteHtYTJFXnPzKp4Zlvt+JIJzlhM4DhRFHhc96zld/FfhpaTn4NZilB2aaNgORCDY gKGg==
X-Gm-Message-State: APjAAAW3zTLyA450E+L9w/z26dE4MBfc3oAaPvyWgvNsNxeh9BeHU1ym LCrhnQ69KAKapiZFKgM83bTQ2XZgdUyTnv+eBpcZoA==
X-Google-Smtp-Source: APXvYqyyMZ7evp/0Sj9g2jrQUgKueOKSHj+SrVk8NSpYBdsRbpENyEISwTDfOGzzuiWy24Qp6+p6lhhdVs4/VArPfFA=
X-Received: by 2002:a2e:8143:: with SMTP id t3mr40186168ljg.131.1559047619456; Tue, 28 May 2019 05:46:59 -0700 (PDT)
MIME-Version: 1.0
References: <MN2PR11MB3565835AA0C2813F6E093278D81D0@MN2PR11MB3565.namprd11.prod.outlook.com> <CAMugd_UDju8Psj6No1QA4fW91f7b2zXFiJ4phPSdxJEdRJjZGw@mail.gmail.com> <MN2PR11MB35656953BF97BBFF323FEB96D81D0@MN2PR11MB3565.namprd11.prod.outlook.com> <CAMugd_UAZf3SQtaOqb_X7b1ONiMuwatvGHmgsZ40_Zk0vjpJ9Q@mail.gmail.com> <MN2PR11MB3565CFFF49D3388864B66F38D81E0@MN2PR11MB3565.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB3565CFFF49D3388864B66F38D81E0@MN2PR11MB3565.namprd11.prod.outlook.com>
From: Nabil Benamar <benamar73@gmail.com>
Date: Tue, 28 May 2019 12:46:46 +0000
Message-ID: <CAMugd_WHuP0RFZNubKvhmC26r79edtw7we-v==bk+YngptbyqQ@mail.gmail.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Cc: "its@ietf.org" <its@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008bb39d0589f20ff2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/U8lsM9Ol9oMU6B_61vaNrdkdmjU>
Subject: Re: [ipwave] rereview of draft-ietf-ipwave-ipv6-over-80211ocb-45
X-BeenThere: its@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF <its.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/its>, <mailto:its-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/its/>
List-Post: <mailto:its@ietf.org>
List-Help: <mailto:its-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/its>, <mailto:its-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 May 2019 12:47:07 -0000

Hi Pascal,

Thank you for your comments. Please see ALL the changes that will be
reflected in version -46. Let me know what is missing?



Abstract


OLD:


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 how IPv6 (including addressing and

   basic ND) can be used to communicate among nodes in range of one

   another over IEEE 802.11-OCB.  Optimizations and usage of IPv6 over

   more complex scenarios is not covered and is subject of future work.




NEW:



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

        provides methods and settings, and describes limitations,

        for using IPv6 to communicate among nodes in range of one another

        over a single IEEE 802.11-OCB link with minimal change to existing
stacks.

        Optimizations and usage of IPv6 over more complex scenarios

        is not covered and is subject of future work.




Introduction



OLD:


The IPv6 network layer operates on 802.11-OCB in the same manner as

   operating on Ethernet, but there are two kinds of exceptions:


   o  Exceptions due to different operation of IPv6 network layer on

      802.11 than on Ethernet.  To satisfy these exceptions, this

      document describes an Ethernet Adaptation Layer between Ethernet

      headers and 802.11 headers.  The Ethernet Adaptation Layer is

      described Section 4.2.1
<https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-45#section-4.2.1>
.  The operation of IP on Ethernet is

      described in [RFC1042 <https://tools.ietf.org/html/rfc1042>], [RFC2464
<https://tools.ietf.org/html/rfc2464>] .





NEW:


The IPv6 network layer operates on 802.11-OCB in the same manner as

   operating on Ethernet, but there are two kinds of exceptions:


   o  Exceptions due to different operation of IPv6 network layer on

      802.11 than on Ethernet. The operation of IP on Ethernet is

      described in [RFC1042 <https://tools.ietf.org/html/rfc1042>], [RFC2464
<https://tools.ietf.org/html/rfc2464>] .



3.  Communication Scenarios where IEEE 802.11-OCB Links are Used




OLD:



   The IEEE 802.11-OCB Networks are used for vehicular communications,

   as 'Wireless Access in Vehicular Environments'.  The IP communication

   scenarios for these environments have been described in several

   documents;




NEW:


The IEEE 802.11-OCB Networks are used for vehicular communications,

as 'Wireless Access in Vehicular Environments’. In particular, we refer the
reader to [I-D.ietf-ipwave-vehicular-networking], that lists some scenarios
and  requirements for IP in Intelligent Transportation Systems.



OLD:


The link model is the following: STA --- 802.11-OCB --- STA.  In

   vehicular networks, STAs can be IP-RSUs and/or IP-OBUs.  While

   802.11-OCB is clearly specified, and the use of IPv6 over such link

   is not radically new, the operating environment (vehicular networks)

   brings in new perspectives.



NEW:



The link model is the following: STA --- 802.11-OCB --- STA.

In vehicular networks, STAs can be IP-RSUs and/or IP-OBUs.

    All links are assumed to be P2P and multiple

    links can be on one radio interface. While 802.11-OCB is clearly
specified,
and the use of IPv6 over such link is not radically new, the operating
environment (vehicular networks) brings in new perspectives.



*4*
<https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-45#section-4>*.
IPv6 over 802.11-OCB*



OLD:



The default MTU for IP packets on 802.11-OCB MUST be 1500 octets.  It

   is the same value as IPv6 packets on Ethernet links, as specified in

   [RFC2464 <https://tools.ietf.org/html/rfc2464>].  This value of the MTU
respects the recommendation that

   every link on the Internet must have a minimum MTU of 1280 octets.




NEW:



The default MTU for IP packets on 802.11-OCB is inherited

          from RFC2464 and is 1500 octets. This value

          of the MTU respects the recommendation that every link on

          the Internet must have a minimum MTU of 1280 octets (stated

          in <xref target="RFC8200"/>, and the recommendations

          therein, especially with respect to fragmentation).




4.2.  Frame Format




OLD:



   IP packets MUST be transmitted over 802.11-OCB media as QoS Data

   frames whose format is specified in IEEE 802.11(TM) -2016

   [IEEE-802.11-2016].



NEW:


   IP packets MUST be transmitted over 802.11-OCB media as QoS Data

   frames whose format is specified in IEEE 802.11 spec.



OLD:


The IPv6 packet transmitted on 802.11-OCB MUST be immediately

preceded by a Logical Link Control (LLC) header and an 802.11 header.



NEW:


IPv6 packet transmitted on 802.11-OCB are immediately preceded

by a Logical Link Control (LLC) header and an 802.11 header



OLD:


In the 802.11 header, the value of the

   Subtype sub-field in the Frame Control field MUST be set to 8 (i.e.

   'QoS Data'); the value of the Traffic Identifier (TID) sub-field of

   the QoS Control field of the 802.11 header MUST be set to binary 001

   (i.e.  User Priority 'Background', QoS Access Category 'AC_BK').


NEW:


 The mapping to the 802.11 data service MUST

 use a ‘priority’ value of 1, which specifies the use of QoS

 with a “Background” user priority.



OLD:


To simplify the Application Programming Interface (API) between the

   operating system and the 802.11-OCB media, device drivers MAY

   implement an Ethernet Adaptation Layer that translates Ethernet II

   frames to the 802.11 format and vice versa.  An Ethernet Adaptation

   Layer is described in


NEW:



To simplify the Application Programming Interface (API)

  between the operating system and the 802.11-OCB media,

  device drivers MAY implement IPv6 over Ethernet per RFC 2464

      and then a frame translation from 802.3 to 802.11 in order

      to  minimize the code changes.



OLD:


4.4.  Stateless Autoconfiguration



   There are several types of IPv6 addresses [RFC4291], [RFC4193], that

   MAY be assigned to an 802.11-OCB interface.  This section describes

   the formation of Interface Identifiers for IPv6 addresses of type

   'Global' or 'Unique Local'.  For Interface Identifiers for IPv6

   address of type 'Link-Local' see Section 4.3.



NEW:


The steps a host takes in deciding how to

      autoconfigure its interfaces in IP version 6 are described in <xref

  target='RFC4862'/>. This section describes

  the formation of Interface Identifiers for IPv6 addresses of

  type 'Global' or 'Unique Local'.  For Interface Identifiers

  for IPv6 address of type 'Link-Local' see <xref

  target='ll'/>.



OLD:


The Interface Identifier for an 802.11-OCB interface is formed using

   the same rules as the Interface Identifier for an Ethernet interface;



NEW:


The RECOMMENDED method for forming

          stable Interface Identifiers (IIDs) is described in <xref

          target='RFC8064'/>.  The method of forming IIDs described in

          section 4 of <xref target='RFC2464'/> MAY be used during

          transition time, in particular for IPv6 link-local

          addresses.



OLD:


4.5.1.  Address Mapping -- Unicast



   The procedure for mapping IPv6 unicast addresses into Ethernet link-

   layer addresses is described in [RFC4861].



NEW:



4.5.1.  Address Mapping -- Unicast



   This draft is scoped for AR and DAD per RFC 4861.




OLD:



4.5.2.  Address Mapping -- Multicast



<Snap>

                                             These issues may be

   exacerbated in OCB mode.  Solutions for these problems SHOULD

   consider the OCB mode of operation.



NEW:



These issues may be exacerbated in OCB mode.  Future improvement to this
specification SHOULD consider solutions for these problems.



OLD:


The subnet structure on which the Neighbor Discovery

  protocol (ND) on OCB works ok is a single-link subnet; the

  status of ND operation on a subnet that covers multiple OCB

  links that repeat the signal at PHY layer, or the messages

  at MAC layer, is unknown.



NEW:



An IPv6 subnet on which Neighbor Discovery protocol (ND) can be used

can be mapped on an OCB network iff all nodes share a single broadcast

Domain, which is generally the case for P2P OCB links;

the status of ND operation on a subnet that covers multiple OCB links

That are not fully overlapping (NBMA) is not in scope.

OLD:

The baseline Neighbor Discovery protocol (ND) [RFC4861
<https://tools.ietf.org/html/rfc4861>] MUST be used over 802.11-OCB links.


NEW:

The baseline Neighbor Discovery protocol (ND) [RFC4861] MUST be supported
over 802.11-OCB links.


 OLD:


Transmitting ND packets may prove to have

   some performance issues.  These issues may be exacerbated in OCB

   mode.  Solutions for these problems SHOULD consider the OCB mode of

   operation.  The best of current knowledge indicates the kinds of

   issues that may arise with ND in OCB mode; they are described in

   Appendix J.


NEW:


Transmitting ND packets may prove to have some performance issues.  These
issues may be exacerbated in OCB

   mode.  Future solutions to OCB should consider solutions for avoiding
broadcast.  The best of current knowledge indicates the kinds of issues
that may arise with ND in OCB mode; they are described in Appendix J.


OLD:


Within the IPsec Security Architecture [RFC4301], the IPsec AH and

   ESP headers [RFC4302] and [RFC4303] respectively, its multicast

   extensions [RFC5374], HTTPS [RFC2818] and SeND [RFC3971] protocols

   can be used to protect communications.  Further, the assistance of

   proper Public Key Infrastructure (PKI) protocols [RFC4210] is

   necessary to establish credentials.  $


NEW:


Removed













Best regards
Nabil Benamar
-------------------
نبيل بنعمرو







On Tue, May 28, 2019 at 8:49 AM Pascal Thubert (pthubert) <
pthubert@cisco.com> wrote:

> Hello Nabil:
>
>
>
> In the next rev I expect to see text in the intro that states the scope of
> reusing legacy stacks with minimal changes.
>
>
>
> Expressed that way, the discussion on legacy ND only and using the
> Ethernet distribution system and then a frame translation to 802.11, all
> makes full sense.
>
> Also, this prepares for the work that the group has already started, which
> involves new stack elements better suited for OCB.
>
>
>
> This should also be in the title. Suggestion for the new title:
>
>
>
>
>
> Minimal support for IPv6 over IEEE Std 802.11 Networks operating Outside
> the Context of a Basic Service Set
>
>
>
>
>
> The ‘minimal’ avoids the risk that the reader thinks that this draft has
> it all and that IPWAVE can close after that.
>
>
>
> All the best,
>
>
>
> Pascal
>
>
>
> *From:* Nabil Benamar <benamar73@gmail.com>
> *Sent:* lundi 27 mai 2019 17:12
> *To:* Pascal Thubert (pthubert) <pthubert@cisco.com>
> *Cc:* its@ietf.org
> *Subject:* Re: [ipwave] rereview of
> draft-ietf-ipwave-ipv6-over-80211ocb-45
>
>
>
> Hi Pascal,
>
>
>
> We are converging :)
>
>
>
> See below
>
>
>
>
>
> Best regards
>
> Nabil Benamar
>
> -------------------
>
> نبيل بنعمرو
>
>
>
>
>
>
>
> On Mon, May 27, 2019 at 2:47 PM Pascal Thubert (pthubert) <
> pthubert@cisco.com> wrote:
>
> Hello Nabil:
>
>
>
> I removed the places where we already agree. Please see below for the
> remaining details
>
>
>
> Ø  This should be out of scope and inherited from IPv6 over WiFi. If the
> draft does not exist then let us do one, at 6MAN.
>
> Yes, I support this idea to initiate a new draft in 6MAN. I'm in!
>
> Ø  The introduction should clatify the scope, which appears to be do with
> what existing stacks can do and (sometimes) see what’s missing.
>
> Here is the new introduction (first paragraph), are we missing something
> else?
>
>
>
> "This document describes the transmission of IPv6 packets on IEEE Std
>
> 802.11-OCB networks [IEEE-802.11-2016] (a.k.a "802.11p" see
>
> Appendix B, Appendix C and Appendix D). This involves the layering
>
> of IPv6 networking on top of the IEEE 802.11 MAC layer, with an LLC
>
> layer. Compared to running IPv6 over the Ethernet MAC layer, there
>
> is no modification expected to IEEE Std 802.11 MAC and Logical Link
>
> sublayers: IPv6 works normally over a single IEEE 802.11-OCB link,
>
> with an LLC layer. Multi-link scenarios are out of scope for the
>
> present document."
>
>
>
>
>
> Pascal, I have just received a detailed review from some IEEE-802.11
> members, thanks to Dorothy! One of the recommendation is to remove section
> 4.2.1 completely.
>
>
>
> Ø    Good, we are converging.
>
>
>
>
>
>
>
> I agree. It seems that by describing specific values, the text is
> redundant with what’s already in IEEE Std 802.11-2016
>
>
>    - In the <reference> tag to the IEEE spec just use <date/> . This
>    actually removes the date. Also please remove -2016 from the spec name,
>    just leave generic 802.11 dateless.
>
> Ok.
>
>
>    -
>    - Placing a date is misguided since we do not have a dependency on one
>    particular version of 802.11. Indeed we want your spec to apply to all
>    versions starting current, which is what is implied by dateless.
>
> That's perfect.
>
>
>    -
>
>
>
>
>
>
>
> Ø  Are we sure of that, don’t we map QoS from ToS bits as usual with 11e?
>
>
>
> Here is the new text to replace that paragraph:
>
>
>
> " “The IPv6 packet transmitted on 802.11-OCB MUST be immediately preceded
> by a Logical Link Control (LLC) header and an 802.11 header. In the LLC
> header, and in accordance with the EtherType Protocol Discrimination (EPD,
> see Appendix E
> <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-45#appendix-E>),
> the value of the Type field MUST be set to 0x86DD (IPv6). The mapping to
> the 802.11 data service MUST use a ‘priority’ value of 1, which specifies
> the use of QoS with a “Background” user priority."
>
>
>
> Ø    Can’t we use different QoS values like we can on WiFi?
>
> That was the recommendation of IEEE 802.11 members, and I updated the
> draft based on your review and their recommendations. Please feel free to
> suggest other text here.
>
>
>
>
>
>
>
>    To simplify the Application Programming Interface (API) between the
>
>    operating system and the 802.11-OCB media, device drivers MAY
>
>    implement an Ethernet Adaptation Layer that translates Ethernet II
>
>    frames to the 802.11 format and vice versa.  An Ethernet Adaptation
>
>    Layer is described in Section 4.2.1.
>
>
>
> Ø  Do not call that an adaptation layer. The may refers to using an
> Ethernet stack and then a translation from Ethernet Frames to 802.11 frames
> as specified by IEEE.
>
> What do you suggest instead?
>
>
>
>
>
> Ø    Maybe that “an implementation may IPv6 over Ethernet per RFC 2464
> and then a frame translation from 802.3 to 802.11 in order to  minimize the
> code changes”.
>
> Ø    If minimal impact on the stack is the actual goal of this draft,
> which I think it is. This is what justifies publish this hastily and then
> do the real work that implies larger changes.
>
> Ø
>
> Sounds good for me!
>
>
>
>
>
>
>
>
>
> 4.4.  Stateless Autoconfiguration
>
>
>
>    There are several types of IPv6 addresses [RFC4291], [RFC4193], that
>
>    MAY be assigned to an 802.11-OCB interface.  This section describes
>
>    the formation of Interface Identifiers for IPv6 addresses of type
>
>    'Global' or 'Unique Local'.  For Interface Identifiers for IPv6
>
>    address of type 'Link-Local' see Section 4.3.
>
>
>
> Ø  Not really interesting. More important is to say that autoconf is
> defined in RFC 4862 and that is missing.
>
> Didn't get your point! What is missing?
>
>
>
>
>
>
>
> Ø    IPv6 autoconf is described in RFC 4862. This section does not refer
> to it, but rather duplicates the previous about address types, which is far
> from interesting.
>
> Ø    I suggest you remove the text above and add a sentence that roughly
> introduce RFC 4862. Note that RFC 8505 does not change the
> autoconfiguration though it changes the way DAD is achieved.
>
>
>
>
>
> Ok. I will include it in -46
>
>
>
>
>
> Ø  MUST +> MAY. Say the scope of this doc only considers ND but neither
> RFC 8505 nor IPWAVE drafts.
>
>
>
> Here is the new text as agreed last time with Brian:
>
>
>
> "The baseline Neighbor Discovery protocol (ND) [RFC4861] MUST be
>
> supported over 802.11-OCB links."
>
>
>
>
>
>
>
> Ø   Yes, that works.
>
>
>
>
>
> Ø  Remove or turn it the other way around like future solutions to OCB
> should consider solutions for avoiding broadcast.
>
> I will reformulate in the following manner:
>
>
>
> Transmitting ND packets may prove to have some performance issues.  These
> issues may be exacerbated in OCB
>
>    mode.  Future solutions to OCB should consider solutions for avoiding
> broadcast.  The best of current knowledge indicates the kinds of issues
> that may arise with ND in OCB mode; they are described in Appendix J.
>
>
>
>
>
> Ø    Good
>
>
>
>
>
>
>
>
>
> All the best,
>
>
>
> Pascal
>
>
>
>
>
> Thank you once again.
>
>
>
> I will publish version 46 soon.
>
>
>
>
>
>
>
> Ø    Please ping me when done; do not forget to scope the document so
> that it is minimizing changes to existing stack and leveraging Ethernet
> implementation, with IPv6 ND and so on, and a focus on P2P over link local.
>
>
>
> All the best,
>
>
>
> Pascal
>
>
>
> Thank you, Pascal for your time.
>