Here some late comments, inline.
Some of the comments are made earlier by myself and others.


> -----Oorspronkelijk bericht-----
> Van: Shubhranshu [mailto:shubranshu@gmail.com]
> Verzonden: vrijdag 23 november 2007 17:26
> Aan: autoconf@ietf.org
> Onderwerp: [Autoconf] Some Thoughts on Problem Statement.
> 
> All,
> 
> Below are some thoughts that might help us a more focused discussion
> and clarify some of  the issues. Please send your comments such that
> we can further refine / clarify them.
> 
> 
> 
> A MANET router needs to configure an IPv6 prefix(es) on its host
> interface

I think we are still looking for a term for this interface. We could borrow
Ingress Interface from NEMO. Manetarch uses "behind the router" or
"non-MANET interfaces(s)". Problem Statement uses "non-MANET interfaces".


> and/or an IPv6 address on its loopback interface. Besides,
> it needs to configure a /128 (or /32 in case of IPv4) and/or a link
> local address on its MANET interface. 

As mentioned before, I want to keep link-locals. So I would say "and a
link-local address on its MANET interface".
And I do not see a reason for distinguish prefix length for loopback and
MANET interface. Both have the same requirements: the prefix is assigned to
a single router.
In manetarch, a /64 is used for loopback (is OK, but /128 can be used also)
and a /128 is to be used for MANET interface, although it is mentioned that
shorter prefix lengths are possible. I think the last paragraph in 5.1 is
not correct, a /64 prefix may be used for MANET interface, and the summary
/62 may be added in the MANET Routing protocol, instead of a couple of /64
and /128 prefixes. Why not aggregating prefixes at the source?


> A MANET router may also
> configure a prefix shorter than /128 (or /32) on its MANET interface
> provided prefix uniqueness is guaranteed [MANET-Arch I-D]. MANET node
> needs to configure "MANET scope" address to communicate among
> themselves. "MANET Scope" addresses are currently not specified /
> standardized within / outside the IETF.

Currently I do not see a reason for defining a new scope. I think ULAs can
be used. And "MANET scope" is natural, connectivity is limited by
connectivity;-)


> 
> As mentioned above, there are three interfaces under consideration for
> address  auto-configuration. Further detail related to these address
> auto-configuration is provided below:
> 
> 1) Configuration of loopback interface:
> 
> It is possible that a MANET Router does not have any host attached to
> its network interface or it has only MANET interface which can be used
> for intra-manet communication. In the absence of any "external" host,
> MANET router may configure an IPv6 global address on its loopback
> interface. The traditional auto configuration procedure such as RFC
> 2462, can be used for this purpose provided the MANET router has been
> assigned a suitable prefix. As usual, this interface is expected to
> send multicast RA/RS messages. However, in this case, these messages
> would be limited to the Router's loopback interface only.

I think a loopback interface needs MLA and/or global address. 
Link-local address on a loopback interface is not very useful, nor sending
RA/RS messages.
I think using loopback interfaces is optional and not really needed.
Addresses assigned on MANET Interface(s) or non-MANET Interface(s) can be
used for communication within or outside the MANET.


> 
> 2) Configuration of MANET interface:
> 
> MANET Router uses this interface to communicate with other MANET
> Routers. 

I do not see a reason for this limitation. There could be communication with
all other nodes, as long as these are reachable and an appropriate address
is used.


> MANET routing and other MANET specific protocols are expected
> to run on this interface. This interface SHOULD be configured with a
> link local address and/or a /128 (in case of IPv6) or with /32 (in
> case of IPv4) address. 

I think we are emphasizing using /128 too much.
And I suggest sticking on IPv6.


> MANET interface may also use smaller prefix
> provided the prefix uniqueness is guaranteed. 
> Configuration of MANET
> interface with a link local address and/or a /128 address is
> straightforward, as it can use existing mechanisms, except the issue
> of address uniqueness test over "multi-hop network".
> 
> The probability of address duplication is quite low if most of the
> /128 bits are randomly generated and so a node may skip address
> uniqueness test. However, address uniqueness detection / resolution is
> a requirement when smaller prefixes are used and also in military &
> other critical MANET application scenarios.

Mixed usage of "address" and "prefix".

I do not see reasoning for different approach "military & other critical
MANET application scenarios". 
Maybe we won't use active uniqueness detection / resolution there because
DoS attack vulnerability.


> The address uniqueness
> detection / resolution should be done across the entire network thus
> requiring that the specific broadcast/multicast messages used for this
> purpose be propagated "even to MANET Routers that are multi-hop away".
> Currently there is no standard specification that addresses this
> requirement.

This will make the MANET Router vulnerable for DAD DoS attacks from the
whole MANET.
Passive DAD is no problem.


> 
> 3) Configuration of Host interface:
> 
> MANET router needs an unique prefix(es) such that it can configure the
> prefix on its host interface. This prefix may further be subnetted and
> used for address configuration of the hosts attached to the MANET
> router. 

What is subnetted?
Do hosts need a subnet?
I have more comments when I know what was intended.


> In this scenario a MANET Router should receive one or more
> unique prefix(es). This is further explained below for the scenario
> where DHCP server is available (i.e connected MANET) and for the
> scenario where there is no server available (i.e. Standalone MANET):

Why can't there be a DHCP server be available in a Standalone MANET?


