Subject: [16ng] Re: is access router an oracle

From: Pars Mutaf <[email-masked]>
Date: Fri, 28 Jul 2006 16:38:01 +0200

On Fri, 2006-07-28 at 15:49 +0200, Pars Mutaf wrote:
> Hello, 
> 
> I have a question about the centralized DAD approach (i.e. with AR
> acting as oracle as currently being discussed in 16ng). I would be 
> more than happy if you send me a reply. Please help me understand
> (seriously).
> 
> The IPv6 interface ID has 64-2=62 bits that can be used for stateless
> address autoconfiguration. With a reasonable random number generator, we
> can generate IPv6 addresses with ~0 address collision probability (or,
> am I overly optimistic ;-).
> 
> But no. We don't feel comfortable. Computers are not reliable. There may
> be a bug or another problem and a collision may occur. Hence, we need a
> duplicate address detection mechanism. Then (in 16ng) we rely on the
> access router knowing all addresses to detect the address collisions.
> 
> We don't trust computers, but we trust the access router acting as an
> oracle i.e. knowing all addresses. Isn't that strange? There is no bug
> in the access router? What if one, or more, or all addresses were lost
> by the AR? 
> 
> If the AR is not error-prone (it isn't), 

sorry for the typo, I mean:

If the AR is error-prone (it is), ...

> its contribution is really
> important? In addition, please don't forget that it is not easy for the
> AR to learn ALL addresses (please see my reply/question to Erik).
> 
> This makes sense? Or, is there an error in my thinking.
> 
> Thank you.
> 
> Best regards, 
> 
> Pars Mutaf
> 
> 
> ==========
> 
> A psychological test:
> 
> There is an incoming packet (ok?) The AR (knowing all addresses in the
> subnet) checks whether or not the destination address exists in its
> cache. No it does not exist. 
> 
> What the AR should do?
> 
> a) Drop the packet
> b) Perform neighbor discovery 
> 
> If you choose (b), then you don't think the AR reliably knows all
> addresses.
> 
>

---

From: "JinHyeock Choi" <[email-masked]>
Date: Mon, 31 Jul 2006 18:37:26 +0900

Dear Pars

Kindly find my inline comments.

> If the AR is error-prone (it isn't), its contribution is really
> important?

The address uniqueness is doubly assured by 1) compurter's generating
random IID and 2) AR's knowing all the address to detect a duplicate
without multicast. However, it may be ok for us to just rely on 1) by
setting DupAddrDetecTransmits =0.

> In addition, please don't forget that it is not easy for the

It may not be that difficult. Kindly find my following proposal.

Right now, the AR scans a (DAD) NS or MLD message to generate the
Address Cache and hosts on the link don't actively participate in
that.

However, if hosts actively notify their newly configured addresses to
the AR, the Authoritative Address Cache can be maintained more easily.
We can use the existing "NUD" procedure to make the hosts to notify
the AR its (newly configured) IPv6 address as below.

For convenience, we assume a link with a single Access Router (AR).
However, I guess that the scheme can be extended for multiple AR case.

Step 1
The IPv6 host generates a tentative address (whether in a stateless
way as of RFC 2462 or in a stateful way with DHCPv6) and performs DAD.
(DAD may be relay DAD.)

Step 2
After successfully completing the DAD, instead of immediately
assigning the tentative address to its interface, the host performs
NUD to ensure that the AR's Address Cache has its (newly configured)
address.

The host sends a Neighbor Solicitation message to the AR with
1) the AR address as a destination address,
2) its (newly configured) address as a source address,
3) the AR address as a target address

Step 3.
When the AR receives the NS, it checks whether its Address Cache has
the source address of the NS (the newly configured address) or not. If
not, it adds the address to its Address Cache.

Step 4.
After assuring that the (newly configured) address is in its Address
Cache, the AR sends a Neighbor Advertisement with
1) the (newly configured) address as a destination address,
2) the AR address as a source address,
3) the AR address as a target address and
4) solicitation bit set.

Step 5.
Only after receiving that NA, the host assigns the (newly configured)
address to its interface to start using it.

* The host may have to send multiple NSs to receive the NA in case of
packet loss.

* When there are multiple ARs on the link, the host sends an NS to
each AR. Also, before assigning the address, it waits for the replying
NAs from all the ARs.

I think we can build the Omniscient AR with the above. The fact that
the host receives the NA in Step 5 assures that the AR has the (newly
configured) address in its Address Cache.

In case I miss something, kindly let me know.

> b) Perform neighbor discovery

