Subject: IPv6 over radio links

From: RJ Atkinson <[email-masked]>
Date: Thu, 13 Mar 2014 08:27:38 -0400

There was some discussion in the IPv6 WG meeting last week about the 
peculiar challenges of multicasting IPv6 packets over IEEE 802.11 a/b/g/n 
links.  These challenges are specific to that single IEEE Media Access 
Control (MAC) protocol and are NOT general to radio links.

  In my consulting work, I deal with IP over a variety of radio links,
for example IP over SATCOM using Very-Small Aperture Terminals (VSATs).
VSAT refers to the size of the antenna, roughly 1m in diameter.  These
are commonly used in North American and Europe by retailers, banks,
and other firms.  VSATs are also quite commonly used on all other
continents (possibly excepting Antarctica) as a way to provide 
communications connectivity (e.g. if the fixed land infrastructure
is inadequate, unreliable, or simply missing).  For an IP/VSAT
deployment, multicast normally is the MOST EFFICIENT way to move
data.  A colleague runs IP over 2.4 Kbps HF in his Amateur Radio
hobby.  He reports that IP multicasting again is the MOST EFFICIENT
way to move data over that radio link.

  The underlying physics of radio networks, at any frequency, are
broadcast.  So, unless a particular kind of radio link is using an
RF MAC protocol with a design anomaly, radio links naturally handle
both broadcast and multicast traffic optimally.

  While IEEE 802.11 a/b/g/n links are fairly common, their MAC
protocol exhibits properties (e.g. handling IP multicast inefficiently)
that are ATYPICAL for RF links.

  To my mind, this says that any optimisations that are targeting the
peculiar issues of the IEEE 802.11 a/b/g/n MAC protocol ought to be
equally narrowly targeted -- such that such optimisations ONLY are
used with links using that specific MAC protocol and are NOT specification
changes that affect the vast majority of radio and wired links that
do NOT have the MAC-specific operational anomalies of IEEE 802.11 a/b/g/n.

  As a specific path forward, I would like to reference Lorenzo's 
presentation on "Solutions within Existing Protocol Specifications".
(This is not yet online at the usual IETF URL, I'd be obliged if 
Lorenzo could get the PDF to the WG Chairs today and if they could
get it posted as soon as possible, so everyone can go read that.)
In one of Lorenzo's slides it talked about a series of steps that
tried to apply science to the issues with the IEEE 802.11 a/b/g/n 
MAC protocol, rather than changing the ND specification for ALL
deployed IPv6 systems (without regard to whether those systems 
are connected to links that handle IP multicast inefficiently).  

  In the first instance, if any ND specification changes are being
considered, they should LOOSEN the ND requirements rather than
create any new requirements or tighten existing requirements.  
Folks who are supporting IPv6 over the 802.11 a/b/g/n MAC protocol
ought to design local optimisations for their 802.11 implementations 
in the ways that Lorenzo's draft outlines and scientifically measure 
the results.  This ought to be practical to do in a lab setting at
any commercial firm or university or research organisation.  As
an example, in IETF terminology "SHOULD" means "do X UNLESS there
are good reasons to do something else".  In this specific case,
running IPv6 over a link that doesn't handle IP multicasting well
WOULD BE a "good reason to do something else" over that one specific
link type.

  One of the features of IPv4 and TCP has been that they are NOT
over specified, thus permitting implementers the opportunity to make
locally-meaningful and locally-sensible optimisations WITHOUT
requiring everyone to implement changes that might not make sense
in different environments (or over different links).

* The bottom line of this note is that I do not support the current
  proposals by Nordmark et alia to change the IPv6 ND specifications.
  They seek to change all IPv6 implementations in order to optimise
  IPv6 for one specific link technology -- a radio link with a badly
  designed MAC protocol (from the perspective of multicasting) that
  behaves quite differently to a normal radio link MAC protocol.

* However, if they were to propose ND specification changes that 
  *loosened* the ND specifications, giving implementers more room for
  local implementation-specific link optimisations, and *without* 
  adding *any* new restrictions/tests/timers/complexity, then
  I would look very seriously at that proposal.

Yours,

Ran Atkinson

---

From: Ole Troan <[email-masked]>
Date: Thu, 13 Mar 2014 14:23:11 +0100

Ran,

> are connected to links that handle IP multicast inefficiently).  

