Pascal:
On Mon, Aug 10, 2015 at 10:05:54AM +0000, Pascal Thubert (pthubert) wrote:
> The basic APs will apply rules like 'oh, we do not expect a router on Wi-Fi
> so let's drop all RS towards wireless'. Hardcoded in the box.
> Clearly, a behavior like this that is not backed by a standard, appears to be
> working, well, until it is no more, and at worse people may 'learn' that they
> cannot have routers over Wi-Fi. Damn.
Do we have a hall of shame somewhere for such behavior ? Would like to know
what AP to avoid ;-)
> More advanced and expensive devices will learn addresses from snooping
> various protocols and devising their own way of figuring which address
> (unicast, multicast) which STA is listening to.
> But a DAD may easily be missed and a state may not be created when it should
> have. A protocol may be misinterpreted, some bug, some new version of the
> protocol. A state may be kept for too long and may cause denial of service.
Right. That multicast to unicast conversion is all non-standard, and at it's
best most likely only working (well?) for actual media streaming, not signaling.
> Such a thing is just untrue. IP works on any link, it has to. That's why we
> do IP over Foo. Now all we need is IP over Wi-Foo for radios such as .11.
> As for protocols that rely on IP multicast, it's IP's problem. If the
> underlying link layer does not have multicast, it is IP's responsibility to
> emulate it.
Right... if it can. But its a bit a question what device-model we want to
expect. I fear that the worst possible device model is something like
a homenet router with an L3 interface that is bridged by a featureless L2
switch chip onto multiple wired ports, one of which is connecting to a
bad L2 WiFi-AP. On the othrer hand is the homenet AP where the IPv6 layer
can query per-client WiFi information from L2. So, which device model
do we want to build out a solution for ?
Btw: my answer: I wish we could move the industry to the latter, but i fear
for early adoption we need to support the first too.
Cheers
Toerless
> > Or the IETF could just say that this seems like a lost cause,
> > multicast/broadcast doesn't seem to work on some L1/L2, and start
> > working on techniques that minimizes broadcast/multicast and change all
> > the protocols to reflect this new reality.
>
> Not All protocols, just IP basic things like ND, and then use IP multicast
> routing even in a ML subnet.
> For ND, it is already done for 802.15.4, RFC 6775, will need some additional
> stuff to make it generic Wi-Foo.
>
> > Something in the middle, but anyway changing the requirements on IETF
> > protocols to avoid using multicast if it can, documenting where it makes
> > sense and when it doesn't.
>
> This also has already started with the efficient ND work at 6MAN and many
> drafts from design team members.
>
> Cheers,
>
> Pascal
>
> >
> > Right now what I am seeing is that there are people who are lobbying to do
> > away with multicast as much as possible because they see that in reality
> > it's
> > not reliable on the devices they have tested it on.
> >
> > What are the odds that 802.11 could agree on a device profile for "IP use"
> > that would include reliable multicast delivery, and one that there is
> > reasonable belief that this would gain significant market adoption?
> >
> > On Mon, 10 Aug 2015, Stephens, Adrian P wrote:
> >
> > > Hello Mikael,
> > >
> > > " For me, it seems these 802.11 broadcast/multicast ACK functions
> > should be "mandatory" to implement if the device wants to support IPv4
> > and IPv6 networks.
> > >
> > > How do we achieve this?"
> > >
> > > There are two routes to "mandatory". The standard can indicate
> > something is mandatory if you support
> > > a particular feature.
> > >
> > > The second is certification. This is the not-so-simple task of
> > > persuading a
> > sufficient number of WiFi-Alliance members
> > > that it is in their economic interest to support the feature that a
> > certification program can be created. Even, given a
> > > certification, the market will still decide whether that is relevant or
> > > not.
> > >
> > >
> > > Best Regards,
> > >
> > > Adrian P STEPHENS
> > >
> > > Tel: +44 (1793) 404825 (office)
> > > Tel: +1 (971) 330 6025 (mobile)
> > >
> > > ----------------------------------------------
> > > Intel Corporation (UK) Limited
> > > Registered No. 1134945 (England)
> > > Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47
> > >
> > > -----Original Message-----
> > > From: ieee-ietf-coord [mailto:[email protected]] On
> > > Behalf Of Mikael Abrahamsson
> > > Sent: 10 August 2015 08:32
> > > To: Stephens, Adrian P
> > > Cc: Pascal Thubert (pthubert); Pat (Patricia) Thaler;
> > > [email protected]; Dan Romascanu ([email protected]); Glenn
> > > Parsons; Homenet; Eric Gray
> > > Subject: Re: [ieee-ietf-coord] [homenet] Despair
> > >
> > > On Mon, 10 Aug 2015, Stephens, Adrian P wrote:
> > >
> > >> The question in my mind is whether this discussion thread is uncovering
> > any new requirements for the 802.11 standard.
> > >
> > > Thanks for the summary, it seems correct.
> > >
> > > It might not need new 802.11 standards, but we still have an operational
> > problem in that it seems some of these standards are not universally
> > implemented by 802.11 based device vendors.
> > >
> > > IETF standards generally assume that multicast and unicast are delivered
> > with a similar level of packetloss (which is low).
> > >
> > > Not all 802.11 implementations have the multicast ACK mechanism
> > implemented, thus it would seem that multicast will be less likely to get
> > delivered to the recipient over these 802.11 implementations.
> > >
> > > For me, it seems these 802.11 broadcast/multicast ACK functions should
> > be "mandatory" to implement if the device wants to support IPv4 and IPv6
> > networks.
> > >
> > > How do we achieve this?
> > >
> > > --
> > > Mikael Abrahamsson email: [email protected]
> > >
> > > _______________________________________________
> > > ieee-ietf-coord mailing list
> > > [email protected]
> > > https://www.ietf.org/mailman/listinfo/ieee-ietf-coord
> > >
> >
> > --
> > Mikael Abrahamsson email: [email protected]
>
> _______________________________________________
> homenet mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/homenet
--
---
Toerless Eckert, [email protected]
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