In WiMAX environment, a).

Thanks for your kind consideration.

Best Regards

JinHyeock
>From [email-masked] Tue Aug  1 00:17:37 2006
Subject: Re: [16ng] is access router an oracle
From: Pars Mutaf <[email-masked]>
To: JinHyeock Choi <[email-masked]>
Organization: INT Evry
Date: Mon, 31 Jul 2006 16:08:19 +0200
cc: [email-masked]
Reply-To: [email-masked]

Hi JinHyeock,

Thanks for your reply. Please find my responses below:

On Mon, 2006-07-31 at 18:37 +0900, JinHyeock Choi wrote:
> Dear Pars
> 
> Kindly find my inline comments.
> 
> > If the AR is error-prone (it isn't), its contribution is really
> > important?
> 
> The address uniqueness is doubly assured by 1) compurter's generating
> random IID and 2) AR's knowing all the address to detect a duplicate
> without multicast. However, it may be ok for us to just rely on 1) by
> setting DupAddrDetecTransmits =0.

If 16ng can mandate or recommend the use of random IIDs, 
and a good random number generator, then the
DAD issue is close IMHO. We can reach address collision probabilities 
as low as e.g. 10^-10. We don't need a better solution 
(personally I don't think we have a better solution). We should be 
more worried about the probability of being hit by lightning. 

That is, everything is all right.

In addition:

Who says that DAD detects all collisions?? What if there were 
a collision (I would be very surprised) but the DAD packet were 
lost? 

You know... the wireless packet error rate is not always that that 
low. 

> > In addition, please don't forget that it is not easy for the
> It may not be that difficult. Kindly find my following proposal.
> 
> Right now, the AR scans a (DAD) NS or MLD message to generate the
> Address Cache and hosts on the link don't actively participate in
> that.
> 
> However, if hosts actively notify their newly configured addresses to
> the AR, the Authoritative Address Cache can be maintained more easily.
> We can use the existing "NUD" procedure to make the hosts to notify
> the AR its (newly configured) IPv6 address as below.
> 
> For convenience, we assume a link with a single Access Router (AR).
> However, I guess that the scheme can be extended for multiple AR case.
> 
> Step 1
> The IPv6 host generates a tentative address (whether in a stateless
> way as of RFC 2462 or in a stateful way with DHCPv6) and performs DAD.
> (DAD may be relay DAD.)
> 
> Step 2
> After successfully completing the DAD, instead of immediately
> assigning the tentative address to its interface, the host performs
> NUD to ensure that the AR's Address Cache has its (newly configured)
> address.
> 
> The host sends a Neighbor Solicitation message to the AR with
> 1) the AR address as a destination address,
> 2) its (newly configured) address as a source address,
> 3) the AR address as a target address
> 
> Step 3.
> When the AR receives the NS, it checks whether its Address Cache has
> the source address of the NS (the newly configured address) or not. If
> not, it adds the address to its Address Cache.
> 
> Step 4.
> After assuring that the (newly configured) address is in its Address
> Cache, the AR sends a Neighbor Advertisement with
> 1) the (newly configured) address as a destination address,
> 2) the AR address as a source address,
> 3) the AR address as a target address and
> 4) solicitation bit set.
> 
> Step 5.
> Only after receiving that NA, the host assigns the (newly configured)
> address to its interface to start using it.
> 
> * The host may have to send multiple NSs to receive the NA in case of
> packet loss.
> 
> * When there are multiple ARs on the link, the host sends an NS to
> each AR. Also, before assigning the address, it waits for the replying
> NAs from all the ARs.
> 
> I think we can build the Omniscient AR with the above. The fact that
> the host receives the NA in Step 5 assures that the AR has the (newly
> configured) address in its Address Cache.
> 
> In case I miss something, kindly let me know.

The protocol that you describe above can address the problem 
only once. It is not reliable.

Consequently, from the mobile host's perspective, your proposal 
is "stressing". Imagine a loss of state scenario (i.e. access 
router crashing and rebooting). This is a realistic scenario that 
was not invented by myself and it is very easily addressed by 
IPv6 Neighbor Discovery (ND).

Your proposal is energy consuming. The idle hosts need to 
periodically check/ensure that the AR still knows their address. 
The longer the period, the less reliable the protocol. 

Normally, idle hosts are supposed to stay cool and silent, and 
conserve energy. They are also supposed to leave bandwidth to 
active hosts. This optimization is important, you know. Because 
mobile hosts are idle e.g. 90% of time.

Here is my proposal:
 