the Lorenzo/Andrew presentation is here:
http://tools.ietf.org/agenda/89/slides/slides-89-6man-10.pdf

cheers,
Ole

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 13 Mar 2014 14:57:16 +0100

>  behaves quite differently to a normal radio link MAC protocol.

Wouldn't simply using MLD snooping fix 98% of the issue with ND multicasts over 802.11?

Because neighbor solicitations and DHCPv6 requests are multicasts from client to the (presumably wire-bound) router/server, they don't have to go over the radio link as multicasts.

The solicited node address that neighbor solicitations are sent to can easily be converted to link layer unicasts by the access point because only one or a very small number of nodes are listening for it.

Router advertisements obviously still have to be multicast, but those actually need to go to all hosts and only a small number of routers send them relatively infrequently, especially if they avoid sending solicited RAs as multicast too frequently (or at all).

I actually think that stuff like Apple's multicast DNS is much more problematic, as it's relatively large messages coming from many nodes going to many nodes. If these protocols could be made less chatty by targeting their packets better (by using the solicited node address or something like it) and/or using proxies and/or be unified rather than having a whole bunch of them, that could help but that would be a significant effort.

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 13 Mar 2014 11:10:16 -0700

> create any new requirements or tighten existing requirements.

Ran,
Loosening the specification and providing different deployment advice 
(and perhaps new optional protocol behavior) is exactly what is being 
considered. Nobody wants any wholesale changes here AFAIK.
>    behaves quite differently to a normal radio link MAC protocol.

With all due respect, you are seriously misstating the facts. First of 
all, introducing new options to Neighbor Discovery is all that is being 
proposed in the efficient-nd. Those options are optional - just like the 
other options that have been added to IPv6 Neighbor Discovery.
Second of all, just because there are new behavior (whether for ND, or 
new TCP option/behavior) there is no assumption that all implementations 
need to change. The effficient-nd is very explicitly about handling a 
mix of hosts and routers that do and do not implement the new optional 
behavior.

>    I would look very seriously at that proposal.
The technical analysis so far (in the design team which started last 
week looking at the different drafts and other ideas) indicates that we can
  - significantly improve the situation for the RA/RS part of the puzzle 
(which includes relaxing behavior and specifying that if hosts 
optionally want to use unicast RS to refresh RA information how they do 
so without causing floods of RS messages)
  - optionally avoid much multicast NS for address resolution using L=0 
(behavior on router state loss and questions around IPv6 link-local 
addresses remains), and
  - if we as a WG want to do something about the multicast NS messages 
used for DAD, then we have a few options to consider
     - the techniques in the existing proxy-dad draft (implicitly 
registrations)
     - the ARO option in the efficient-nd draft (explicit registrations)
     - make DAD explicitly more optional (but seems counterproductive 
with more use of privacy/temporary addresses)

The design team is also gathering more data on the multicast traffic on 
WiFi (to see whether there is additional deployment and/or 
implementation advise that would make sense to avoid unneeded 
multicasts), and gathering the current deployment experience for WiFi, 
broadband, and cellular to see whether there are useful operational 
recommendations that can be made.

As IPv6 will continue to be deployed, and as the networks will scale in 
new dimensions with new classes of devices, we need to ensure that there 
is sufficient flexibility both in how to efficiently operate IPv6 
networks and for implementers that care about battery life etc.

Regards,
    Erik

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 17 Mar 2014 19:23:14 +0900

> Wouldn't simply using MLD snooping fix 98% of the issue with ND multicasts

In large networks the problem is actually solicited RAs happening every
time a device joins the network. Once you solve that by sending solicited
RAs unicast, most of the rest of it can be solved using MLD snooping, yes.

> Because neighbor solicitations and DHCPv6 requests are multicasts from
> client to the (presumably wire-bound) router/server, they don't have to go
> over the radio link as multicasts.
>

Yes.

> The solicited node address that neighbor solicitations are sent to can
> easily be converted to link layer unicasts by the access point because only
> one or a very small number of nodes are listening for it.
>

Yes (though this requires that the AP keep state via multicast or unicast
snooping).

> Router advertisements obviously still have to be multicast, but those
> actually need to go to all hosts and only a small number of routers send
> them relatively infrequently, especially if they avoid sending solicited
> RAs as multicast too frequently (or at all).
>

