Subject: Re: [MBONED] [homenet] 802.11 is just fine for IPv6 [was: Despair]

From: Toerless Eckert <[email-masked]>
Date: Mon, 10 Aug 2015 01:49:31 -0700

Hmm... the multicast to unicast conversion described in there looks fairly
weak. It doesn't discuss any problems with IGMPv2/MLDv1 wrt to report
suppression and how to deal with that for example. Or the challenge that
hosts may not be happy about receiving IP multicast packets with unicast MAC
destination address. If an organization has the ability to specify behavior
f HNID's (as in 5.2), then it would be a lot better to specify those
refinemenet (eg: translate back to L2-multicast in downstream HNID's, L2 unicast
IGMp queries to inhibit report suppression o proxy into IGMPv3/MLDv2, etc. pp.)

What interaction does IETF have with that initiative ? 
Does it make sense / is it possible to engage with these folks ?
Anybody hee workin over there ?

Seems they are planning to be gone anyhow, so just likley the will create from existing
docs some half-baked solution ?

http://www.homegatewayinitiative.org/news/PressReleases/PR11_HGI_Conclusion_FINAL.pdf

Cheers
    Toerless

On Fri, Aug 07, 2015 at 09:16:27AM +0000, Hartog, F.T.H. (Frank) den wrote:
> HGI is requesting Home Gateways to perform Wi-Fi multicast-to-unicast conversion, see http://www.homegatewayinitiative.org/publis/P_HGI01628R19.pdf . 
> 
> Regards, 
> 
> Frank
> ________________________________________
> From: homenet [[email-masked]] on behalf of Juliusz Chroboczek [[email-masked]]
> Sent: Friday, August 07, 2015 10:21 AM
> To: Mikael Abrahamsson
> Cc: Homenet
> Subject: Re: [homenet] 802.11 is just fine for IPv6 [was: Despair]
> 
> > I don't see how you can claim that ISIS can't use multicast on wifi
> > because multicast on wifi doesn't work,
> 
> I have never claimed that.  Babel uses multicast on wifi.  (Once again,
> Mikael, I request that you stop misrepresenting my position.)
> 
> I think that the multicast reduction technique used by David in IS-IS and
> by Markus in HNCP are a smart idea, and I intend to implement something
> similar in a private branch of Babel in order to test how much of an
> improvement it gives (the protocol explicitly allows that, so it's merely
> an implementation change).  I won't merge it into the mainline until I get
> a sufficient set of experimental data, which could take some time.
> 
> If you can publish your experimental data before then, that would be helpful.
> 
> -- Juliusz
> 
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet
> This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.
> 
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

-- 
---
Toerless Eckert, [email-masked]

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 10 Aug 2015 11:26:49 +0200 (CEST)

(included [email-masked] and also changed subject to something more 
appropriate)

As far as I can tell, so far people have told IETF it's their job to 
reduce multicast to make IP based protocol "work" on 802.11 media. That's 
at least what I have been seeing. Considering the reactions from other 
parties, it seems the "multicast sucks on 802.11" is something 802.11 
hasn't heard of before.

The only thing IETF can do is to use less multicast, and the obvious way 
of solving it is to just replicate into unicast. This seems like a 
suboptimal way to work around the problem if there are a lot of nodes.

>From what I read below, one way out of this is the IETF making a clear 
statement that multicast is an integral part of IP networking, and if a 
medium doesn't support delivering multicast frames in a similarily 
reliable fashion to unicast, it's not suited to carrying IP based 
protocols (or any other protocol that uses L2 broadcast/multicast).

It seems to me that there are a few paths that the IETF could go:

Write an RFC stating requirements on L1/L2 protocols when it comes to 
unicast, multicast and broadcast handling of packets. This could include 
options for mechanisms that turned multicast/broadcast into unicast that 
certain medias could have as requirements. Then IEEE could create a device 
profile that would fulfil these requirements, possibly add a 
certification, and then try to get market pressure to require devices to 
support this profile. The IETF wouldn't change its mind about how 
multicast is used in its protocols after this, but just say "this is the 
reality, please deal with it when you create L1/L2 that's supposed to 
carry IP".

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.

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.

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-masked]] On Behalf Of Mikael Abrahamsson
> Sent: 10 August 2015 08:32
> To: Stephens, Adrian P
> Cc: Pascal Thubert (pthubert); Pat (Patricia) Thaler; [email-masked]; Dan Romascanu ([email-masked]); 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-masked]
>
> ieee-ietf-coord mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ieee-ietf-coord
>

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 10 Aug 2015 12:09:26 +0200 (CEST)

On Mon, 10 Aug 2015, Stephens, Adrian P wrote:

> [Adrian P Stephens]
> This problem is nothing new.  We know about the relative performance of multicast vs unicast.
> Saying it "sucks" is not very helpful.   Unlicensed spectrum is free.  You are getting more than you are paying for :0).

I don't see how it's relevant that the spectrum is free? Even if this was 
done in a licensed spectrum I would still get 10% packet loss because 
multicast isn't ACKed, right?

> The technical solution is surely to add a class of service specification to multicast packs that indicates their sensitivity to loss.
> The point is that the AP is in possession of a lot of data about individual nodes that may help it make an informed decision
> between unicast and multicast.
>
> Moving the duplication into the IP layer ensures uninformed decisions.

That's my opinion as well. Thanks for confirming it.

> [Adrian P Stephens]
> <irony type="british; very-subtle">
> I'm guessing you will be the first to turn off the 802.11 networking on your devices when the IETF makes such a statement.
> </irony>

Well, since it seems 802.11 has mechanisms to make multicast delivery 
decently reliable, it seems it would be suited if the implementation 
actually included that mechanism. If it's omitted by the implementor, it's 
not. Currently I have no idea if my home network includes GCR or not. I 
also don't know if GCR needs client support.

> [Adrian P Stephens]
> As I indicated in my earlier post,  there are multiple actors here.
> The odds are pretty good that 802.11 will respond to a clear requirement to handle multicast specially.
> If has,  after all,  already done this twice.

What do you mean "specially"? What I've been bringing up is not to treat 
it specially, it's to treat it so that it works similarily to unicast. 
>From my point of view, without the GCR or similar mechanism, multicast is 
treated specially, ie it's being treated worse than unicast.