Soft MAC/IP state. It may expire. It may be lost. No problem. Idle 
hosts do *nothing*. Upon incoming packet, the AR informs the 
destination using ND multicast neighbor solicitation. 
The idle host (if sleeping, wakes up), re-establishes its MAC 
connection and receives the incoming packet buffered by the AR.
This is standard ND, except that the host does not return its 
MAC address. Instead, it re-establishes its MAC connection.

This makes sense?

The only potential problem that I see with this approach is the 
MAC connection establishment delay. If it takes e.g. 10 seconds 
this is too long. But a delay e.g. up to 1 sec is OK imho. 
Personally, with a newest technology like Wimax I would be
very surprised if the connection establishment takes that long.

> In WiMAX environment, a).

This is not reliable. Try to see the problem from the AR's 
perspective. At a given moment of time, say T_i, when there is 
an incoming packet and the destination address is NOT in the 
AR's cache:

It is impossible to know for sure 
if the destination's cache entry wasn't lost 
a few milliseconds, seconds, or minutes ago.

That's why the reliable answer is (b); not only in Wimax but
in all cases. 

(and, please don't forget that we are not supposed 
to have a different IP solution for Wimax)

Is there a problem in my logic?

Thanks.

pars

---

From: "JinHyeock Choi" <[email-masked]>
Date: Tue, 1 Aug 2006 00:04:59 +0900

Dear Pars

> IPv6 Neighbor Discovery (ND).

In case a default router fails, the standard NUD procedure will kick
in to detect the router failure. Neighbor Discovery recommends a host
to keep at least one default router in REACHABLE state. So after
Reachabletime, the hosts will send an NS to perform NUD. If the router
reboots meanwhile, it can re-generate the Address Cache from the NSs.

> mobile hosts are idle e.g. 90% of time.

Idle hosts don't have to wake up so often. We may set the certain
amount of time, maybe AddressKeepTime, and make it a rule that the AR
keeps the address within AddressKeepTime. If we set AddressKeepTime as
default router lifetime, it would not disturb mobile nodes' sleep
much.

> very surprised if the connection establishment takes that long.

In WiMAX network, when a packet arrives for an idling MN, instead of
multicasting NS, the AR (ASN GW) pages the MS to wake it up and
forward the packet accordingly. Take notice that the idling MN may
move out of the subnet while sleeping.

> That's why the reliable answer is (b); not only in Wimax but

I think it depends on viewpoint. WiMAX is planned as a commercial
network. WiMAX network is supposed to provide communication service
for the subscribers which has its information in ASN GW (AR). I don't
think WiMAX network aims to deliver packets to its destination at all
cost.

Also wireless bandwidth is scarce resource and, as you point out,
roughly 90 % of hosts are sleeping at any moment. So it may not
efficient to wake up all those sleeping node and send multicast NS for
a dubious destination.

Best Regards

JinHyeock
>From [email-masked] Tue Aug  1 01:56:46 2006
Date: Mon, 31 Jul 2006 08:49:03 -0700 (PDT)
From: Behcet Sarikaya <[email-masked]>
Subject: Re: [16ng] is access router an oracle
To: JinHyeock Choi <[email-masked]>
cc: [email-masked]
Reply-To: Behcet Sarikaya <[email-masked]>

--0-1528901018-1154360943=:9442
Content-Type: text/plain; charset=us-ascii

Hi JinHyeock,
  I read your proposal with great interest.
So you are proposing ND + NUD, I think it is quite costly in terms of air bandwidth.
  Why not use eND? You had indicated some problems with it, we have solutions for those.
  Regarding random IIDs, I think WiMAX MNs would use those only for privacy and as additional addresses, normal mode of operation should be the IIDs are generated from IEEE MAC addresses.
  Kind regards,

--behcet

----- Original Message ----
From: JinHyeock Choi <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Sent: Monday, July 31, 2006 10:04:59 AM
Subject: Re: [16ng] is access router an oracle

Dear Pars

> IPv6 Neighbor Discovery (ND).

In case a default router fails, the standard NUD procedure will kick
in to detect the router failure. Neighbor Discovery recommends a host
to keep at least one default router in REACHABLE state. So after
Reachabletime, the hosts will send an NS to perform NUD. If the router
reboots meanwhile, it can re-generate the Address Cache from the NSs.

> mobile hosts are idle e.g. 90% of time.

Idle hosts don't have to wake up so often. We may set the certain
amount of time, maybe AddressKeepTime, and make it a rule that the AR
keeps the address within AddressKeepTime. If we set AddressKeepTime as
default router lifetime, it would not disturb mobile nodes' sleep
much.

