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

From: Pekka Savola <[email-masked]>
Date: Thu, 1 Feb 2007 08:47:48 +0200 (EET)

Some responses inline,

On Wed, 31 Jan 2007, Basavaraj Patil wrote:
>> The design implications of raising RA intervals (intead of, say, filtering
>> extra RAs out) may not be fully understood.  How are other protocols (e.g.,
>> periodic MLD reports, Neighbor Solicitations due to port scanning or
>> pinging
>> the all nodes multicast address, etc.) handled?
>
> Filtering extra RAs is not an option. The MS expects an RA at
> MaxAdvIntervals and filtering them would disrupt MS behavior.

Which implementations expect this?  Is this behaviour related to DNA? 
At least I have not seen this kind of dependency but I have a very 
limited view of fixed hosts only.  Host implementations that I'm aware 
of just look at the lifetimes of PIO options (can be long) for address 
lifetimes and AdvDefaultLifetime (max 9000sec) for default route 
lifetime.

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.

> The MS and AR are connected via a PtP link which is created via a
> combination of the transport connection over the air interface and a
> corresponding GRE tunnel between the BS and AR. Are there specific
> issues w.r.t MLD reports etc. on a PtP link that you believe need to
> be clarified?

I don't see PtP specific issues, except that MLD specifications expect 
that hosts send periodic MLD reports about the groups they have joined 
(including the solicited-node link local addresses).  Similarly, 
router is required to send MLD queries periodically on the link to 
check the multicast group memberships.  How are you going to deal with 
this scenario?  Will it require a protocol modification as well?

Are there other protocols similar to ND and MLD which require 
periodical messaging that may be relevant in this scenario (I can't 
recall from the top of my head, but I'd suspect there may be, whether 
standardized or proprietary)?

>> ==> However, if the MS is a router, RA is basically ignored in this kind of
>> context.  Hence, this approach of non-default MTU configuration seems
>> applicable between host and a router only.
>
> Okay... Do you have any suggestion or text that would help in this
> context?

I'm not sure which specific text would be most helpful here, but you 
should probably point out that the proposed approach is only 
applicable in host-router scenarios so you can't depend on it for all 
cases.  In other scenarios, other mechanisms (unfortunately, the only 
option I can think of is manual configuration at both ends) needs to 
be used.

>> How do you deal with periodic MLD reports, for
>> example?
>
> So what would break if periodic MLD reports are not sent.

If there is MLD snooping (to restrict multicast flooding) along the 
path, it will break.  I'm not sure how applicable this is in this 
context; if each MS (from the perspective of AR) has a separate link 
so that 10 multicast recipients of the same group would require 10 GRE 
tunneled packets (no optimization), this is maybe not an issue except 
for expandability.

I think this is more of a procedural issue, i.e., what steps are 
required to standardize a mechanism that breaks existing standardized 
mechanisms?  Do all the existing mechanisms need to be changed (first) 
or something else?  Should this approach be reviewed by the people who 
standardized the old mechanisms?

>> 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.

>> 3) The text above seems technically incorrect.  The key point here is what
>> is the MTU on the wired link between BS and AR.  If it supports MTUs higher
>> than 1500 (for example, GE jumboframes, SDH, ATM, whatever), tunneling
>> could
>> possibly still be used.
>
> True... But the fact is that for WiMAX, the profile specifies a MAX
> SDU of 1522 octets. So the packets on the air-interface cannot be
> greater than 1522 bytes. So the existence of links with higher MTU
> capability on the link between the BS<->AR does not matter.

We may be talking past each other, because I don't see what 
air-interface has to do with this (I'm assuming that the interface 
between AR and BS is _not_ air-interface but I may be wrong).  A 
1500-byte packet on AR-BS interface could be encapsulated in GRE 
(resulting in ~1550 byte packet or something like that) between AR and 
BS.  If AR-BS interface supports MTU higher than about 1550, this 
should be no problem.