> What are the odds that the WFA will create a new certification?
> What are the odds that it is successful in the market?
>
> These are presently unknowns,  and will remain that way until tried.

I have no history on this kind of subject, someone who has been involved 
in 802.11 perhaps could make an educated guess and share an opinion on 
what might be the path that has the best odds to succeed?

http://eprints.networks.imdea.org/275/1/L.%20Eznarriaga-MsC%20Thesis-September%202011.pdf

Btw, could you confirm that GCR in 802.11aa is something that is needed in 
both AP and clients to work? It seems like it would need to be. How widely 
implemented is it in clients? Is this a hardware issue or driver issue? 
Does the operating system need to support it as well?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 10 Aug 2015 12:15:58 +0200 (CEST)

On Mon, 10 Aug 2015, Pascal Thubert (pthubert) wrote:

>> medium doesn't support delivering multicast frames in a similarily reliable
>> fashion to unicast, it's not suited to carrying IP based protocols (or any
>> other protocol that uses L2 broadcast/multicast).
>
> 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.

Yes, but what about when multicast is there but it's less reliable 
compared to unicast? Is this also IPs problem?

Again, if if's IPs problem then if 802.11 would just clearly state that 
this is the case, then we have a way forward. I just hope 802.11 
understand that it'll see a lot more unicast coming its way and be 
prepared to handle it.

> This also has already started with the efficient ND work at 6MAN and many drafts from design team members.

Remember to get IETF chair to say this and give this as a clear 
directional statement how things should be done going forward, just the 
same way it's been said regarding security and encryption. I have little 
problem with this approach as long as we have consensus that this is the 
way things should be done.

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 10 Aug 2015 03:26:59 -0700

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.

> 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

> > 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.
> 

> Cheers,
> Pascal
> > 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.
> > 
> > > " 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?"
> > >
> > > 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
> > > Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47
> > >
> > > Cc: Pascal Thubert (pthubert); Pat (Patricia) Thaler;
> > > [email-masked]; Dan Romascanu ([email-masked]); Glenn
> > > Parsons; Homenet; Eric Gray
> > >> The question in my mind is whether this discussion thread is uncovering
> > any new requirements for the 802.11 standard.
> > >
> > > 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?
> > >
> > > --

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 10 Aug 2015 13:03:08 +0200 (CEST)

On Mon, 10 Aug 2015, Pascal Thubert (pthubert) wrote:

> Yes it is. IP over Foo must indicate if IP multicast over a link uses L2 mechanisms or not.

Ok, so am I interpreting you correctly that there are three profiles for 
L1/L2 mediums:

1. Multicast works approximately the same way as unicast (packet loss)
2. Multicast works worse than unicast and should be minimized
3. Multicast not supported

So what we're missing is taking into account the #2 profile in the IETF, 
because so far we've only really understood that #1 and #3 exists?

> For Wi-Fi, there is no multicast support and it is sufficiently clear now that relying on broadcast is not a good idea.

But I keep hearing from the 802.11 experts (at least they seem to be) that 
there are 802.11 mechanisms that seem to make multicast work well enough 
and that there are power upsides to using multicast?

> Rather, a good idea could be to build a multilink subnet with APs that 
> are also routers to serve the wireless edge, whereby the Ethernet 
> backbone can rely on L2 broadcast while the wireless edge is routed. 
> Many LLNs work like this. Why should Wi-Fi be an exception?

Well, I am not wireless expert, I don't know if it makes more sense to 
treat each device to its own subnet and thus send RAs to each and every 
one of them as needed, or if it makes sense to have some kind of multicast 
mechanism and make sure that they all get this multicast packet in a 
shared subnet. Your suggestion seems perfectly fine for me from an IP 
point of view, actually I prefer that option as well. Basically each host 
has its own /64.

> I'd hate this, IEEE telling IETF what to do. Just like IETF telling IEEE 
> to do an immensely scalable L2 multicast support so that Solicited Node 
> Multicast appears so cool on a switched fabric? Does not seem to work 
> either.
>
> The IETF has to decide if it wants to design IP over 802.11 - or Wi-Foo 
> in general which would be my take. And then the IETF has to decide if it 
> wants to design IP over a mix of Wi-Fi and Ethernet. IEEE people may 
> join the effort so we do the job right.

Are there more types of profiles we need? Does it make more sense to send 
a multicast packet if there are more (or less) than X nodes in a subnet, 
send unicast to each and every one of them if it's less (or more) than Y. 
Should each individual device be able to say what it prefers in case we're 
mixing battery powered devices and wired devices in the same place?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 10 Aug 2015 13:54:26 +0200 (CEST)

On Mon, 10 Aug 2015, Pascal Thubert (pthubert) wrote:

> Unsure about your profile, Mikael. Ethernet would be a #2 by now, only 
> things like sat-links could still be #1s. So the work would really be to

I don't agree, wired ethernet is still #1 if you ask me.

> figure out what to do with the varieties of your #2. My question is 
> rather whether IP over 802.11 should be operated like IP over Ethernet 
> or like IP over 802.15.4.

That is a good question.

> The multilink subnet is not one /64 per wireless device as you indicate. 
> That model certainly works too, and was deployed, but with it, a set of 
> 64 bits identifies and routes to a device, so we are mostly back to a 
> world of IPv4 with just DHCP (PD) and identifiers of 64 bits instead of 
> 32.
>
> The multilink subnet is a single large subnet encompassing the whole 
> ESS, Ethernet + Wi-Fi. It is really a Layer-3 ESS, based on the same 
> ideas as the Layer-2 is.
>
> In that model, the association of a wireless device associates the IP 
> unicast and multicast addresses with the MAC address, and the AP acts as 
> a router and performs proxy ND over the Ethernet backbone on behalf of 
> the wireless devices. That way, the ND NS are never multicast over the 
> wireless. In practice, the association of IP addresses should be done as 
> part of ND, and that is what RFC 6775 does.

Ok, thanks for explaining what you meant in more detail. I think I got it 
now.

---

From: "Stephens, Adrian P" <[email-masked]>
Date: Mon, 10 Aug 2015 09:39:43 +0000

Hello Mikael,

Please see my responses embedded below...

Best Regards,
 