> very surprised if the connection establishment takes that long.

In WiMAX network, when a packet arrives for an idling MN, instead of
multicasting NS, the AR (ASN GW) pages the MS to wake it up and
forward the packet accordingly. Take notice that the idling MN may
move out of the subnet while sleeping.

> That's why the reliable answer is (b); not only in Wimax but

I think it depends on viewpoint. WiMAX is planned as a commercial
network. WiMAX network is supposed to provide communication service
for the subscribers which has its information in ASN GW (AR). I don't
think WiMAX network aims to deliver packets to its destination at all
cost.

Also wireless bandwidth is scarce resource and, as you point out,
roughly 90 % of hosts are sleeping at any moment. So it may not
efficient to wake up all those sleeping node and send multicast NS for
a dubious destination.

Best Regards

JinHyeock
_______________________________________________
16ng mailing list
[email-masked]
http://eeca16.sogang.ac.kr/mailman/listinfo/16ng

--0-1528901018-1154360943=:9442
Content-Type: text/html; charset=us-ascii

<html><head><style type="text/css"><!-- DIV {margin:0px} --></style></head><body><div style="font-family:courier, monaco, monospace, sans-serif;font-size:12pt"><div style="font-family: courier,monaco,monospace,sans-serif; font-size: 12pt;">Hi JinHyeock,<br>&nbsp; I read your proposal with great interest.<br>So you are proposing ND + NUD, I think it is quite costly in terms of air bandwidth.<br>&nbsp; Why not use eND? You had indicated some problems with it, we have solutions for those.<br>&nbsp; Regarding random IIDs, I think WiMAX MNs would use those only for privacy and as additional addresses, normal mode of operation should be the IIDs are generated from IEEE MAC addresses.<br>&nbsp; Kind regards,<br><br>--behcet<br><br><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;">----- Original Message ----<br>From: JinHyeock Choi &lt;[email-masked]&gt;<br>To: [email-masked]<br>Cc: [email-masked]<br>Sent: Monday, July 31, 2006
 10:04:59 AM<br>Subject: Re: [16ng] is access router an oracle<br><br><div>Dear Pars<br><br>&gt; &gt; &gt; In addition, please don't forget that it is not easy for the<br>&gt; &gt; &gt; AR to learn ALL addresses (please see my reply/question to Erik).<br>&gt; &gt;<br>&gt; &gt; It may not be that difficult. Kindly find my following proposal.<br>&gt; &gt;<br>&gt; &gt; Right now, the AR scans a (DAD) NS or MLD message to generate the<br>&gt; &gt; Address Cache and hosts on the link don't actively participate in<br>&gt; &gt; that.<br>&gt; &gt;<br>&gt; &gt; However, if hosts actively notify their newly configured addresses to<br>&gt; &gt; the AR, the Authoritative Address Cache can be maintained more easily.<br>&gt; &gt; We can use the existing "NUD" procedure to make the hosts to notify<br>&gt; &gt; the AR its (newly configured) IPv6 address as below.<br>&gt; &gt;<br>&gt; &gt; For convenience, we assume a link with a single Access Router (AR).<br>&gt; &gt; However, I guess that
 the scheme can be extended for multiple AR case.<br>&gt; &gt;<br>&gt; &gt; Step 1<br>&gt; &gt; The IPv6 host generates a tentative address (whether in a stateless<br>&gt; &gt; way as of RFC 2462 or in a stateful way with DHCPv6) and performs DAD.<br>&gt; &gt; (DAD may be relay DAD.)<br>&gt; &gt;<br>&gt; &gt; Step 2<br>&gt; &gt; After successfully completing the DAD, instead of immediately<br>&gt; &gt; assigning the tentative address to its interface, the host performs<br>&gt; &gt; NUD to ensure that the AR's Address Cache has its (newly configured)<br>&gt; &gt; address.<br>&gt; &gt;<br>&gt; &gt; The host sends a Neighbor Solicitation message to the AR with<br>&gt; &gt; 1) the AR address as a destination address,<br>&gt; &gt; 2) its (newly configured) address as a source address,<br>&gt; &gt; 3) the AR address as a target address<br>&gt; &gt;<br>&gt; &gt; Step 3.<br>&gt; &gt; When the AR receives the NS, it checks whether its Address Cache has<br>&gt; &gt; the source
 address of the NS (the newly configured address) or not. If<br>&gt; &gt; not, it adds the address to its Address Cache.<br>&gt; &gt;<br>&gt; &gt; Step 4.<br>&gt; &gt; After assuring that the (newly configured) address is in its Address<br>&gt; &gt; Cache, the AR sends a Neighbor Advertisement with<br>&gt; &gt; 1) the (newly configured) address as a destination address,<br>&gt; &gt; 2) the AR address as a source address,<br>&gt; &gt; 3) the AR address as a target address and<br>&gt; &gt; 4) solicitation bit set.<br>&gt; &gt;<br>&gt; &gt; Step 5.<br>&gt; &gt; Only after receiving that NA, the host assigns the (newly configured)<br>&gt; &gt; address to its interface to start using it.<br>&gt; &gt;<br>&gt; &gt; * The host may have to send multiple NSs to receive the NA in case of<br>&gt; &gt; packet loss.<br>&gt; &gt;<br>&gt; &gt; * When there are multiple ARs on the link, the host sends an NS to<br>&gt; &gt; each AR. Also, before assigning the address, it waits for the
 replying<br>&gt; &gt; NAs from all the ARs.<br>&gt; &gt;<br>&gt; &gt; I think we can build the Omniscient AR with the above. The fact that<br>&gt; &gt; the host receives the NA in Step 5 assures that the AR has the (newly<br>&gt; &gt; configured) address in its Address Cache.<br>&gt; &gt;<br>&gt; &gt; In case I miss something, kindly let me know.<br>&gt;<br>&gt; The protocol that you describe above can address the problem<br>&gt; only once. It is not reliable.<br>&gt;<br>&gt; Consequently, from the mobile host's perspective, your proposal<br>&gt; is "stressing". Imagine a loss of state scenario (i.e. access<br>&gt; router crashing and rebooting). This is a realistic scenario that<br>&gt; was not invented by myself and it is very easily addressed by<br>&gt; IPv6 Neighbor Discovery (ND).<br><br>In case a default router fails, the standard NUD procedure will kick<br>in to detect the router failure. Neighbor Discovery recommends a host<br>to keep at least one default router in
 REACHABLE state. So after<br>Reachabletime, the hosts will send an NS to perform NUD. If the router<br>reboots meanwhile, it can re-generate the Address Cache from the NSs.<br><br>&gt; Your proposal is energy consuming. The idle hosts need to<br>&gt; periodically check/ensure that the AR still knows their address.<br>&gt; The longer the period, the less reliable the protocol.<br>&gt;<br>&gt; Normally, idle hosts are supposed to stay cool and silent, and<br>&gt; conserve energy. They are also supposed to leave bandwidth to<br>&gt; active hosts. This optimization is important, you know. Because<br>&gt; mobile hosts are idle e.g. 90% of time.<br><br>Idle hosts don't have to wake up so often. We may set the certain<br>amount of time, maybe AddressKeepTime, and make it a rule that the AR<br>keeps the address within AddressKeepTime. If we set AddressKeepTime as<br>default router lifetime, it would not disturb mobile nodes' sleep<br>much.<br><br>&gt; Here is my
 proposal:<br>&gt;<br>&gt; Soft MAC/IP state. It may expire. It may be lost. No problem. Idle<br>&gt; hosts do *nothing*. Upon incoming packet, the AR informs the<br>&gt; destination using ND multicast neighbor solicitation.<br>&gt; The idle host (if sleeping, wakes up), re-establishes its MAC<br>&gt; connection and receives the incoming packet buffered by the AR.<br>&gt; This is standard ND, except that the host does not return its<br>&gt; MAC address. Instead, it re-establishes its MAC connection.<br>&gt;<br>&gt; This makes sense?<br>&gt;<br>&gt; The only potential problem that I see with this approach is the<br>&gt; MAC connection establishment delay. If it takes e.g. 10 seconds<br>&gt; this is too long. But a delay e.g. up to 1 sec is OK imho.<br>&gt; Personally, with a newest technology like Wimax I would be<br>&gt; very surprised if the connection establishment takes that long.<br><br>In WiMAX network, when a packet arrives for an idling MN, instead of<br>multicasting
 NS, the AR (ASN GW) pages the MS to wake it up and<br>forward the packet accordingly. Take notice that the idling MN may<br>move out of the subnet while sleeping.<br><br>&gt; &gt; &gt; What the AR should do?<br>&gt; &gt; &gt;<br>&gt; &gt; &gt; a) Drop the packet<br>&gt; &gt; &gt; b) Perform neighbor discovery<br>&gt; &gt;<br>&gt; &gt; In WiMAX environment, a).<br>&gt;<br>&gt; This is not reliable. Try to see the problem from the AR's<br>&gt; perspective. At a given moment of time, say T_i, when there is<br>&gt; an incoming packet and the destination address is NOT in the<br>&gt; AR's cache:<br>&gt;<br>&gt; It is impossible to know for sure<br>&gt; if the destination's cache entry wasn't lost<br>&gt; a few milliseconds, seconds, or minutes ago.<br>&gt;<br>&gt; That's why the reliable answer is (b); not only in Wimax but<br>&gt; in all cases.<br><br>I think it depends on viewpoint. WiMAX is planned as a commercial<br>network. WiMAX network is supposed to provide
 communication service<br>for the subscribers which has its information in ASN GW (AR). I don't<br>think WiMAX network aims to deliver packets to its destination at all<br>cost.<br><br>Also wireless bandwidth is scarce resource and, as you point out,<br>roughly 90 % of hosts are sleeping at any moment. So it may not<br>efficient to wake up all those sleeping node and send multicast NS for<br>a dubious destination.<br><br>Thanks for your kind consideration.<br><br>Best Regards<br><br>JinHyeock<br>_______________________________________________<br>16ng mailing list<br>[email-masked]<br><a target="_blank" href="http://eeca16.sogang.ac.kr/mailman/listinfo/16ng">http://eeca16.sogang.ac.kr/mailman/listinfo/16ng</a><br></div></div><br></div></div></body></html>
