[Autoconf] Comments on draft-clausen-manet-autoconf-recommendations-00

["Velt, R. (Ronald) in 't" <[e-mail]>]

Thomas, Ulrich, all,

Please find below some comments on
draft-clausen-manet-autoconf-recommendations-00.txt

Regards,
Ronald in 't Velt


Comments on I-D title, abstract and introduction:
-------------------------------------------------

It is not entirely clear to me what the intention behind this I-D is. Is
the goal that it evolves into the "one practical addressing model" that 
the proposed new WG charter calls for? Is it merely a description of one

(tried and tested) way in which MANET addresses could be configured? If 
the latter, why is the the word "Recommendations" in the title? The 
specified "intended status" of the I-D is "informational". RFC2026,
sec. 4.2.2. says:

> An "Informational" specification is published for the general
> information of the Internet community, and does not represent an
> Internet community consensus or recommendation.

Of course, this does not rule out that this I-D contains recommendations
from the authors. However, it seems to me that "recommendations" is a 
slightly awkward term. Some additional words of explanation might help.

Also, the I-D mentions several times that the presented approach is
supported
by an "existence proof", i.e. its viability has been proven by
succesfully 
deploying MANETs this way. At the same time, the addressing examples
given in 
the document all seem to be based on IPv4. (Even though the text
frequently 
says "/32 or /128"). This begs the question whether the "existence
proof"
extends to real-world IPv6 MANETs. Perhaps it would be useful to add an
appendix to the document, which provides details like platform / OS
(version), 
IPv4 or IPv6, etc. on some of the networks that the authors have gained 
experience with and based their "recommendations" on.


Comment on section 2.1, MANET "Node" Morphology
-----------------------------------------------

The I-D says:

| 2.1.  MANET "Node" Morphology -- Hosts and Routers
|
|    Each "independent node" in a MANET can functionally be described
|    according to Figure 1, with the "MANET node" being composed of a
|    "MANET router" (R) with one or more "MANET interfaces" -- i.e. the
|    interface which is to be used for establishing connectivity between
|    MANET routers -- as well as zero or more interfaces towards other
|    networks or hosts on classic IP links.
|
|                                   \|/
|                   MANET interface  |
|                        +-----------|---------------------+
|                        |        +--+------+              |
|                        |        |    R    |  MANET router|
|                        |        +---------+              |
|                        |         |      |                |
|                        |      +---+     | Classical IP   |
|                        |      | H |     | links with     |
|                        |      +---+     | hosts          |
|                        |         _______|______          |
|                        |        |       |      |         |
|                        |      +---+   +---+  +---+       |
|                        |      | H |...| H |  | H |       |
|                        |      +---+   +---+  +---+       |
|                        |                                 |
|                        +---------------------------------+
|                                    MANET node
|
|                      Figure 1: MANET "node" morphology
|

Terminology: What is shown in Fig. 1 is not a node, but a collection of
nodes:
one router and several hosts.


Comment on section 2.2, MANET Interface Configuration:
------------------------------------------------------

The I-D says:

| 2.2.  MANET Interface Configuration
|
|    The following summarizes the configuration constraints for MANET
|    interfaces of a MANET router:
|
|    o  Each MANET interface on a MANET router MUST be configured with
an
|       IP address which is unique, at least within the MANET.
|
|    o  Each MANET interface MUST be configured with a prefix length of
|       /32 (for IPv4) or /128 (for IPv6).
|

What is, conspicuously, missing here, is a "recommendation" on what IPv4
broadcast address should be configured on the MANET interface. I think 
this should be added, along with a subsequent "rationale and
justification" 
in Section 4.

Comment on Section 3.1, MANET Router and Single Host
----------------------------------------------------

The I-D says:

| 3.1.  MANET Router and Single Host
|
|    Figure 3 illustrates a MANET node consisting of a MANET router with
a
|    single MANET interface and a single host.  This is the typical
case,
|    for example, when one has a laptop, PDA or smartphone participating
|    in the MANET: the "router" and the "host" are in that case logical
|    components within the same device, and with a single physical
|    interface.
|
|    The MANET node is assigned a single IPv4 address, in this case
|    192.168.1.1.  This IP address is to identify both the MANET
interface
|    of the MANET router as well as the host.  Logically, this is
|    accomplished by configuring the interface of the MANET router as an
|
Shouldn't that read: "the interface of the host?"
|
|    "unnumbered interface", by assigning 192.168.1.1/32 to the MANET
|    interface of the router.  Traffic to the logical component that is
|    the router will typically be addressed to a well-known multicast
|    address, thus the router can distinguish between traffic to itself
|    and traffic to the logical host.

This seems to contradict a previous interpretation of the (now dead, but
not forgotten) MANET Architecture I-D, which was that a host, even if 
co-located with / internal to the MANET Router, could not adopt the IP 
address of the MANET interface.  I recall asking this specifically at
the 
microphone during the Autoconf session in Vancouver (IETF-70), saying
that 
is was common practice and being told that people had been doing it
wrong 
for years (by none other than one of the authors of this I-D :-)


Comment on Section 3.2, MANET Router and Attached Network w. Prefix
Delegation
------------------------------------------------------------------------
------

The I-D says:
-------------

| 3.2.  MANET Router and Attached Network w. Prefix Delegation
|
|    Figure 5 illustrates a MANET router with a single MANET interface
and
|    an interface towards a classic IP link such as an Ethernet.  The
|    MANET router is delegated the IPv4 prefix 192.168.1.0/24.  That
|    prefix is assigned to the non-MANET link, on which interfaces are
|    assigned addresses such as 192.168.1.1/24, 192.168.1.2/24,
|    192.168.1.3/24 etc.  Note that the interfaces on that classic IP
link
|    are configured with a prefix length of /24, indicating that the
|    interfaces with addresses from within that IP prefix are all
|    reachable within a single IP hop.
|
|    The MANET interface is configured as an "unnumbered interface" by
|    "borrowing" the address (192.168.1.1) from its interface towards
the
|    classic IP link - but is configured with the prefix length /32.
The
|    MANET interface is, specifically, not configured with a prefix
length
|    of /24, even though that prefix is delegated to the MANET router,
as
|    the MANET interface is not able to reach all other interfaces with
|    addresses from within 192.168.1.0./24 in a single IP hop.
|
|
|
|                  192.168.1.1/32  \|/
|                      +------------|------------+
|                      |            |            |
|                      |          +-+-----+      |
|                      |          |   R   | 192.168.1.0/24
|                      |          +-------+      |
|                      |192.168.1.1/24 |         |
|                      |               |         |
|                      +---------------+---------+
|                                      |
|                           ,----------+-----------.
|                           |          |           |
|                         +---+      +---+       +---+
|          192.168.1.2/24 | H |      | H |       | H | 192.168.1.4/24
|                         +---+      +---+       +---+
|                               192.168.1.3/24
|
|     Figure 5: MANET router (R) with an attached network and a
delegated
|     subnet prefix. Notice that the prefix 192.168.1.0/24 is assigned
to
|    the non-MANET link, where interfaces are configured with that
prefix,
|      e.g. 192.168.1.3/24. The MANET interface "borrows" the IP address
|     from that link, however is configured with a prefix length of /32.
|
|    Traffic to the MANET interface with the IP address 192.168.1.1 can
be
|    distinguished from traffic to the non-MANET interface with the same
|    address since traffic destined to the MANET interface of the router
|    typically will be addressed to a well-known multicast address.

Wouldn't it be convenient if the MANET Router had an address for e.g.
remote
management?


Comment on Section 3.3, MANET Router and Attached Network w/o Prefix
Delegation
------------------------------------------------------------------------
-------

The I-D says:

| 3.3.  MANET Router and Attached Network w/o Prefix Delegation
|
|    Figure 6 shows a situation similar to that of Section 3.2 except
that
|    the MANET router, for whatever reason, is not delegated any prefix.
|
|    As no prefix has been delegated to the MANET router, the MANET
router
|    can not simply "borrow" an IP address from within a delegated
prefix
|    for its MANET interface and know this IP address to be unique --
but
|    has to rely on some other mechanism for acquiring an IP address.
|    Whichever mechanism is used for acquiring this IP address, is shall
|    ensure that this IP address is unique, at least within the MANET.

If I understand Section 2.2 correctly, IP address unicity is a
necessary,
but not a sufficient condition. Its prefix should be unique within the 
MANET as well.

Comment on Section 4.2, /32 and /128 Prefix Lengths
---------------------------------------------------

The I-D says:

| 4.2.  /32 and /128 Prefix Lengths
|
|    In early MANET deployments, a common occurrence was to configure a
|    MANET as "a subnet" and configure it as indicated in Figure 9: the
|    MANET would have a subnet prefix, say 192.168.1.0/24 and MANET
|    interfaces would be configured with this subnet prefix, e.g.
|    192.168.1.3/24.
|
|                    Communication
|                        Range
|             <~~~~~~~~~~~~+~~~~~~~~~~~~> <~~~~~~~~~~~~+~~~~~~~~~~~~~>
|                          |<~~~~~~~~~~~~+~~~~~~~~~~~~>|
|                      +--------+    +--------+    +--------+
|                      |192.168.|    |192.168.|    |192.168.|
|                      | 1.1/24 |    | 1.2/24 |    | 1.3/24 |
|                      +--------+    +--------+    +--------+
|
|         Data packet:     -------------->
|          dest     192.168.1.3
|          next-hop 192.168.1.2
|
|           ICMP Redirect  <--------------
|
|
|      Figure 9: Misconfigured MANET: MANET interfaces configured with a
|      shared /24 prefix, causing the central router to produce an ICMP
|      redirect when forwarding packets from 192.126.1.1 to 192.168.1.3.
|
|    If, for example, a data packet was transmitted by the MANET router
|    192.168.1.1 to be received by 192.168.1.3, then this would -- with
|    reference to Figure 9 -- have to be forwarded by the MANET router
|    192.168.1.2.  With the MANET interfaces in this MANET being
|    configured with the subnet prefix 192.168.1 and the prefix length
|    /24, it was observed that this produced ICMP redirects by
|    192.168.1.2.
|
|    An early, and often suggested, solution was to "treat the symptoms
|    rather than cure the disease" by disabling ICMP redirects on MANET
|    routers -- i.e. to require modifications to the IP stack operation
in
|    order that it can be supporting MANETs.
|
|    The ICMP redirect is intended to be used to inform a source to send
|    packets using an alternative, more direct, route -- e.g. if a
source,
|    s wishes to send a data packet to a destination node d via the path
|    s-R1-R2-d, and if R1 knows that a direct path s-R2-d is available,
|    then the ICMP redirect from R1 will inform s of this route.
|
|    Two interfaces, configured with addresses from within the same
subnet
|    prefix, and with the same prefix length are defined to be reachable
|    from each other within a single IP hop.  More precisely, it is
|    assumed that all interfaces with IP addresses within that subnet
|    prefix and configured with the same prefix length are directly
|    reachable from each other without forwarding by an intermediate
|    router.  Hence, a way for R1 to know that a direct path may exist
|    between h and R2 is if h, R1 and R2 are configured with IP
addresses
|    from within the same subnet prefix and within the same subnet
prefix.
|
|    Returning to the MANET scenario in Figure 9, with all MANET
|    interfaces being configured with the same subnet prefix and the
same
|    prefix length, it follows from the discussion above that all these
|    MANET interfaces are expected to be directly reachable from each
|    other within a single IP hop.  When, in this configuration, the
|    router 192.168.1.2 is requested to forward a data packet from
|    192.168.1.1 to 192.168.1.3, it is expected that it generates an
ICMP
|    redirect to 192.168.1.1 suggesting that a direct path exists from
|    192.168.1.1 to 192.168.1.3 -- as this is what the configuration
|    suggests.
|
|    Rather than "treating the symptoms" and disabling ICMP redirects,
|    requiring /32 and /128 prefix lengths on MANET interfaces "cures
the
|    disease".  An interface so configured will not make any assumptions
|    about other interfaces being within a single IP hop, and so will
not
|    generate ICMP redirects when forwarding traffic.