Adrian P STEPHENS

-----Original Message-----
From: ieee-ietf-coord [mailto:[email-masked]] On Behalf Of Mikael Abrahamsson
Sent: 10 August 2015 10:27
To: Stephens, Adrian P
Cc: [email-masked]; Dan Romascanu ([email-masked]); Glenn Parsons; [email-masked]; Homenet; Eric Gray
Subject: [ieee-ietf-coord] Multicast on 802.11

As far as I can tell, so far people have told IETF it's their job to reduce multicast to make IP based protocol "work" on 802.11 media. That's at least what I have been seeing. Considering the reactions from other parties, it seems the "multicast sucks on 802.11" is something 802.11 hasn't heard of before.

[Adrian P Stephens] 

The only thing IETF can do is to use less multicast, and the obvious way of solving it is to just replicate into unicast. This seems like a suboptimal way to work around the problem if there are a lot of nodes.

[Adrian P Stephens] 

>From what I read below, one way out of this is the IETF making a clear
statement that multicast is an integral part of IP networking, and if a medium doesn't support delivering multicast frames in a similarily reliable fashion to unicast, it's not suited to carrying IP based protocols (or any other protocol that uses L2 broadcast/multicast).

[Adrian P Stephens] 

Write an RFC stating requirements on L1/L2 protocols when it comes to unicast, multicast and broadcast handling of packets. This could include options for mechanisms that turned multicast/broadcast into unicast that certain medias could have as requirements. Then IEEE could create a device profile that would fulfil these requirements, possibly add a certification, and then try to get market pressure to require devices to support this profile. The IETF wouldn't change its mind about how multicast is used in its protocols after this, but just say "this is the reality, please deal with it when you create L1/L2 that's supposed to carry IP".

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.

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.

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.

that would include reliable multicast delivery, and one that there is reasonable belief that this would gain significant market adoption?

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 10 Aug 2015 10:05:54 +0000

Hello Mikael

> The only thing IETF can do is to use less multicast, and the obvious way of
> solving it is to just replicate into unicast. This seems like a suboptimal way
> to work around the problem if there are a lot of nodes.

Many products do that. But then people immediately think about sending unicast only to those who need the packet. Good idea isn't it? 

Because none of that is standard, different special sauces from different vendors will cause interoperation issues. Think about the impact of firewalls that we have suffered over the years, applied to the network operation down to the basic protocols.

Vendor-specific magic heuristics about how to play with snooped state that are deployed today will have unpredictable effects on new protocols in the future that expect standard behavior from deployed boxes. 

Add to that new host behaviors like rapid renewal of IP addresses for privacy reasons and you see that the good idea above was the recipe to first shoot oneself in the foot and then all the way up.

> profile that would fulfil these requirements, possibly add a certification, and
> then try to get market pressure to require devices to support this profile.
> The IETF wouldn't change its mind about how multicast is used in its
> protocols after this, but just say "this is the reality, please deal with it when
> you create L1/L2 that's supposed to carry IP".
> 

That is not my conception of IP. That would be Inter-Some-Net protocol now.

Cheers,

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 10 Aug 2015 10:43:56 +0000

> >> statement that multicast is an integral part of IP networking, and if
> >> a medium doesn't support delivering multicast frames in a similarily
> > 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.
> 
> Yes, but what about when multicast is there but it's less reliable compared
> to unicast? Is this also IPs problem?

If not, a router learns from MLD the state it needs to figure to which devices it should copy a given packet.

Rather, a good idea could be to build a multilink subnet with APs that are also routers to serve the wireless edge, whereby the Ethernet backbone can rely on L2 broadcast while the wireless edge is routed. Many LLNs work like this. Why should Wi-Fi be an exception?

> 
> Again, if if's IPs problem then if 802.11 would just clearly state that this is
> the case, then we have a way forward. I just hope 802.11 understand that
> it'll see a lot more unicast coming its way and be prepared to handle it.
 
I'd hate this, IEEE telling IETF what to do. Just like IETF telling IEEE to do an immensely scalable L2 multicast support so that Solicited Node Multicast appears so cool on a switched fabric? Does not seem to work either. 

The IETF has to decide if it wants to design IP over 802.11 - or Wi-Foo in general which would be my take. And then the IETF has to decide if it wants to design IP over a mix of Wi-Fi and Ethernet. IEEE people may join the effort so we do the job right.

Cheers,

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 10 Aug 2015 11:36:59 +0000

Unsure about your profile, Mikael. Ethernet would be a #2 by now, only things like sat-links could still be  #1s. So the work would really be to figure out what to do with the varieties of your #2. My question is rather whether IP over 802.11 should be operated like IP over Ethernet or like IP over 802.15.4.

Trouble is, some multicast ore more important than others. E.g. you miss an RA, usually no harm done, wait for the next or RS to force one. You missed a DAD, the protocol failed. If we start retrying DADs, we make the broadcast situation even worse. So to your point about energy, Wi-Foo may decide to broadcast some messages, unicast others multiple times, and at some point change the IP protocols so that the protocols operate differently. 

The IETF already made these steps for 802.15.4. RAs are still broadcasted but DAD was changed to be reliable and unicast-based.

The multilink subnet is not one /64 per wireless device as you indicate. That model certainly works too, and was deployed, but with it,  a set of 64 bits identifies and routes to a device, so we are mostly back to a world of IPv4 with just DHCP (PD) and identifiers of 64 bits instead of 32.

The multilink subnet is a single large subnet encompassing the whole ESS, Ethernet  + Wi-Fi. It is really a Layer-3 ESS, based on the same ideas as the Layer-2 is.

In that model, the association of a wireless device associates the IP unicast and multicast addresses with the MAC address, and the AP acts as a router and performs proxy ND over the Ethernet backbone on behalf of the wireless devices. That way, the ND NS are never multicast over the wireless. In practice, the association of IP addresses should be done as part of ND, and that is what RFC 6775 does.
 
Cheers,

Pascal

Cheers,

Pascal

