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

Hi,

I can't help but argue about the default value. There are so many
scenarios and network types that could make use of CARD that it would be
impossible to give a default value. In the worst case, with a WLAN
network, a user might only spend a few seconds within the cover area of
one AP, while in the IETF, most people are sitting down while the
connectivity is on, which implies a lingering time of minutes or even
hours...

I would go for a section that discusses shortly the transmission interval,
and could give some example values in different scenarios, but no
single standardized default.

My 2 cents,
Jukka

On Thu, 3 Jul 2003, James Kempf wrote:

> > > 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
> 
> 
> 
> _______________________________________________
> Seamoby mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/seamoby
>