Subject: [mobile-ip] Text for #236: Appliances that don't have config knobs

From: Jari Arkko <[email-masked]>
Date: Thu, 13 Feb 2003 16:33:43 +0200

Pekka,

You suggested earlier that we should avoid requiring configuration
options since not all devices have the capabilities for that. Here
are some responses to your specific proposals. I think we can accommodate
most of them, though the first one may not be necessary (or possible).

 > 5) something about upper-case keywords..
 >
 >    o  The node MUST allow route optimization to be administratively
 >       enabled or disabled.  The default SHOULD be enabled.
 >
 > is MUST a bit strong (e.g. consider appliances that may not have any
 > config knobs).  Perhaps a reword: "If node defaults to enabling route
 > optimization, there MUST be a way to administratively disable it", though
 > I'm not sure if that's optimal either.

I agree that we should not force configuration interfaces for all
nodes. We can fulfil your request for some of the other cases
in the document, but I think this one is kind of special.

This requirement comes from a section which is for nodes that wish to
support RO. Assuming we do not want to have nodes that support RO and
who are unable to turn it off, this is about the best we can do at the
moment. For instance, in your suggestion, if the node defaults to RO being
disabled, it must have a configuration interface or otherwise RO is
just dead code.

(Nodes that don't want a configuration interface should not do RO.)

 >    o  Every IPv6 router SHOULD be able to send an Advertisement Interval
 >       option (Section 7.3) in each of its Router Advertisements [12], to
 >       aid movement detection by mobile nodes (as in Section 11.5.1).
 >       The use of this option in Router Advertisements MUST be
 >       configurable.
 >
 > as above, I personally like a MUST but it seems a bit strong, for _all_
 > routers..?

I agree, particularly when the requirement to send these options is
only a SHOULD. Let's change it to a SHOULD.

 >    o  Every IPv6 router SHOULD be able to support sending unsolicited
 >       multicast Router Advertisements at the faster rate described in
 >       Section 7.6.  The use of this faster rate MUST be configurable.
 >
 > see above

Yes. I suggest changing the text to "If the router supports this, the
rate MUST be configurable.".

 >    Packets addressed to
 >    the mobile node's site-local address SHOULD NOT be tunneled to the
 >    mobile node by default, but this behavior MUST be configurable to
 >    enable it; currently, the exact definition and semantics of a "site"
 >    and a site-local address are incompletely defined in IPv6, and this
 >    default behavior might change at some point in the future.
 >
 > MUST for a config knob like this seems too harsh a requirement to me,
 > a required knob to enable site-locals?  Come on..

As a part of other discussion this text has been removed and what
remains is just a "SHOULD NOT be tunneled to the mobile node". I see
that I have some complaints about that still on my Inbox. But I think
we can find consensus on this; those who want to use site-locals can
go against the SHOULD without problems. At that point, they also know
that they may not want to do this for all mobiles.

 >    multicast recipients).  Multicast packets addressed to a multicast
 >    address with scope larger than link-local but smaller than global
 >    (e.g., site-local and organization-local [3]), to which the mobile
 >    node is subscribed, SHOULD NOT be tunneled to the mobile node by
 >    default.  This behavior MUST be configurable to allow it to be
 >    enabled.
 >
 > again, a rather harsh requirement.

See above.

 >    On some types of network interfaces, the mobile node MAY also
 >    supplement this monitoring of Router Advertisements, by setting its
 >    network interface into "promiscuous" receive mode, so that it is able
 >    to receive all packets on the link, including those not addressed to
 >    it at the link layer (i.e., disabling link-level address filtering).
 >    The mobile node will then be able to detect any packets sent by the
 >    router, in order to detect reachability from the router.  This use of
 >    promiscuous mode may be useful on very low bandwidth (e.g., wireless)
 >    links, but its use MUST be configurable on the mobile node since it
 >
 > the MUST requirement needs re-phrasing.  "If it is enabled by defaults,
 > its use MUST be configurable..." ?

Yes. How about "If the mobile node supports this functionality,
its use MUST be configurable."

Jari

---

From: Pekka Savola <[email-masked]>
Date: Wed, 19 Feb 2003 18:49:12 +0200 (EET)

> most of them, though the first one may not be necessary (or possible).

I agree with all of the suggestions -- even the first one.  I agree it's 
special.

Thanks.

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