> From: Mikael Abrahamsson [mailto:[email-masked]]
> Sent: lundi 10 août 2015 13:03
> To: Pascal Thubert (pthubert) <[email-masked]>
> Cc: [email-masked]; Dan Romascanu ([email-masked])
> <[email-masked]>; Stephens, Adrian P
> <[email-masked]>; Glenn Parsons
> <[email-masked]>; [email-masked]; Homenet
> <[email-masked]>; Eric Gray <[email-masked]>
> Subject: RE: [ieee-ietf-coord] Multicast on 802.11
> 
> 1. Multicast works approximately the same way as unicast (packet loss) 2.
> Multicast works worse than unicast and should be minimized 3. Multicast
> not supported
> 
> there are 802.11 mechanisms that seem to make multicast work well
> enough and that there are power upsides to using multicast?
> 
> Well, I am not wireless expert, I don't know if it makes more sense to treat
> each device to its own subnet and thus send RAs to each and every one of
> them as needed, or if it makes sense to have some kind of multicast
> mechanism and make sure that they all get this multicast packet in a shared
> subnet. Your suggestion seems perfectly fine for me from an IP point of
> view, actually I prefer that option as well. Basically each host has its own
> /64.
> 
> > I'd hate this, IEEE telling IETF what to do. Just like IETF telling
> > IEEE to do an immensely scalable L2 multicast support so that
> > Solicited Node Multicast appears so cool on a switched fabric? Does
> > not seem to work either.
> >
> > The IETF has to decide if it wants to design IP over 802.11 - or
> > Wi-Foo in general which would be my take. And then the IETF has to
> > decide if it wants to design IP over a mix of Wi-Fi and Ethernet. IEEE
> > people may join the effort so we do the job right.
> 
> a multicast packet if there are more (or less) than X nodes in a subnet, send
> unicast to each and every one of them if it's less (or more) than Y.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 10 Aug 2015 20:05:11 +0200

> Such a thing is just untrue. IP works on any link, it has to. That's why
> we do IP over Foo.

Agreed, IP is supposed to work on anything from 10Gb/s fiber to carrier
pigeons.  The market has chosen, IP has eaten all of the protocols that
required special support from the link layer.  If a link layer doesn't
fit, we design an adaptation shim (I'm looking at you, ARCNET).

However, this doesn't prevent us from giving advice to link layer
designers for best IP performance.  RFC 3819 (BCP 89) has the following to
say:

   Subnetworks using shared channels (e.g., radio LANs, Ethernets) are
   especially suitable for native multicasting, and their designers
   should make every effort to support it.

Since RFC 3819 is mostly concerned about avoiding receiving unwanted
multicast, it doesn't say anything about the performance of multicast
itself.  Is an update needed?

-- Juliusz

---

From: "Pat (Patricia) Thaler" <[email-masked]>
Date: Mon, 10 Aug 2015 18:41:42 +0000

There are potentially ways of addressing higher loss rates for multicast that should be explored before going to replicated unicast.

>...  I have yet to hear about anyone using 802.11 for 
> instance for multicast IP video streaming. People have tried, quickly 
> discovered it didn't work (for any sensible level of work, multiple 
> percent packet loss doesn't count as "work" in a packet data network,) and
> moved to wires instead. ...

There are different use cases with different requirements on the underlying network. The needs and constraints of video streaming are different than those of protocols such as ND (neighbor discovery). The solutions that work for one may not apply to the other. 

For example, I can think of approaches to the problem:
> If you miss a couple of consecutive RAs in IPv6, you abandon your prefix 
> and your default route.
which wouldn't apply at all to video streaming. On the other hand, potentially work done in DetNet could help with video streaming but might not be a good fit for the use of multicast to maintain IPv6.

---

From: Alia Atlas <[email-masked]>
Date: Mon, 10 Aug 2015 14:48:49 -0400

Hi Adrian,

I am encouraging those interested to wrote a draft indicating the observed
issues and perhaps exploring the solution space.   I assume that's what you
would need to start having a meaningful discussion on reasonable options.

Thanks,
Alia
On Aug 10, 2015 5:41 AM, "Stephens, Adrian P" <[email-masked]>
wrote:

> Cc: [email-masked]; Dan Romascanu ([email-masked]); Glenn
> Parsons; [email-masked]; Homenet; Eric Gray
> Saying it "sucks" is not very helpful.   Unlicensed spectrum is free.  You
> are getting more than you are paying for :0).
>
>
> The technical solution is surely to add a class of service specification
> to multicast packs that indicates their sensitivity to loss.
> The point is that the AP is in possession of a lot of data about
> individual nodes that may help it make an informed decision
> I'm guessing you will be the first to turn off the 802.11 networking on
> your devices when the IETF makes such a statement.
> </irony>
>
>
>
> profile that would fulfil these requirements, possibly add a certification,
> and then try to get market pressure to require devices to support this
> profile. The IETF wouldn't change its mind about how multicast is used in
> its protocols after this, but just say "this is the reality, please deal
> with it when you create L1/L2 that's supposed to carry IP".
>
> > " For me, it seems these 802.11 broadcast/multicast ACK functions should
> > The second is certification.  This is the not-so-simple task of
> persuading a sufficient number of WiFi-Alliance members

---

From: Joe Touch <[email-masked]>
Date: Mon, 10 Aug 2015 19:58:16 -0500

On Aug 10, 2015, at 1:05 PM, Juliusz Chroboczek <[email-masked]> wrote:

> multicast,

I don't know why you would get that impression. I helped write that section (as noted in sec 19). Native L2 multicast should be supported exactly because it's useful to IP, as noted here:

---
Multicasting is considerably more efficient when a subnetwork explicitly supports it.
---

Joe

> it doesn't say anything about the performance of multicast

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 11 Aug 2015 09:08:27 -0700

> If not, a router learns from MLD the state it needs to figure to which devices it should copy a given packet.

Well, the problem with WiFI is that L2 multicast  are useful under some
conditions and not useful under others. And the conditions are more
complex than boolean ;-)

> For Wi-Fi, there is no multicast support and it is sufficiently clear now that relying on broadcast is not a good idea. 

Pretty sure you don't mean that. If you would eliminate ALL multicast, you
didn't have discovery of new devices.

> Rather, a good idea could be to build a multilink subnet with APs that are also routers to serve the wireless edge, whereby the Ethernet backbone can rely on L2 broadcast while the wireless edge is…

