[16NG] Re: Review of the ipv6-over-ipv6cs draft

[Pekka Savola <[e-mail]>]

On Thu, 1 Feb 2007, Basavaraj Patil wrote:
> DNA for example. For DNA, a host relies on prefixes which were received
> within 3 * Maximum of MaxRtrAdvInterval.

Such behaviour would be incorrect, as RFC2461 says:

       AdvDefaultLifetime
                      The value to be placed in the Router Lifetime field
                      of Router Advertisements sent from the interface,
                      in seconds.  MUST be either zero or between
                      MaxRtrAdvInterval and 9000 seconds.  A value of
                      zero indicates that the router is not to be used as
                      a default router.

                      Default: 3 * MaxRtrAdvInterval

So it is legitimate to have:

  3*MaxRtrAdvInterval < AdvDefaultLifetime < 9000

If what you say is true, DNA specification is incorrect.

>> Even if a default route would be lost while in suspend, I don't see
>> this as an issue as immediately when the host gets woken up, the
>> default route could be re-obtained by a) specific RA (if wake up call
>> was sent by the AR -- at the same time or 20ms later) or b) a RS (if
>> host decided to wake up).  Later you also said that when a host gets
>> paged it needs to establish the link, implying that in fact there is
>> some delay before link can be used after paging.
>
> Well... If the AR is configured to send periodic RAs at regular
> intervals (MaxRtrAdvInterval), the AR would end up paging the host and
> waking it up to deliver an RA which is essentially not very useful
> to the host.

If this approach were to be chosen, MaxRtrAdvInterval would be set to 
something like 1800 seconds, but for example BS could filter out 80% 
of messages, so an RA would only be sent to MS every 8000 seconds. 
>From the perspective of MS, filtering out RAs is indistinguishable 
from it packets getting lost in the network, so this would require no 
host modifications.

> In fact we had an I-D
> (draft-madanapalli-ipv6-periodic-rtr-advts-00.txt)  proposing that it
> should be possible to not send RAs at all on certain links. But
> because of backward compatibility issues this has not
> progressed. Since a host can always send a Rtr solicitation whenever
> it needs to, why send periodic RAs at all? If movement detection is
> not based on RAs as an example..

In fact, I have experience from traditional ethernet links where hosts 
(when they boot up) send RS's too early so that they are lost, and 
you'll need to rely on the next periodic RA.  While careful 
implementation may avoid this particular pitfall, at least on typical 
hosts "RS only" strategy would have been less effective in ensuring 
the hosts always have connectivity.

>>>> How do you prevent frequent port scanning from waking up the host
>>>> every 5 minutes when the router wants to do Neighbor Solicititation for the
>>>> address?
>>>
>>> It does not make sense to do wake up the host every 5 mins. Is there a
>>> reason for the AR to do NS periodically?
>>
>> No -- unless AR has packets to send to the MS.
>
> The AR does not do NS at all in the case of 802.16 because 802.16
> doesn't use MAC address for traffic forwarding.
> The AR simply sends the packet destined to the MS to its virtual
> interface and if the MS is in idle mode, it is paged. If not the
> packet is delivered.

Ok, this is something that needs to be spelled out better and was one 
of my earlier points, i.e., how do you do address mapping between IP 
addresses and link-layer addresses.  RFC2461 section 7 specifies that 
in the typical case.  It seems you diverge from that.  Does that mean 
that NUD (as part of section 7) is also not used?

In particular, NUD also applies to point-to-point interfaces which 
have no link-layer addresses (e.g., tunnels) even though the use of NS 
for address resolution wouldn't.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
16NG mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/16ng