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

Hi Ronald,

comments inline...

Velt, R. (Ronald) in 't wrote:
> 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.
>   

I am not against adding a few additional words explaining the purpose of
this document if this is felt to be necessary. As you suggested, these
recommendations reflect *our* experience of how to configure a MANET, in
a way that (i) works and (ii) does not break the IP model. Of course,
there may be other ways of doing so.
> 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.
>   
Again, I am not against adding IPv6 examples in the appendix if it is
considered to be useful. The original intention was to keep the draft short.

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

I am tempting to remove or replace the term MANET "node" as it could be
ambiguous. Thomas, would do you think? 

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

MANET protocols will use the newly allocated LL-MANET-Routers multicast
address specified in RFC 5498 for broadcasts within the local neighborhood.
> 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 :-)
>   

I let the other author reply to this as I figure it was him in Vancouver ;-)

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

Indeed, it might be convenient. In the draft, we only specify that MANET
interfaces MUST be configured with a /32 or /128 host prefix. Using
unnumbered interfaces is described in the examples and worked for our
settings. You can still follow the draft by assigning a /32 (/128)
prefix in a different way than using unnumbered interfaces.

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

I don't understand your question here. In the example in section 3.3, it
is said that this address (which is a /32 address) is unique at least
within the MANET, so it is conform with section 2.2. What would you like
to change or get explained here in addition?

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

It's a bad thing if a software breaks an RFC ;-) Anyway, the ICMP
redirects are just a "symptom" of a broken network configuration. So
while you could simply "treat" the symptom by suppressing ICMP
redirects, you could as well respect the IP model instead of breaking it.

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

Yes, this seems to be a valid configuration for me. As you said, it
might not be a common case and in particular it gets dangerous if there
pops up a new router in your example with, say, 192.168.2.253/24. As we
say in section 1:

    "Caveat lector: Other configurations and deployment approaches for
   MANETs are likely possible, and should not be disregarded or
   excluded.  This document, however, describes a set of configuration
   and deployment recommendations, which practical experience and real-
   world deployments have shown to be feasible."

So while we could enumerate all other possible configurations, we prefer
to present one that works for us and that does not break IP. There
probably are other ways of doing so.

For the broadcast, you would rather use LL-MANET-Routers than the
broadcast address 255.255.255.255.

>
> 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 (?)
>   
Thanks! :-)

> (End of comments)
> This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html
>
> _______________________________________________
> Autoconf mailing list
> Autoconf@ietf.org
> https://www.ietf.org/mailman/listinfo/autoconf
>   

Cheers,
Ulrich