Thats why i asked what device model we need. Don't think i got an
answer for that though. L3 homenet APs would be lovely. But will it
be sufficient to ONLY support those theoretical devices in homenet ?

> I'd hate this, IEEE telling IETF what to do. Just like IETF telling IEEE to do an immensely scalable L2 multicast support so that Solicited Node Multicast appears so cool on a switched fabric? Does…

Sure.

> The IETF has to decide if it wants to design IP over 802.11 - or Wi-Foo in general which would be my take. And then the IETF has to decide if it wants to design IP over a mix of Wi-Fi and Ethernet.…

Getting IPv6 link signaling work with WiFi sucking L2 multicast
is just a bit of work in the L2 IPv6 protocols that can be done
IMHO without botrhering IEEE. Getting streaming multicast work 
best requires more L2 awareness and it doesn't seem homenet
is interested in thast anyhow, so i think we're only going to get
a solution for the L2 IPv6 signaling piece realistically in the
IETF alone.

Cheers
    toerless

---

From: Alia Atlas <[email-masked]>
Date: Tue, 11 Aug 2015 12:15:49 -0400

Can we please remove [email-masked] from this conversation?
Once we as the IETF figure out what to write down and discuss, that'll be a
good time to interact,
but I think this conversation is really not the point of that list.

It's already cc'd to mboned and homenet...

Thanks,
Alia

On Tue, Aug 11, 2015 at 12:08 PM, Toerless Eckert <[email-masked]> wrote:

> > For Wi-Fi, there is no multicast support and it is sufficiently clear
> now that relying on broadcast is not a good idea.
>
> are also routers to serve the wireless edge, whereby the Ethernet backbone
> can rely on L2 broadcast while the wireless edge is routed. Many LLNs work
> like this. Why should Wi-Fi be an exception?
>
> wants to design IP over a mix of Wi-Fi and Ethernet. IEEE people may join
> the effort so we do the job right.
>

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 11 Aug 2015 09:28:54 -0700

> The only thing IETF can do is to use less multicast, and the obvious way of solving it is to just replicate into unicast. This seems like a suboptimal way to work around the problem if there are a…

When replacing multicast with unicast its not necessary to replicate,
you can instead use different protocol mechanisms too, eg: client/server
communications. Especailly wrt to the p2p duplicate address detection.

> between unicast and multicast.

For the signaling that IPv6 needs it looks like a lot of waste of
complex L2 tracking (like those protected GCR's) to create reliability.

> Moving the duplication into the IP layer ensures uninformed decisions.

Yes, but only about optimizations unnecessary for signaling. Which is
why i said we should be more specific about what use of multicast
we're talking about: signaling or media. They need different
solution approaches IMHO.

> Write an RFC stating requirements on L1/L2 protocols when it comes to unicast, multicast and broadcast handling of packets. This could include options for mechanisms that turned multicast/broadcast…

Yeah, that doesn't work.

> 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 a…

Yes, for IPv6 L2 signaling.

> 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.

That too.

Cheers
    Toerless

> MBONED mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mboned

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 11 Aug 2015 09:30:50 -0700

Sure... 
But don't look at me, i don't remember i added that Cc:, i added mboned ;-))

---

From: Alia Atlas <[email-masked]>
Date: Tue, 11 Aug 2015 14:08:32 -0400

https://tools.ietf.org/html/draft-vyncke-6man-mcast-not-efficient-01 may be
of interest in understanding some of the issues with IPv6 and wifi.

Regards,
Alia

On Tue, Aug 11, 2015 at 12:30 PM, Toerless Eckert <[email-masked]> wrote:

> > > > Yes it is. IP over Foo must indicate if IP multicast over a link
> uses L2
> > > mechanisms or not.
> > > >
> > > > If not, a router learns from MLD the state it needs to figure to
> which
> > > devices it should copy a given packet.
> > >
> backbone
> > > > > it'll see a lot more unicast coming its way and be prepared to
> handle
> > > it.
> > > >
> IEEE
> Wi-Foo

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 11 Aug 2015 19:34:18 +0200

I'm removing from CC the people who I know are on Homenet, please do the
same with the other lists.

> I don't know why you would get that impression. I helped write that
> section (as noted in sec 19). Native L2 multicast should be supported
> exactly because it's useful to IP, as noted here:
> 
> ---

Perhaps I misread this section, but the impression I get is that it is
concerned about avoiding waking nodes and avoiding duplicate
transmissions.  I doesn't read like the authors are thinking about
networks where multicast has higher packet loss and lower throughput than
unicast, which is what concerns us here.

I'd love to be proved wrong.

-- Juliusz

---

From: Joe Touch <[email-masked]>
Date: Tue, 11 Aug 2015 13:59:15 -0700

On 8/11/2015 10:34 AM, Juliusz Chroboczek wrote:
> Perhaps I misread this section, 

Are you referring to RFC3819?

> but the impression I get is that it is
> transmissions.

This is incorrect. The section is basically saying "IP works better when
L2 supports multicast so L3 (IP) doesn't have to emulate it".

The assumption is that L2 will do a reasonably good and efficient job of
multicast/broadcast - certainly better than L3 or other layers would.

> I doesn't read like the authors are thinking about

The point of that section is that IP is more complex when it has to
emulate something that L2 doesn't provide. If it's more efficient to
implement L2 multicast via serial copy than by shared channels, that's
L2's decision.

The point of the RFC is to NOT make this the job of L3. L3 is a bad
place to support multicast or broadcast on subnets.

Joe

---

From: "Pat (Patricia) Thaler" <[email-masked]>
Date: Tue, 11 Aug 2015 21:44:24 +0000

RE: RFC3819

> multicast/broadcast - certainly better than L3 or other layers would.

What I think Juliuz is trying to point out is that the RFC doesn't talk about how good the performance of L2 multicast needs to be - for instance in terms of BER/packet loss. It does talk about the impact of BER on TCP throughput, but not on multicast. 

How good an error rate do the IPv6 related multicasts need?

Adrian summarized the causes of packet loss:
"1.  The basic "packet error rate" (before Ack) designed to is 10% in the case of unicast.   This is a very broad statement and almost so
simplistic as to be misleading.    Errors are composed of 1) collisions, 2) interference,  3) rate/MCS adaptation
errors,  4) sudden changes in the radio environment such as shadowing.   The residual error for unicast is less because of the retry mechanism.