> 
> - Scenario where DHCP server is available.
> 
> In this case the DHCP server could be either co-located or directly
> reachable to the MANET Boarder Router. If the server is directly
> reachable, as shown in the figure 1 below, then MANET Boarder Router
> can use existing DHCP request-reply  messages (RFC 3315) between
> itself and the DHCP server in order to receive prefix(es). The MANET
> Boarder Router can then delegate those prefixes to the MANET routers
> connected to it either directly or over multi-hop routes. It should be
> noted that the link between the MANET router and its attached host
> follows the classic link model and SHOULD use the relevant traditional
> protocols for address configuration.

This will work with SBI also.


> 
> The above mentioned DHCP request-reply mechanism normally assumes
> direct or stable i.e. not a dynamic multi-hop route connectivity
> expected between the requesting node and the DHCP server.

This works with DHCP Relay also.


> MANET
> routers dynamically update routes & frequently change neighborhood and
> are multi-hop away from the DHCP server e.g. MR3 in Fig 1. These,
> however, does not require a complete protocol design but rather puts
> some requirements on the existing protocols [e.g. RFC 3633]. Currently
> there is no standard to address these requirements or that allows that
> MANET nodes should act as a dynamic DHCP relay.

Another problem is: which ISP is being used, via which Border Router? 

In the example of Fig 3, MR3 sends to All_DHCP_Relay_Agents_and_Servers.
Then, first hop MNR (configured with Global Address) sends to
All_DHCP_Servers or to a DHCP unicast address. 
Sending to All_DHCP_Servers should work, as long as MANET supports
multicast.
I do not think this mechanism is optimal. In a dense MANET, there could be
an awful lot of All_DHCP_Servers site-local multicasts. Also the large
number of relayed unicast messages could be unacceptable.
The problems shall be further analyzed.


> 
>                                                          -----
> MR1...MR3
>                                                     /      .
>    +-------------+          +------------+  | /       .
>    |               |   p2p   |  MANET   |/        .
>    |  ISP Edge|   Link  |  Border    |         .
>    |   Router   +---------+  Router    |\        .
>    |                |          |                |  \       .
>   +-------------+           +------------+      \----- MR2
> 
> 
> Fig 1 (same as fig 1 in draft-ietf-autoconf-statement-02)
> 
> - Scenario where no DHCP server is available.
> 
> By its very nature, MANET environment does not always assume
> availability of any pre-configured server. Even in such scenarios a
> MANET router needs to configure an unique prefix. Traditionally,
> protocols such as RFC 2462 are used for address configuration of nodes
> in stateless manner. However,  RFC 2462 defines address auto
> configuration mechanisms for nodes (host and router) and as such it
> does not provide any mechanism for allocating "unique prefix(es)" to
> the routers. For example, in Figure 2 below, a MANET Router, say MR3,
> may need to receive prefix(es) (which can be further subnetted and
> used for address configuration of its attached host nodes) from the
> MANET Boarder Router /Access Router. Currently no specification exists
> that addresses this requirement.

ULAs can be generated very easily. Each MNR gets its own /48, or own /64 to
reduce collision probability.
Bytheway, MR is Mobile Router, not MANET Router.


> 
>                              -- MR1...MR3 ....MR5
>                    /
>                  /               .
>                 /                 .
>          MR4                   .
>                  \
>                     \
>                       \ -- MR2 ...
> 
> Fig 2. (same as Fig 2 in draft-ietf-autoconf-statement-02)
> 
> 
> Mobile and wireless nature of MANET routers result in dynamic network
> topology [MANET-Arch ID, RFC 2501] which has the property of changing
> neighbor nodes. These MANET properties result in network partitioning
> and merger of initially isolated networks. Normally, once an address
> is allocated to a node, it continues using it and collaborating to
> detect and resolve duplicates in case its address is allocated to any
> other node. Since initially isolated MANETs had allocated  addresses
> independent with each other, there remains probability of more than
> one node using same address. Currently there is no specification that
> solves problem of MANET "network merger detection" and duplicate
> address detection/ resolution resulting due to two / more MANETs
> merger.

I like to see the analysis of the probability for collisions.

> 
> It is desirable that network partitioning is also detected such that
> resources / prefixes that were allocated to the outgoing nodes could
> be re-used. Currently there is no specification to solve the problem
> of MANET  "network merger detection".

Last words:
What I am missing here is a reference to PacketBB. In MANET, usage of
compressible addresses is highly preferred. Therefore, prefixes need to have
a shared prefix (and suffix). Well coordinated prefix delegation is required
to arrange this. And we should think of methods for prefix aggregation, for
advertisement of a single prefix by a MANET Router.

I think we have two Autoconf categories:

1: SLAAC / ULA
Only to be used in cases where self-generation of address / prefix
generation is required, e.g. option 2 is not applicable.
Random addresses and prefixes are unique with very high probability.
Address compression is typically not possible. 
DAD is normally not really needed (to be analyzed).

2: Manual / DHCP / AAA / MIPv6 bootstrap / NEMO MNP delegation / other
Used whenever possible, e.g. connectivity to a Delegating Router (RFC3633
terminology) exists.
Managed addresses and prefixes should be unique, depending on manual
configuration or implemented protocols and platforms.
Address compression is possible, depending on (to be analyzed).
DAD is normally not really needed (to be analyzed).

Teco.

> 
> 
> _______________________________________________
> Autoconf mailing list
> Autoconf@ietf.org
> https://www1.ietf.org/mailman/listinfo/autoconf



_______________________________________________
Autoconf mailing list
Autoconf@ietf.org
https://www1.ietf.org/mailman/listinfo/autoconf