Re: Big Temporary Networks

[William Herrin <bill () herrin us>]

On Wed, Sep 19, 2012 at 11:33 AM, Sean Harlow <sean () seanharlow info> wrote:
> On Sep 19, 2012, at 04:25, Masataka Ohta wrote:
>
> > As I already stated, DHCP discover/request from STA to AP is
> > unicast.
>
> This didn't sound right, so I decided to test.  With the three clients
> available to me (laptop running OS X 10.7.4, phone running
> Android 4.0, and iPod running iOS 4.1.2) all client->server
> DHCP was broadcast, as well as server->client NACKs.
> Server->client offers and ACKs were unicast.

I think Masataka meant to say (and said previously) that the DHCP
request from the wifi station is, like all packets from the wifi
station to the AP, subject to wifi's layer 2 error recovery. It's not
unicast but its subject to error recovery anyway. In the return
direction (AP to station) broadcast and multicast packets are not
subject to error recovery while unicast packets are. Hence the the
DHCPv4 server->client unicast offers and acks pass reliably while
IPv6's equivalent multicast ICMPv6 router advertisements do not.


On Wed, Sep 19, 2012 at 5:54 PM, Masataka Ohta
<mohta () necom830 hpcl titech ac jp> wrote:
> However, at WiFi L2, it is first unicast to AP and then broadcast
> by the AP.

Your use of nomenclature is incorrect. It'd be like saying my ethernet
card unicasts a packet to the switch and then the switch broadcasts it
out all ports. Or like saying that a packet with an explicit MAC
destination is a broadcast packet because the switch doesn't have the
address in its MAC table. The packet is flooded out all ports but its
not a broadcast packet.

A layer 2 packet was unicast, multicast or broadcast moment I attached
the appropriate destination MAC. The exact handling on a particular
segment of the layer 2 network, while important in other contexts, is
irrelevant to the designation unicast, multicast or broadcast.


On Wed, Sep 19, 2012 at 3:26 AM, Masataka Ohta
<mohta () necom830 hpcl titech ac jp> wrote:
> The only thing operators have to know about IPv6 is that IPv6, as
> is currently specified, is not operational.

No offense, but it is not for you or I or Owen Delong to declare that
IPv6 is or isn't operational. Operators of individual networks can and
will decide for themselves whether and when IPv6 is sufficiently
operational for their use.

Your observation about IPv6's equivalent of an ARP reply using
multicast so that it misses wifi's layer 2 error recorvery (and thus
performs poorly compared to IPv4) was of value. Got any more or are we
ready to move on?

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin () dirtside com  bill () herrin us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004