2. Multicast is generally sent at a  low "basic" (one intended to be receivable by all STAs in the AP's network) rate.   This improves reliability in some of the error causes cited above, but not all. 
...." 

If it takes two missed RAs to decide that you aren't connected to the router any more, that has about a 1% chance of happening with a 10% packet error rate (though the multicast error rate is probably somewhat better since it is sent at the lower rate). This assumes that the error probability for the two RAs is independent; they occur far enough apart in time that this doesn't seem unreasonable. 
 
Why does it take two lost RAs rather than one? Presumably because the protocol assumes that sometimes an RA is lost, just not with as high a probability as 10%.

1% seems high - how good does it need to be for acceptable behavior? One could improve the behavior by adjusting parameters so that more than 2 had to be lost. Of course there is a tension between bandwidth for multicast heartbeats, wanting to detect reasonably quickly that the device is no longer on the subnet (e.g. because it is mobile), and not losing the context unnecessarily.

Without guidance on how good the multicast packet loss rate should be, it is difficult to define the best solution .

---

From: "Pat (Patricia) Thaler" <[email-masked]>
Date: Tue, 11 Aug 2015 21:46:43 +0000

I think it is useful for [email-masked]<mailto:[email-masked]> to be in the conversation. Some of the participants in the discussion are on that reflector and I don’t know that they are on homenet or mboned.

Pat

From: ieee-ietf-coord [mailto:[email-masked]] On Behalf Of Alia Atlas
Sent: Tuesday, August 11, 2015 9:16 AM
To: Toerless Eckert
Cc: [email-masked]; Homenet; [email-masked]
Subject: Re: [ieee-ietf-coord] [homenet] Multicast on 802.11

Can we please remove [email-masked]<mailto:[email-masked]> from this conversation?
Once we as the IETF figure out what to write down and discuss, that'll be a good time to interact,
but I think this conversation is really not the point of that list.

Thanks,
Alia

On Tue, Aug 11, 2015 at 12:08 PM, Toerless Eckert <[email-masked]<mailto:[email-masked]>> wrote:

Sure.

Cheers
    toerless

_______________________________________________
homenet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/homenet

---

From: Joe Touch <[email-masked]>
Date: Tue, 11 Aug 2015 14:54:01 -0700

On 8/11/2015 2:44 PM, Pat (Patricia) Thaler wrote:
> What I think Juliuz is trying to point out is that the RFC doesn't
> talk about how good the performance of L2 multicast needs to be -
> for instance in terms of BER/packet loss. It does talk about the
> impact of BER on TCP throughput, but not on multicast.

Agreed.

> How good an error rate do the IPv6 related multicasts need?

I would expect that depends on the use, e.g., DAD would be different
than streaming multimedia.

> If it takes two missed RAs to decide that you aren't connected to
> the router any more, that has about a 1% chance of happening with a 10%
> packet error rate (though the multicast error rate is probably
> somewhat better since it is sent at the lower rate). This assumes that
> the error probability for the two RAs is independent; they occur far
> enough apart in time that this doesn't seem unreasonable.
> 
> Why does it take two lost RAs rather than one? Presumably because
> the protocol assumes that sometimes an RA is lost, just not with as
> high a probability as 10%.
> 
> 1% seems high - how good does it need to be for acceptable behavior? 
> One could improve the behavior by adjusting parameters so that more
> than2 had to be lost. Of course there is a tension between bandwidth
> formulticast heartbeats, wanting to detect reasonably quickly that
> thedevice is no longer on the subnet (e.g. because it is mobile), and
> notlosing the context unnecessarily.
> 
> Without guidance on how good the multicast packet loss rate should
> be, it is difficult to define the best solution .

While I agree with your conclusion, what's the alternative if there is
no L2 multicast?

I think you're arguing for more specific guidance on acceptable packet
loss rates for various uses of multicast, but that might be out of scope
for RFC3819 (even as a -bis). I gave it a quick scan, and as I checked
(and recall) RFC3819 doesn't make specific recommendations on BER for
unicast either. It says that the BER needed depends on the use, and that
can affect the efficiency of L3. The same is true for multicast, but
that doc is not the place for a specific recommendation.

Joe

---

From: "Pat (Patricia) Thaler" <[email-masked]>
Date: Tue, 11 Aug 2015 22:32:35 +0000

Joe, 

I'm mainly concerned in this discussion on what error rate is needed for acceptable performance of the protocols that support IPv6 - e.g. DAD, RA. Streaming multimedia is a separate discussion since different solutions might apply to it. 

> While I agree with your conclusion, what's the alternative if there is

802.11 does have L2 multicast. It just doesn't provide for L2 ack and retry for L2 multicast (at least in its basic form, there is a recent optional extension for that) so the packet loss can be higher than that for unicast.

> that doc is not the place for a specific recommendation.

I don't think advice on that would be out of place as "Advice for Internet Subnetwork Designers" if it is what is needed to make IPv6 work well. People here have expressed consternation that 802.11 doesn't have good enough performance for that, but how can you expect subnets to provide that performance  when the need hasn't been included in the advice.

Even if the number doesn't get put into an RFC3819-bis, it would be useful to have a number so that solutions can be examined.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 12 Aug 2015 07:17:47 +0200 (CEST)

On Tue, 11 Aug 2015, Pat (Patricia) Thaler wrote:

> Without guidance on how good the multicast packet loss rate should be, 
> it is difficult to define the best solution .

I'd say most applications people actually use start behaving very badly 
around 0.1 - 1% packet loss. VoIP MOS goes down, TCP starts to really get 
affected etc. I'd imagine most people I interact with that design 
protocols design protocols have in their mind that the packet loss rate is 
around this level, not higher.

So for me, the "contract" that 802.11 needs to fulfil for the IETF not to 
start looking into changing IP for 802.11, is for 802.11 networks to 
deliver broadcast and multicast packets with around 0.1% packet loss (or 
less) as a design goal for normal operations.

---

From: "Toerless Eckert (eckert)" <[email-masked]>
Date: Wed, 12 Aug 2015 06:50:05 +0000

What you mention is for media streaming, and the wifi problem is primarily burst loss. Correcting that is expensive, whether its done at l2 or higher layer. Our signaling protocols can easily be fixed to live with even higher loss at lower cost. Thats why i am suggesting to separate solution space between signalling and media.

Sent from my Samsung Captivate Glide on AT&T

Mikael Abrahamsson <[email-masked]> wrote:

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 12 Aug 2015 10:12:05 +0200 (CEST)

On Wed, 12 Aug 2015, Henning Rogge wrote:

> 0.1% multicast packet loss is unrealistic.

I found this interesting document:

https://hal.archives-ouvertes.fr/tel-00919403/document

In 2.4 there is a lot of text about different ways of making multicast 
(more) reliable.

>From what I can see, the control plane (for instance RA/ND/ARP etc) (this 
does not include video transmission) of IP based protocols have the 
following requirements for its broadcast/multicast packets (from now on I 
will only say multicast):

Multicast packets should be delivered with less than 1% packet loss 
Multicast packets should be delivered within 200-500ms (for instance DAD 
requires answer within 1s)

This would indicate to me that 802.11 could do the following to achieve a 
compromise between power, packet loss etc:

If the multicast packet is to be sent to X receivers or fewer, turn them 
into L2 unicast, and send them individually (tradeoff between sending X 
packets and using a lower rate multicast). X could be 2-4 or something?

Send IP control plane multicast packets at an interval, for instance 
250ms, so stations can sleep in between.

Send multiple packets at the above interval if there are multiple ones 
queued up, use BNAK for retransmits, potentially turning 
to-be-retransmitted multicast packets into unicast (re)transmits to send 
to individual stations that didn't receive the multicasted packet(s).

(I don't know if this is already being done) Stations should send IP 
multicast packets to the AP in L2 unicast so the AP can then send it as 
multicast using above mechanism, including queuing it for multiple 
delivery.

Thoughts?

---

From: Henning Rogge <[email-masked]>
Date: Wed, 12 Aug 2015 07:51:46 +0200

On Wed, Aug 12, 2015 at 7:17 AM, Mikael Abrahamsson <[email-masked]> wrote:
> affected etc. I'd imagine most people I interact with that design protocols
> design protocols have in their mind that the packet loss rate is around this
> level, not higher.
>
> start looking into changing IP for 802.11, is for 802.11 networks to deliver
> broadcast and multicast packets with around 0.1% packet loss (or less) as a
> design goal for normal operations.

The problem is we are dealing with more and more wireless devices, so
the medium starts to become congested more easily.

0.1% - 1% packet loss (not frame loss) is possible for unicast, but
0.1% multicast packet loss is unrealistic.

Henning Rogge

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Wed, 12 Aug 2015 07:31:27 +0000

>0.1% multicast packet loss is unrealistic.

Some empirical measurements done on large WLAN are worse than those
numbers: range of 10% to 20% of mcast packets lost...

---

From: Stig Venaas <[email-masked]>
Date: Wed, 12 Aug 2015 10:42:24 -0700

Hi

> numbers: range of 10% to 20% of mcast packets lost...

In this case I guess there might be such a big loss for unicast at the
radio layer (or what you call it) as well. It's just that there is
retransmission for lost unicast. The long delay may become an issue for TCP
and unicast streaming though.

Stig

---

From: Joe Touch <[email-masked]>
Date: Wed, 12 Aug 2015 11:23:29 -0700

On 8/11/2015 3:32 PM, Pat (Patricia) Thaler wrote:
> Joe, 
> 
> I'm mainly concerned in this discussion on what error rate is needed
> for acceptable performance of the protocols that support IPv6 - e.g.
> DAD, RA. Streaming multimedia is a separate discussion since different
> solutions might apply to it. 

Sure.

> 802.11 does have L2 multicast. It just doesn't provide for L2 ack 
> and retry for L2 multicast (at least in its basic form, there is a
> recent optional extension for that) so the packet loss can be higher
> than that for unicast.

Understood, but again, what's the alternative?

> I don't think advice on that would be out of place as "Advice for
> Internet Subnetwork Designers" if it is what is needed to make IPv6 work
> well. People here have expressed consternation that 802.11 doesn't have
> good enough performance for that, but how can you expect subnets to
> provide that performance when the need hasn't been included in the advice.

That's true, but specific protocol behaviors do address this issue
already, e.g., RFC 7559 uses exponential backoffs for soliciting RAs.

DAD is a "negative information" protocol, i.e., a lossy link can give a
false positive. This issue is already addressed Sec 4.4 of RFC 4429: the
effect of L2 losses can be mitigated by recommending a different value
for DupAddrDetectTransmits. RFC 4862 Sec 5.1 already notes that this
parameter might need to be defaulted to a different value for particular
link types, and such might need to be the case for 802.11.

> Even if the number doesn't get put into an RFC3819-bis, it would be
> useful to have a number so that solutions can be examined.

For this protocol mechanism, the numbers are a relationship:

	L2 mcast loss rate vs. DupAddrDetectTransmits value

IMO, it'd be a lot easier to increase DupAddrDetectTransmits than to
assume 802.11 would lower the L2 mcast loss rate.

Joe

---

From: Henning Rogge <[email-masked]>
Date: Wed, 12 Aug 2015 21:39:21 +0200

> link types, and such might need to be the case for 802.11.

Luckily DAD is mostly needed for randomized IPv6 addresses... if you
use the MAC address for generating the IP you are either fine or you
have a MAC level collision, which means you have an unsolvable
problem.

(it gets even worse on 802.11 IBSS/Adhoc mode)

Henning Rogge

---

From: Joe Touch <[email-masked]>
Date: Wed, 12 Aug 2015 13:08:34 -0700

> requires answer within 1s)

That assumes default DAD configuration, and I already noted that this is
clearly not appropriate for existing 802.11 links based on the recently
reported loss rates.

I.e., DAD doesn't have specific requirements; it has a *relationship* of
its configuration to the link properties.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 12 Aug 2015 13:13:15 -0700

> have a MAC level collision, which means you have an unsolvable

DAD is also needed to detect duplicates due to host misconfiguration,
such as when a cloned MAC is added to the same network or when addresses
are duplicated by other means (e.g., DHCPv6 misconfiguration).

I couldn't confirm, but isn't this also not a local decision? I.e., if
DAD fails you might end up with a duplicate address even when you set
your IP addresses based on the burned-in MAC because others could select
the same address randomly (I didn't see how that was avoided by the
self-assignment algorithm).

Joe

---

From: Henning Rogge <[email-masked]>
Date: Thu, 13 Aug 2015 06:35:50 +0200

> self-assignment algorithm).

