In 802.16, the MAC address is not used for
data transfer in only the IP-CS mode, which is not strictly an 802 thing. In
the Ethernet emulation modes, it certainly is. Also in the IP-CS modes, the MAC
addresses are known at both ends of the connection.
An IP-CS connection is more akin to a
point to point IP link than an Ethernet. The decision to send a packet down the
connection is a L3 one. L2 has only one connection to send it down, address
resolution is moot. Such spoofing sounds like a hack to satisfy an address
resolution attempt that shouldn’t be happening because the interface
doesn’t warrant it.
DJ
From:
owner-dna@ecselists.eng.monash.edu.au
[mailto:owner-dna@ecselists.eng.monash.edu.au] On Behalf Of Bernard Aboba
Sent: Thursday, January 10, 2008
11:05 AM
To: JinHyeock Choi
Cc: Wes Beebee (wbeebee);
dna@eng.monash.edu.au; Hemant Singh (shemant); gmonte@microsoft.com
Subject: RE: [DNA] DNAv6 Review
from Mobopts
> It may cause some problem for DNA scheme to rely on
MAC address as below.
>
> First, in certain technology such as 802.16, MAC address is not used
> for data transfer. In some implementation, when a host performs
> address resolution to find the router's MAC address, its device driver
> intercepts the message and provides a bogus MAC address.
So the device driver is spoofing a response to the Neighbor Solicitation?
Won't this cause problems if and when SEND is implemented?
> Moreover, when a host moves to another subnet/ link, it won't speed up
> DNA procedure to check whether its existing default router is still
> reachable. So the scheme will give little help when, IMO, fast DNA is
> needed the most, i.e. when a host doesn't have a valid address, so
> should get a new one ASAP.
Since ND and RS/RA are done simultaneously in simple DNAv6, the completion
time is determined by the faster of the two exchanges. In the case where
the
host doesn't have a valid address, the ND exchanges will fail (no response),
and the host will obtain an address via the normal RS/RA procedure.