-- 
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/16ng

---

From: Basavaraj Patil <[email-masked]>
Date: Thu, 01 Feb 2007 21:17:05 -0600

Hi Pekka,

Reponses inline:

> Which implementations expect this?  Is this behaviour related to

DNA for example. For DNA, a host relies on prefixes which were received
within 3 * Maximum of MaxRtrAdvInterval.
Well, the problem also is the fact if the MaxRtrAdvInterval as per RFC2461
is fairly small, the AR will send the periodic RAs and this would
cause the MS being paged causing it to transition from Idle
mode. Discussion on increasing the value of this parameter in the bis
version of RFC2461 (during IETF LC) concluded that the value can be
specified  depending on the link or in specific IPv6 over foo
documents. 

> lifetimes and AdvDefaultLifetime (max 9000sec) for default route

But the Max value of MaxRtrAdvInterval as per RFC2461 is 1800
secs. And this is not long enough. Hence the reason to increase the
value of this parameter.

> 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. 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..
The delay in establishing the link after the MS is paged is fairly
small and there is buffering capability in the network to manage the
delay. 

> this scenario?  Will it require a protocol modification as well?

No. The draft only increases the Max value of MaxRtrAdvInterval. It doesn't
change any standard w.r.t. periodic MLD report.

> standardized or proprietary)?

Cant think of any.

> option I can think of is manual configuration at both ends) needs to

Okay. I can add some text to this effect.

> tunneled packets (no optimization), this is maybe not an issue except

Yes. Because of the p2p link model, it won't break even in presence
of MLD snooping.

> 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.

> BS.  If AR-BS interface supports MTU higher than about 1550, this

Ahh... The BS<->AR link is what you were refering to..
I agree... But in general MTU size of 1500 on links is assumed or
expected. And hence the recommendation.

-Raj

---

From: Pekka Savola <[email-masked]>
Date: Fri, 2 Feb 2007 08:01:52 +0200 (EET)

> 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.

> 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

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.

> interface and if the MS is in idle mode, it is paged. If not the

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.

---

From: "JinHyeock Choi" <[email-masked]>
Date: Fri, 2 Feb 2007 19:27:00 +0900

Dear Pekka

Thanks for your helpful review. Kindly find my in-line comments.

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

I'm not sure why that's incorrect.

First take notice that it is NOT MaxRtrAdvInterval BUT Maximum of
MaxRtrAdvInterval. (This distinction is sometimes confusing, at least
to me.) According to RFC 2461, Maximum of MaxRtrAdvInterval is 30 min
but MaxRtrAdvInterval may differ from router to router.

        MaxRtrAdvInterval
                     The maximum time allowed between sending
                     unsolicited multicast Router Advertisements from
                     the interface, in seconds.  MUST be no less than 4
                     seconds and no greater than 1800 seconds.

Second a host simply stops using for DNA operation a prefix which was
not received within 3 * Maximum of MaxRtrAdvInterval but can keep
using the prefix as of RFC 2461.

This 3 * Maximum of MaxRtrAdvInterval rule is to remove the stale
prefix information quickly  because prefix lifetime can be quite long,
days or even weeks, for DNA operation.

> from it packets getting lost in the network, so this would require no

As you wrote above, assume MaxRtrAdvInterval is set to 1800 secs
(which happens to be also the Maximum of MaxRtrAdvInterval) and BS
filters out to deliver RA every 8000 secs.

Then after 5400 secs, from the lack of RAs within 3 * Maximum of
MaxRtrAdvInterval, hosts can deduce that it has missed at least 3 RAs
and stop using advertised prefix for DNA operation.

If MaxRtrAdvInterval is very close to Maximum of Max RtrAdvInterval,
filtering out some RAs may give hosts the wrong impression that there
is something wrong on the router/link.

Thanks for your kind consideration.

Best Regards

JinHyeock

---

From: Pekka Savola <[email-masked]>
Date: Fri, 2 Feb 2007 16:20:40 +0200 (EET)

