Isn't v6ops a natural fit for this, since it essentially documents an
operational practice that is implemented by real hardware?

On Tue, Oct 23, 2018 at 11:29 AM Suresh Krishnan <[email protected]> wrote:

> Thanks Lorenzo, Pascal and Bernard for your comments. I have asked the
> authors to respond to your comments on the intarea mailing list. Also,
> Bernard suggested a 802.11 review of this draft, and I intend to pursue
> that as well if the draft progresses. I could not find a WG that would be a
> exact fit for this work, and that is why I decided to cast the net wide for
> potentially relevant WGs in the hope of getting reviews. I will be
> extremely happy if this can be hosted in a WG instead and get sufficient
> review there.
>
> Regards
> Suresh
>
> On Oct 19, 2018, at 10:44 AM, Pascal Thubert (pthubert) <
> [email protected]> wrote:
>
> Dear all :
>
> I agree with Lorenzo, this scheme is at a high level what we can find in
> commercial products, and I have first-hand experience on that.
>
> As an informational document, this RFC could be a useful reference to
> consider if we were to change the protocols in a way that would impact
> those existing and non-standard snooping behaviors.
> Snooping has proven to be very useful, but as one may guess, it is not
> reliable; it may miss packets, may fail to create bindings, may point on an
> incorrect location as well.
>
> So I’d say that if we publish as RFC,  we should also indicate that with
> draft-ietf-6lo-ap-nd, we (will) have a more robust solution for devices
> that are willing to announce themselves.
>
> Cheers,
>
> Pascal
> *From:* ipv6 <[email protected]> *On Behalf Of *Lorenzo Colitti
> *Sent:* vendredi 19 octobre 2018 02:07
> *To:* Suresh Krishnan <[email protected]>
> *Cc:* [email protected] WG <[email protected]>; IETF IPv6 Mailing List <
> [email protected]>; [email protected]; [email protected]; [email protected];
> [email protected]
> *Subject:* Re: [dhcwg] Considering AD sponsoring draft-bi-savi-wlan-15
>
> On Fri, Oct 19, 2018 at 7:38 AM Suresh Krishnan <[email protected]> wrote:
>
>    I am considering AD sponsoring the following draft
>
> https://tools.ietf.org/html/draft-bi-savi-wlan-15
>
> that describes a source address validation solution for WLAN. If you have
> any concerns
> either with the content of the draft, or about me AD sponsoring it please
> let me know before 2018/11/18.
>
>
> I skimmed the draft. It looks well-written, and it addresses an important
> problem which I think is probably solved in (different?) proprietary ways
> on various implementations in the field today. I'm not very familiar with
> the AD sponsorship process, so not sure what the has to happen from a
> process perspective. But I think the document requires further review,
> especially given that it's making statements about very widely-deployed
> scenarios (IPv6 over wifi). Should the document be adopted by a WG such as
> 6man or v6ops? If not, it should definitely be reviewed by those WGs.
>
> As a concrete example, here are some things that need to be resolved
> before the document advances:
>
>    1. The proposed scheme relies on DAD packets to create mapping
>    entries. That means that if a DAD packet is lost (which can happen even
>    though 802.11 employs retransmissions at L2), a station could have an IPv6
>    address that doesn't work with no indication that it's not working. This is
>    basically a non-recoverable outage. Perhaps the document should specify
>    another solution instead, e.g., it could say that mapping entries could be
>    created when a wired station receives a solicited NA response from a
>    wireless station.
>    2. The document says that the lifetime of SLAAC addresses is the
>    address lifetime, but the network has no way of knowing what the address
>    lifetime is because it depends on which RA(s) the host has received.
>
>
> Cheers,
> Lorenzo
>
>
> _______________________________________________
> dhcwg mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dhcwg
>
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg

Reply via email to