If you have a duplicate MAC then DAD will not safe you... you cannot
communicate anyways because of a layer-2 problem.

Henning Rogge

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 13 Aug 2015 07:25:51 +0200 (CEST)

> communicate anyways because of a layer-2 problem.

Well, you can share the same L3 network but not share the same L2 network 
(and do proxy-ND between them). But yes, you're basically correct.

---

From: Joe Touch <[email-masked]>
Date: Thu, 13 Aug 2015 11:13:05 -0700

On 8/13/2015 10:59 AM, james woodyatt wrote:
> On Aug 12, 2015, at 21:35, Henning Rogge <[email-masked]
> <mailto:[email-masked]>> wrote:
...
> Yes, and DAD also has logic that limits the damage on the entire network
> when hosts join with duplicate L2 addresses, c.f. section 5.4.5 of RFC 4862.

Also, a duplicate L2 is a problem at L2 only when both L2s are on the
same L2 subnet. It's entirely possible that the two L2s are on different
L2 subnets but on the same L3 subnet.

E.g., consider point-to-point links to the router. No reason to care
about the L2s at all (interface is all you need to determine the remote
end), but nodes that self-address using identical L2s would create
identical L3's.

Joe

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 14 Aug 2015 16:17:15 +0000

Hello Alia:

The solution space has been explored in the context of WPANs (802.15.4, BTLE…) and there is certainly value in extending this to WLANs. We have running code that was tested between vendors (twice already) at 6TiSCH plug fests and is scheduled for official plugtest in Berlin next year.