> days or even weeks, for DNA operation.

OK, it is "correct" in the sense that DNA can certainly, at 3* 
Max_MaxRtrAdvInterval decide that the default router is rather stale 
(at 60% of its maximum lifetime) and stop using it, but Neighbor 
Discovery itself specifies the maximum as 
max{Max_MaxRtrAdvInterval,9000}.

Hence if 3*Max_MaxRtrAdvInverval is felt to be too short a time to 
wake up a dormant host, but 9000 seconds would not be, DNA could be 
fixed to use the rest of the 9000 seconds the same way as ND is 
already using using it.

> and stop using advertised prefix for DNA operation.

And that is very much due to the way how DNA has been specified, not 
how ND has been specified.  Perhaps DNA should change to look at 
5*Max_MaxRtrAdvInterval (or in other words: 9000 seconds) rather than 
just 60% of the maximum.

> is something wrong on the router/link.

That's correct in a way, if the hosts are (too) "smart" and e.g., 
report that something odd is going on if there is no RA seen in 30 
minutes.  A dumb host doesn't even need to know what 
Max_MaxRtrAdvInterval and don't care though.

---

From: Basavaraj Patil <[email-masked]>
Date: Fri, 02 Feb 2007 15:54:59 -0600

Inline:

> from it packets getting lost in the network, so this would require no

Well requiring the BS to filter such messages would be an additional
requirement and not the best option. Also the BS would need to know which
specific RAs are to be filtered, I.e the periodic ones vs the ones that are
solicited by the MS.
Additionally if the host implementation is such that it will wake up to
receive an RA when the MaxRtrAdvInterval is reached it will have the adverse
effect of waking up unnecessarily and wasting battery power and
air0interface resources. Such a host may end up even sending an RS at the
expiry of the MaxRtrAdvInterval in case the RA has been filtered out by the
BS or lost. 

Hence it is better to increase the value of the MaxRtrAdvInterval. This
change does no harm.

-Raj

---

From: "JinHyeock Choi" <[email-masked]>
Date: Sat, 3 Feb 2007 15:15:36 +0900

Pekka

> fixed to use the rest of the 9000 seconds the same way as ND is

I am a little confused. First, 3 * Max_MaxRtrAdvInterval rule only
prevents a host from using old prefixes for DNA operation, i.e. link
identification. It doesn't mandate the host stop using any router.
Second, since Max_MaxRtrAdvInterval is 1800 secs,
max{Max_MaxRtrAdvInterval,9000} is simply 9000 sec.

> 5*Max_MaxRtrAdvInterval (or in other words: 9000 seconds) rather than

It depends on how many lost RAs would constitute prefix invalidation.
Maybe we'd better discuss this further in DNA WG ML. By chance, Sathya
happened to submit an updated DNAv6 draft today. Your feedback on DNA
solution would be appreciated.

> Max_MaxRtrAdvInterval and don't care though.

Right, we were concerned that MIPv6 hosts may be such a smart ones
because RFC 3775 recommends mobile nodes to interpret the lack of RAs
as an L3 handoff indication.

                   the mobile node needs to perform Router Discovery
   to discover routers and prefixes on the new link, as described in
   Section 6.3.7 of RFC 2461 [12].

   o  If Router Advertisements that the mobile node receives include an
      Advertisement Interval option, the mobile node may use its
      Advertisement Interval field as an indication of the frequency
      with which it should expect to continue to receive future
      Advertisements from that router.  This field specifies the minimum
      rate (the maximum amount of time between successive
      Advertisements) that the mobile node should expect.  If this
      amount of time elapses without the mobile node receiving any
      Advertisement from this router, the mobile node can be sure that
      at least one Advertisement sent by the router has been lost.  The
      mobile node can then implement its own policy to determine how
      many lost Advertisements from its current default router
      constitute an L3 handover indication.

Best Regards

JinHyeock