--0-1528901018-1154360943=:9442--
>From [email-masked] Tue Aug  1 02:33:07 2006
Date: Mon, 31 Jul 2006 18:23:49 +0200

Dear JinHyeock,

On Tue, 2006-08-01 at 00:04 +0900, JinHyeock Choi wrote:
> In case a default router fails, the standard NUD procedure will kick
> in to detect the router failure. Neighbor Discovery recommends a host
> to keep at least one default router in REACHABLE state. So after
> Reachabletime, the hosts will send an NS to perform NUD. If the router
> reboots meanwhile, it can re-generate the Address Cache from the NSs.
> 

Neighbor Discovery also recommends "multicast neighbor solicitations".
Multicast neighbor solicitations (upon lack of state) have significant
contribution to ND's reliability. If we remove this feature, the NUD
requirements will also change probably.

NUD may become too energy consuming in this case (if we wish to obtain
the same level of reliability).. Because the host's NSs would have to
be more frequent.

Or, am I missing something?

> Idle hosts don't have to wake up so often. We may set the certain
> amount of time, maybe AddressKeepTime, and make it a rule that the AR
> keeps the address within AddressKeepTime. If we set AddressKeepTime as
> default router lifetime, it would not disturb mobile nodes' sleep
> much.
> 
> > Here is my proposal:
> >
> In WiMAX network, when a packet arrives for an idling MN, instead of
> multicasting NS, the AR (ASN GW) pages the MS to wake it up and
> forward the packet accordingly. Take notice that the idling MN may
> move out of the subnet while sleeping.
> 
> > > > What the AR should do?
> > > >
> > > > a) Drop the packet
> I think it depends on viewpoint. WiMAX is planned as a commercial
> network. WiMAX network is supposed to provide communication service
> for the subscribers which has its information in ASN GW (AR). I don't
> think WiMAX network aims to deliver packets to its destination at all
> cost.
> 
> Also wireless bandwidth is scarce resource and, as you point out,
> roughly 90 % of hosts are sleeping at any moment. So it may not
> efficient to wake up all those sleeping node and send multicast NS for
> a dubious destination.

Please note that my proposal applies only to the loss of state scenario.
This does not introduce any cost in normal mode of operation.
If the incoming packet's destination has a cache entry, very good.
You say that this will mostly be the case? Great. 

But if NOT, the destination address should be multicast neighbor
solicited. This is the best solution to the loss of state scenario.
I think this is in the commercial operator's interest.

Thank you for your attention.

pars

---

From: Pars Mutaf <[email-masked]>
Date: Tue, 01 Aug 2006 16:39:19 +0200

> You know... the wireless packet error rate is not always that that 

Regarding the possibility of not doing DAD (because there is no such
thing as an oracle): the SEND working group discussed the same issue 
in the past:

http://standards.ericsson.net/lists/ietf-send/msg00502.html

Looks like the issue is not close. 

May be 16ng may reconsider this possibility. In Wimax there is 
a stronger need imho.

pars