Yes (though not all vendors support sending solicited RAs multicast. We're
trying to fix that.)

> I actually think that stuff like Apple's multicast DNS is much more
> problematic, as it's relatively large messages coming from many nodes going
> to many nodes.

Yes.

---

From: "Eric Levy- Abegnoli (elevyabe)" <[email-masked]>
Date: Mon, 17 Mar 2014 10:53:47 +0000

From: Lorenzo Colitti <[email-masked]<mailto:[email-masked]>>
Date: lundi 17 mars 2014 11:23
To: Iljitsch van Beijnum <[email-masked]<mailto:[email-masked]>>
Cc: IETF IPv6 Mailing List <[email-masked]<mailto:[email-masked]>>, RJ Atkinson <[email-masked]<mailto:[email-masked]>>
Subject: Re: IPv6 over radio links

On Thu, Mar 13, 2014 at 10:57 PM, Iljitsch van Beijnum <[email-masked]<mailto:[email-masked]>> wrote:
Wouldn't simply using MLD snooping fix 98% of the issue with ND multicasts over 802.11?

In large networks the problem is actually solicited RAs happening every time a device joins the network. Once you solve that by sending solicited RAs unicast, most of the rest of it can be solved using MLD snooping, yes.

It would be nice to stop agitating the MLD-snooping magic stick and explain how this could possibly work for NS-lookup (to solicited node multicast).  Because it cannot.  It's all explained in Eric V. draft, but I'll repeat it here.