The solution splits the broadcast domain by making the hybrid wired/wireless network a MultiLink Subnet. ND operations on the wireless links derives from RFC 6775 and the use of multicast for ND is dramatically reduced. Backbone routers perform proxy ND operations to integrate with the wired backbone. The overall design is pretty much an echo at layer-3 of the association process that was designed for 802.11 and that is much more suitable to wireless than IPv6 ND’s multicast-based operations.

I just updated the (years old, used to be a 6LowPAN WG doc from which RFC 6775 actually derives) backbone router draft. The problems is summarized by referencing other drafts from Andrew, Eric, Erik, Samita, and others, and I detailed the protocol operations as my memory and a crude code lookup tells me it is implemented. It is broadly correct but there are devils in the details and we’ll need to refine as usual.

URL:            https://www.ietf.org/internet-drafts/draft-thubert-6lo-backbone-router-00.txt

Htmlized:       https://tools.ietf.org/html/draft-thubert-6lo-backbone-router-00

Take care,

Pascal

From: homenet [mailto:[email-masked]] On Behalf Of Alia Atlas
Sent: lundi 10 août 2015 20:49
To: Adrian P Stephens <[email-masked]>
Cc: [email-masked]; Dan Romascanu ([email-masked]) <[email-masked]>; Glenn Parsons <[email-masked]>; [email-masked]; Homenet <[email-masked]>; Mikael Abrahamsson <[email-masked]>; Eric Gray <[email-masked]>
Subject: Re: [homenet] [ieee-ietf-coord] Multicast on 802.11

Hi Adrian,

I am encouraging those interested to wrote a draft indicating the observed issues and perhaps exploring the solution space.   I assume that's what you would need to start having a meaningful discussion on reasonable options.

Thanks,
Alia
On Aug 10, 2015 5:41 AM, "Stephens, Adrian P" <[email-masked]<mailto:[email-masked]>> wrote:
Hello Mikael,

Best Regards,

Adrian P STEPHENS

Tel: +44 (1793) 404825<tel:%2B44%20%281793%29%20404825> (office)
Tel: +1 (971) 330 6025<tel:%2B1%20%28971%29%20330%206025> (mobile)

-----Original Message-----
From: ieee-ietf-coord [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Mikael Abrahamsson
Sent: 10 August 2015 10:27
To: Stephens, Adrian P
Cc: [email-masked]<mailto:[email-masked]>; Dan Romascanu ([email-masked]<mailto:[email-masked]>); Glenn Parsons; [email-masked]<mailto:[email-masked]>; Homenet; Eric Gray
Subject: [ieee-ietf-coord] Multicast on 802.11

(included [email-masked]<mailto:[email-masked]> and also changed subject to something more
appropriate)

[Adrian P Stephens]

[Adrian P Stephens]

[Adrian P Stephens]

On Mon, 10 Aug 2015, Stephens, Adrian P wrote:

> From: ieee-ietf-coord [mailto:[email-masked]<mailto:[email-masked]>] On
> Behalf Of Mikael Abrahamsson
> [email-masked]<mailto:[email-masked]>; Dan Romascanu ([email-masked]<mailto:[email-masked]>); Glenn
> Mikael Abrahamsson    email: [email-masked]<mailto:[email-masked]>
>
> [email-masked]<mailto:[email-masked]>

--
Mikael Abrahamsson    email: [email-masked]<mailto:[email-masked]>

_______________________________________________
ieee-ietf-coord mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ieee-ietf-coord

---

From: james woodyatt <[email-masked]>
Date: Thu, 13 Aug 2015 10:59:20 -0700

> communicate anyways because of a layer-2 problem.

Yes, and DAD also has logic that limits the damage on the entire network when hosts join with duplicate L2 addresses, c.f. section 5.4.5 of RFC 4862.

>    If the address is a link-local address formed from an interface
>    identifier based on the hardware address, which is supposed to be
>    uniquely assigned (e.g., EUI-64 for an Ethernet interface), IP
>    operation on the interface SHOULD be disabled.

It’s worth noting that the presence of network sleep proxies can make this recommendation problematic. It would be better to disable the whole interface only when the actual L2 address is discovered to be duplicated, not just the link-local IPv6 address w/ embedded EUI-64 IID, which would allow DAD failures with sleep proxies on link-local addresses to be treated like a DAD failure with a sleep proxy on any other address. Alas, earwax.

—james