Re: [v6ops] [dhcwg] Considering AD sponsoring draft-bi-savi-wlan-15

["Pascal Thubert (pthubert)" <[e-mail]>]

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 <[e-mail]> On Behalf Of Lorenzo Colitti
Sent: vendredi 19 octobre 2018 02:07
To: Suresh Krishnan <[e-mail]>
Cc: [e-mail] WG <[e-mail]>; IETF IPv6 Mailing List <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [dhcwg] Considering AD sponsoring draft-bi-savi-wlan-15

On Fri, Oct 19, 2018 at 7:38 AM Suresh Krishnan <[e-mail]<mailto:[e-mail]>> 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