Assuming (which his not the case) that all host stack send mld-report, a switch could easily miss some of them (reports are not acknowledged and sent once. Over wifi, it's guaranteed that some are lost.
So a switch end up with a forwarding state for each multicast mac it sees (say 33:33:ff:01:02:03) pointing to 1 or more ports (say in my example ports 1 & 2,  (where it saw reports) and often missing a third port, say 3  (where it missed the report).  When the switch get the NS-lookup, it does not know its state is incomplete, so it does not forward to port 3. Address resolution broken. Unless we claim there is no collision on last 3 bytes?
The switch could send an mld query on a regular basis . How long would we accept broken address resolution? One minute? I'd rather say 1 to 3 sec, given host give up after that.
MLD query is itself a multicast message. It would be sent the AP to all wifi associated nodes. So now we have replaced one multicast with many., send every second!
Last but not least, snooping performed by the infra (the layer-2 switches) implies some "passivity". If the switch needs to send something, it has to have a source address to source query from. Switches don't have layer-3 addresses in every subnet (vlan) they operate on. This would be a major operational burden in they had to.

MLD snooping is good when there is an MLD router to fall back on. But not for link-local scope multicast, where it is not the case.
Eric

Yes.

Yes (though this requires that the AP keep state via multicast or unicast snooping).

Yes (though not all vendors support sending solicited RAs multicast. We're trying to fix that.)

I actually think that stuff like Apple's multicast DNS is much more problematic, as it's relatively large messages coming from many nodes going to many nodes.

Yes.

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 17 Mar 2014 12:58:41 +0100

There hasn’t been a rebuttal to this, so I’ll waste some time on this.

> These challenges are specific to that single IEEE Media Access 
> For an IP/VSAT

Speaking from a 2014 vantage point, the anomaly actually is with 1990s-style VSATs and those HF links.

Both have the unusual property that any packet sent out has a good likelihood of reaching all receivers.
This is because at the time these were designed, the sender (satellite in the VSAT case — the uplink is unicast anyway) did not do anything to exploit advantages it might have towards any specific receiver it targets.

This is anomalous today when many radio links use power control, beam forming, MIMO and similar space multiplexing techniques.

Of course, the simple broadcast-style radios will continue to exist in their specific areas of application.
They are simpler to build for hobbyists or on very constrained systems, they are up there on existing satellites etc.
And there are some actual applications where broadcast does help (say, “radio” as in AM radio).
Finally, even MIMO systems need to coordinate before going into efficient mode, so there will always be some broadcast components within the overall signal.

But as a general trend, using radio broadcast to disseminate information is no longer the natural way.
WiFi just happens to lead the trend here with a 10:1 to 50:1 efficiency ratio between unicast and broadcast.

(There are also system-level aspects that I’ll not go into here.)

The takeaway for 6man should be that the basic assumption of 1996’s ND, i.e. that multicast is as reliable and as efficient as unicast, no longer is right.  That doesn’t mean that we immediately have to stop using multicast (or have to stop using it at all — again, it’s great for some inefficient initial coordination), but we shouldn’t continue to design things as if the assumption were still true.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 17 Mar 2014 13:03:57 +0100

> Wouldn't simply using MLD snooping fix 98% of the issue with ND multicasts over 802.11?

The ironic thing here is that MLD is a registration protocol (a bad one, as Eric has pointed out).
Using MLD snooping, a node registers their IPv6 addresses (well, the lower 32 bits) to the L2 infrastructure.
This infrastructure then simulates a broadcast medium based on that registration in order to implement the L3 defense and lookup.

Even if this worked right most of the time, it would be hard to grasp for me how that is better than an actual L3 registration of the IPv6 address to the router, as the ARO option provides.

Grüße, Carsten

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 17 Mar 2014 09:03:48 -0400

On 17  Mar 2014, at 07:58 , Carsten Bormann wrote:
> This is anomalous today when many radio links use power control,
> beam forming, MIMO and similar space multiplexing techniques.

I agree that some radio links use those methods.  I am familiar
with several such.  Point-to-point and point-to-multipoint 
terrestrial microwave links are not new, but even they handle 
link-layer broadcast/multicast well within the set of intended 
communicating nodes.  In some cases, the newer radio link types 
that you mention above still work very well with IP multicasting.

> Of course, the simple broadcast-style radios will continue
> to exist in their specific areas of application.

s/in their specific/in their MORE NUMEROUS/

> But as a general trend, using radio broadcast to disseminate
> information is no longer the natural way.

Radio broadcast to disseminate information is still the natural way
for RF links.  There are some links, such as IEEE 802.11 a/b/g/n, 
where link-layer design choices make such dissemination 
un-naturally inefficient.

> The takeaway for 6man should be that the basic assumption of 1996’s ND,
> i.e. that multicast is as reliable and as efficient as unicast,
> no longer is right.  

I completely disagree with the notion that multicast somehow
has stopped being reliable enough and efficient enough in the
general case.

As I've said before, but in case it somehow wasn't clear earlier,
I don't have any issues with adding some ND complexity to better
support IEEE 802.11 a/b/g/n -- BUT -- ANY complexity or ANY changes
or ANY recommended optimisations ought to be narrowly targeted
at IEEE 802.11 a/b/g/n networks and ought to be separately 
specified.  A specific suggestion that someone else made earlier 
was to write a new standards-track "IPv6 over IEEE 802.11 a/b/g/n" 
document containing such optimisations.

Similarly, if the other radio links you mention at top benefit
from such optimisations, then suitable standards-track 
"IPv6 over FOO" documents can be written for those link types.

What we ought NOT do is make specification changes that impact
the millions of ALREADY deployed IPv6 stacks that are NOT connected
to the curiously-designed RF link types that lack scalable
support for broadcast/multicast.

Yours,

Ran

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 17 Mar 2014 22:11:01 +0900

On Mon, Mar 17, 2014 at 9:03 PM, Carsten Bormann <[email-masked]> wrote:

> This infrastructure then simulates a broadcast medium based on that
> registration in order to implement the L3 defense and lookup.
>
> Even if this worked right most of the time, it would be hard to grasp for
> me how that is better than an actual L3 registration of the IPv6 address to
> the router, as the ARO option provides.
>

It's true, it's not a very good one. Though it's not quite as bad as Eric
says, because on wifi, uplink multicast is acknowledged and thus as
reliable as unicast. But relying on routers to keep state is also not a
very good idea, because it's stateful and brittle.

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 21 Mar 2014 09:54:42 -0700

Ran,

The devil is in the details.

We shouldn't burden IPv6 over all link layers with considerations that 
are specific to particular link layers or particular to a class of link 
layers. But at the same time we should avoid fragmenting the IPv6 
standards and implementations.

Thus we shouldn't create an artificial choice where an implementation 
needs to select between IPv6.1 and IPv6.2 (or ND-for-Ethernet vs. 
ND-for-WiFi); a single implementation should be able to support both and 
have it be a choice (based on the link type/property, on deployment, or 
on operator control) which parts of the protocol are being enabled and 
used.

At the same time we shouldn't require that an implementation that by 
design never wants to handle links with a particular property aren't 
required to implement support for it.

So a IPv6 over 802.11 a/b/g/n wouldn't make any sense to be if it 
fragments the IPv6 standards by defining different protocol elements and 
behaviors.
A spec on "how to efficiently run IPv6 over 802.11 a/b/g/n" would make 
sense.

We already have (simple) examples of this approach in RFC 4861. If a 
link-layer doesn't have addresses it isn't burdened by address fields; 
the SLLAO and TLLAO are not used on links with that property. (The other 
examples are more obscure.)

Regards,
     Erik

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 21 Mar 2014 13:09:26 -0400

On 21  Mar 2014, at 12:54 , Erik Nordmark wrote:
> So a IPv6 over 802.11 a/b/g/n wouldn't make any sense if it
> fragments the IPv6 standards by defining different protocol
> elements and behaviors.
>  
> A spec on "how to efficiently run IPv6 over 802.11 a/b/g/n"
> would make sense.

Agreed, provided the "how to efficiently" text means optional 
advice to implementers and/or optional-to-support extensions, 
rather than mandatory changes to the IPv6 specifications.

If we do end up changing the base IPv6 specifications in some way
(something I hope we can avoid in the interest of spec stability), 
then we ought to be *loosening* specs so that implementers have the 
flexibility to optimise their implementation, instead of *tightening* 
or *changing* specifications.

Above all, I prefer that implementations not using the 802.11 a/b/g/n 
link type are not impacted (and thereby made non-compliant) by any 
outcome from the design team process (or subsequent 6MAN WG action).

For example, VSAT links are VERY narrow-band compared with 802.11 
a/b/g/n, or nearly any wired/fibred link, so using multicast over 
those VSAT links provides significant advantages in both ND performance
and also the link bandwidth remaining available for user data.

Yours,

Ran

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 21 Mar 2014 18:22:05 +0000

Hi Ran,

I do agree with you on the fact that efficient-ND should be innocuous to non E-ND devices, and that it should not enter in the certification of devices that have no use of it. Devices that can make use of E-ND are mobile devices in a WLAN/WPAN environment, as well as devices that rely on a proxy for ND operations. 

I do not see that a classical PC on an Ethernet would need to do support the efficient-ND extension, though it could if it chose to. The intent was not to impose efficient ND on those devices. This is why we dubbed it WiND for Wireless ND.

Cheers,

Pascal

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of RJ Atkinson
> Sent: vendredi 21 mars 2014 18:09
> To: [email-masked]
> > So a IPv6 over 802.11 a/b/g/n wouldn't make any sense if it fragments
> > the IPv6 standards by defining different protocol elements and
> > behaviors.
> >
> Agreed, provided the "how to efficiently" text means optional advice to
> implementers and/or optional-to-support extensions, rather than mandatory
> changes to the IPv6 specifications.
> 
> If we do end up changing the base IPv6 specifications in some way (something I
> hope we can avoid in the interest of spec stability), then we ought to be
> *loosening* specs so that implementers have the flexibility to optimise their
> implementation, instead of *tightening* or *changing* specifications.
> 
> Above all, I prefer that implementations not using the 802.11 a/b/g/n link type
> are not impacted (and thereby made non-compliant) by any outcome from the
> design team process (or subsequent 6MAN WG action).
> 
> For example, VSAT links are VERY narrow-band compared with 802.11 a/b/g/n,
> or nearly any wired/fibred link, so using multicast over those VSAT links provides
> significant advantages in both ND performance and also the link bandwidth
> remaining available for user data.
> 
> Yours,
> 
> Ran
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Jared Mauch <[email-masked]>
Date: Fri, 21 Mar 2014 14:38:38 -0400

> I do not see that a classical PC on an Ethernet would need to do support the efficient-ND extension, though it could if it chose to. The intent was not to impose efficient ND on those devices. This…

speaking and thinking outloud for a moment, some folks have microwave or other wireless bridges as well that may cause a LAN to span at least a few ms end-to-end in the same broadcast domain, I would imagine the wired hosts would also benefit from this.

Not everyone is using a fancy switch or hardware in this type of environment, so anything within the layer-2 domain will need to interop reasonably.

- Jared

PS. Good news is many devices, eg: iPhone, get software or hardware upgrades a few times a year almost automatically by the consumers, making this much better than a PC still running XP 10+ years later.