Isn't v6ops a natural fit for this, since it essentially documents an
Post by Suresh KrishnanThanks 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) <
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
*Sent:* vendredi 19 octobre 2018 02:07
*Subject:* Re: [dhcwg] Considering AD sponsoring draft-bi-savi-wlan-15
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
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
https://www.ietf.org/mailman/listinfo/dhcwg