It may cure (or rather prevent) this disease, but it could introduce
other
ailments.  For instance, Linux has an "rp_filter" kernel parameter, 
described as follows in the kernel documentation
(networking/ip-sysctl.txt):

> rp_filter - BOOLEAN
>	1 - do source validation by reversed path, as specified in
RFC1812
>	    Recommended option for single homed hosts and stub network
>	    routers. Could cause troubles for complicated (not loop
free)
>	    networks running a slow unreliable protocol (sort of RIP),
>	    or using static routes.
>
>	0 - No source validation.
>
>	conf/all/rp_filter must also be set to TRUE to do source
validation
>	on the interface
>
>	Default value is 0. Note that some distributions enable it
>	in startup scripts.

Debian is among the distributions that set rp_filter on start-up by
default,
being non-compliant with RFC1812, section 5.3.8. in this respect. The
effect 
is, that e.g. MANET protocol HELLO's are discarded, because they fail
the 
reverse path check. Of course, this can be fixed through a modification
of a 
configuration file.  In practice, though, this is just as much work as
turning 
off the generation of ICMP redirects.

Furthermore, the use of /32's (/128's) appears to exclude a
configuration
as depicted below:

		 <------------------>	<----------------->
          \|/		         \|/                   \|/
           |			    |                     |
         +-+-+                  +-+-+                 +-+-+
   \|/   | R |   \|/            | R |          \|/    | R |	  \|/
    |	   +---+    |             +---+           |     +---+	   |
  +-+-+         +-+-+	                      +-+-+          +-+-+
  | H |         | H |                         | H |          | H |
  +---+         +---+                         +---+          +---+

  H = host
  R = router

Here, all nodes just have a single radio interface. Some are configured
to be 
hosts, wheras others are routers. Hosts can be considered as
"satellites" of 
routers, in the sense that each of them is associated with a particular
router 
and travels with it. Each host has a default route, with its associated
router
as the next hop.

This can be made to work by assigning e.g. /24's from different
"subnets"
to the routers. For instance, in the picture above, the leftmost router
gets 
192.168.1.254, the middle one 192.168.2.254 and the rightmost router 
192.168.3.254. The broadcast address on the routers should be set to
have a wider 
"scope" (shorter prefix)than their unicast addresses, e.g.
192.168.255.255 or even 
255.255.255.255. This ensures that any protocols that rely on broadcast
still work 
between routers. (Autoconfiguration protocols could potentially fall
into this 
category, as do some older implementations of MANET routing protocols).
Hosts
are configured with addresses from the same subnet as their associated
router. The 
hosts in the leftmost cluster in the picture above would e.g. be
192.168.1.1 and 
192.168.1.2.

It could be argued that for this scenario, separate virtual interfaces
should
be configured on top of the radio interface. One virtual interface would
then serve 
as MANET interface, while the other(s) would be used for communication
with local
hosts. However, depending on the L2 technology / implementation used,
this may not 
be readily achievable.

The above may not be a very common case and therefore we could agree to
not
support it. However, in my opinion this should be a conscious and
documented 
decision.


Comment on Section 4.3, IP Hop Isolation
----------------------------------------

I-D says:

| 4.3.	IP Hop Isolation

     <snip>

|    There are, essentially, four potential ways of addressing this
|    problem: requiring all upper-layer applications and protocols to
|    become "MANET aware", inventing mechanisms for presenting a MANET
|    as-if it was an Ethernet, pushing the problem to layer 2, or
|    encapsulating any MANET specific behavior in a way such that it is
|    only exposed to explicitly MANET aware applications and protocols.

I only count three ways here (?)

(End of comments)
This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html