Re: [CARD Technical Issue] U flag and Unsolicited CARD

> > A default rate must be specified. The IESG will insist on this. See RFC
> 2608
> > for an example.
> >
> [eunsoo] If the IESG insist on setting the default value, we can set the
> default maximum transmission rate of the unsolicited replies. Since
> unsolicited replies would not involve time-sensitive operation, it should
be
> fine. A simple guess is "maximum once per second" like the router
> advertisement. What do you think?
>

Here are what some other protocols do.

1) RFC 2461 suggests MAX_INITIAL_RTR_ADVERT_INTERVAL as an initial value and
MIN_DELAY_BETWEEN_RAS multicast to the All Nodes Multicast Address.
MIN_DELAY_BETWEEN_RAS is 3 seconds, MAX_INITIAL_RTR_ADVERT_INTERVAL is 16
seconds.

2) RFC 2608 (SLP, whose purpose is similar to CARD in some ways) suggests 12
hours for unsolicited DA advertisements. This is clearly too long for CARD,
since nodes can hand over at any time.

3) OSPF has a default route flooding period of about 20 min. This also seems
a bit long.

4) As a general observation, protocols that do excessive advertisement tend
to increase the base network load, reducing bandwidth for traffic, something
to be especially avoided on wireless networks. Novell's SAP for example was
infamous for this, and I am told that Apple Rendezvous can also if not
properly configured.

The question one must ask is if the MNs can solicit, what is the purpose of
the unsolicited message?  As an alternative, to reduce traffic from per MN
solicitations? If so, then having the message multicast more frequently than
the approximate lingering time of the MNs on the link won't end up saving
anything.

With this in mind, I'd suggest a default mean of 5 min, configurable to half
the approximate mean lingering time of mobile nodes on the link. The router
then randomly generates a time between 1 sec. and the mean for the actual
time (to avoid synchronization). An interesting experiment would be to look
at some data on 802.11 networks, like for example, the IETF network, and
find out long nodes do linger. YMMV of course, but it would give some more
realistic bounds.

Here are some other considerations:

1) If any of the CARD information changes, the router should multicast
immediately. The router should start by randomizing the initial message
between, say, 1 and 3 seconds in order to avoid clashes with other routers
on the link. And it should continue sending for, say 20 seconds, randomizing
the intermessage time, in case any of the messages are dropped. The draft
should recommend keeping dynamic attribute changes to a minimum, as this
would cause excessive advertisement. Perhaps a minimum change interval of 5
min.

2) Pg. 46 of RFC 2461 has this to say about sending of unsolicted RAs:

   Unsolicited Router Advertisements are not strictly periodic: the
   interval between subsequent transmissions is randomized to reduce the
   probability of synchronization with the advertisements from other
   routers on the same link [SYNC].

The WG may want to consider requiring this of unsolicited CARD messages as
well.

3) Another way to avoid the clashing adverts problem is to have only one
router on the link do the advertisement. The WG may also want to consider
recommending that the protocol accommodate configuration such that one
router can be configured as the sole CARD multicast source. Or was the
protocol intended to accommodate different CARD information on routers
sharing the same link? It might be possible (but clearly undesirable from a
complexity standpoint) to have one set of access points in one geographical
area configured with one router and another with another but both routers on
the same subnet, and the possible CARs be different, since the possible
topological moves from the different geographical areas could be different.
The MIP group is grappling with this issue for movement detection, no
solution yet.

> > > The same port number as the solicited CARD reply is used for the
> > unsolicted
> > > CARD reply.
> > >
> >
> > OK.
> >
> > > What do you think would be the proper TTL for the unsolicited CARD
> reply?
> > I
> > > thought TTL 1 should be fine between MN-AR.
> > >
> >
> > If you make it 255, then the reply must have come from a node on the
same
> > link. This is a cheap way to prevent an offlink attacker from sending
> bogus
> > CARD replies. RFC 2461 uses this technique. The node should reject the
> > message if the TTL is not 255.
> >
> [eunsoo] Thanks for the info. 255 must be the right value for MN-AR. How
> about AR-AR?
>

The check won't work in that case because there could be multiple hops
between the two. The two ARs should be using ESP to authenticate anyway.

            jak