Subject: [Autoconf] Some Thoughts on Problem Statement.

From: Shubhranshu <[email-masked]>
Date: Sat, 24 Nov 2007 01:26:28 +0900

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

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.

2) Configuration of MANET interface:

MANET Router uses this interface to communicate with other MANET
Routers. 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. 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. 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.

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

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

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

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

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

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

_______________________________________________
Autoconf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/autoconf

---

From: Shubhranshu <[email-masked]>
Date: Sat, 24 Nov 2007 02:17:25 +0900

A correction, please see below

---------- Forwarded message ----------
From: Shubhranshu <[email-masked]>
Date: Nov 24, 2007 1:26 AM
Subject: Some Thoughts on Problem Statement.
To: [email-masked]

<snip>

>>  "2462 defines address auto configuration mechanisms for nodes
(hosts and not routers)".

- Shubhranshu

                            -- MR1...MR3 ....MR5
                  /
                /               .
               /                 .
        MR4                   .
                \
                   \
                     \ -- MR2 ...

---

From: mase <[email-masked]>
Date: Sat, 24 Nov 2007 11:27:15 +0900

Dear Shubranshu,

I think that your text cleary describes the issues. My comments and 
questions are in line.

Thanks,
Kenichi

>Currently there is no standard specification that addresses this

The above description only covers pre-service DAD issue. I think that 
we should also describe in-service issue here. Thai is merger of two 
isolated MANETs may bring address conflict and the method of 
detecting and resolving the address conflict is required.

>MANET nodes should act as a dynamic DHCP relay.

I think that MANET Border Router/Access Router is not available or 
meaningful in this scenario where no DHCP server is available 
(stand-alone MANET).

>and merger of initially isolated networks. Normally, once an address

In this paragraph, you use address. Is this ok? You discuss unique 
prefix issues above.
Should "address" here be replaced with prefix?

>of MANET  "network merger detection".

This should be "network partitioning detection"

---

From: Shubhranshu <[email-masked]>
Date: Sun, 25 Nov 2007 21:44:54 +0900

Prof. Mase,

Please see below:

On 11/24/07, mase <[email-masked]> wrote:
> Dear Shubranshu,
>
> I think that your text cleary describes the issues.

Thank you. (also I received some private e-mail expressing this ....:-) )

>My comments and
<snip>
> detecting and resolving the address conflict is required.

Agree, we need to include them. Later paragraph describes network
merger and related issues.

<snip>
> meaningful in this scenario where no DHCP server is available

Right, need to replace with MR4.

> Should "address" here be replaced with prefix?

Prefixes.

> This should be "network partitioning detection"

Typo. Thanks for catching them.

- Shubhranshu

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 26 Nov 2007 16:24:38 +0100

Shubhranshu, thanks for your message.  To my reading, your message has 
structure in it; e.g. it says which are the cases to be followed.  It 
also seems to take into account most major ideas having already been 
exposed (since the little while I follow it).  I agree with it.  I have 
some comments.

Overall, I'm trying to identify where and how do protocols break.

Shubhranshu wrote:
> local address on its MANET interface.

I yet have to understand why MANET router has to configure a prefix on
its loopback interface.  It's probably by proper definition of MANET -
in that case, sorry, froget  it.

On another hand, if a Router has a prefix in its config file and looks
for a way to configure a address from that prefix on one of its real
interfaces, then one possibility is to derive itself an address from its
Ethernet MAC address, attach it to that prefix and then 'ifconfig' and
'route add'.  Another alternative is to send RAs on its loopback
interface with that prefix, and let the IPv6 stack autoconfigure
address, prefix and route as usual.  These are two choices.

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

Ok, I think "prefix uniqueness" is something not simple to define.

I think comparing addresses /128 is simple because they're fixed length.

Comparing a /128 address to a set of prefixes is also simple because we 
have the "longest prefix match".

But comparing two prefixes has many other undefined possibilities.

I think though a human administrator can easily plan an addressing 
architecture and static routing where prefixes are unique, store those 
in a set of files.

Also, MANET Scope is somehting I need to understand better.  Is MANET 
Scope in any relationship with the existing scopes: link-local scope, 
global scope?  Is MANET Scope in some relationship with the scope of the 
all-manet-routers IP multicast group requested by manet-iana document?

Is MANET scope in some relationship with the scopes of the following 
Ethernet MAC multicast addresses: 33::1 (all Ethernet hosts), 33::2 (all 
Ethernet routers), or other Ethernet MAC multicast group scopes?

_some_ relationship?  _No_ relationship whatsoever?

> As mentioned above, there are three interfaces under consideration
> for address  auto-configuration. Further detail related to these
> address auto-configuration is provided below:
> 
>  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.

This makes me think the MANET Router doesn't communicate  to anybody 
else than self.  Its (real) network interface has no hosts attached to 
it (has Routers attached to it?), MANET interface is virtual and 
loopback interface leads to self.  I may misunderstand you.

Also, I will have to read other documents to understand why the loopback 
interface needs to have address/prefix. If I understand that then maybe 
I can understand the above as well.

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

I agree.

If the MANET interface is virtual then I think there's no standard for 
defining link-local address on a virtual interface.  People do different 
things for these, sometimes random.

I think a good virtual interface (MANET interface or other) would need:
-a link-local address (/128 length).
-a link-local prefix (the fe80 /10 length).
-maybe a global subnet prefix with global address.
-maybe another global subnet prefix with a global address.

I think you mean that "MANET Interface" means a sort of a label we put 
on a real network interface.  Something that in some contexts some 
people call "egress interface", or "ingress interface".

So, if you mean MANET Interface is a real interface, then we may already 
have a means to form a link-local address for it.

> uniqueness test. However, address uniqueness detection / resolution
> is a requirement when smaller prefixes are used and also in military
> & other critical MANET application scenarios. The address uniqueness 
>  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.

I think I'd suggest that when the MANET network uses subnets with 
well-defined link-layer multicast behaviour then the duplication should 
be ensured by DAD.  If the MANET network doesn't use such subnets, or 
uses SBI (semi-broadcast interface) then the address uniqueness 
detection should be indeed done across the semi-subnets (maybe define 
semi-subnet).

Or maybe that address uniqueness should be _ensured_ across the entire 
MANET network, probably with a detection mechanism that acts on a scope 
lesser than the entire MANET network.

This is related to that MANET scope...

I will read the tail of this message later.

Thanks,

Alex

> 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. 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):
> 
> 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.
> 
> routers dynamically update routes & frequently change neighborhood
> and are multi-hop away from the DHCP server e.g. MR3 in Fig 1. These,
>  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.
> 
> ----- MR1...MR3 /      . +-------------+          +------------+  | /
> . |               |   p2p   |  MANET   |/        . |  ISP Edge|
> Link  |  Border    |         . |   Router   +---------+  Router    |\
> . |                |          |                |  \       . 
> protocols such as RFC 2462 are used for address configuration of
> nodes in stateless manner. However,  RFC 2462 defines address auto 
> MANET Boarder Router /Access Router. Currently no specification
> exists that addresses this requirement.
> 
> -- MR1...MR3 ....MR5 / /               . /                 . MR4
> . \ \ \ -- MR2 ...
> 
>  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.
> 

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: "Ulrich Herberg" <[email-masked]>
Date: Tue, 27 Nov 2007 09:33:53 +0100

Hello Alexandru, hello Shubhranshu,

I also think that the text by Shubhranshu is very useful; some
comments inline...

> in that case, sorry, froget  it.

To my understanding, this loopback interface serves as a "logical"
host on the MANET node (correct me if I am wrong). As in real-life
scenarios, most of the time a mobile node will not only be a router
but some mobile device (PDA, laptop, ...), it will run some
applications on it (e.g. web browser). The loopback interface
definitely needs to be explained in the manetarch draft as I am also
not sure whether my explanation is correct.

Another reason of using the loopback interface could be to not
attribute an IP address to the MANET interface but using unnumbered
interfaces (as specified by Cisco).

> address, prefix and route as usual.  These are two choices.

I think that this is correct. While the first case is simpler, it
would mean changing the way of how a network interface is configured.
By the way, do you know how the loopback interface in for example
Linux is configured? That would be an interesting comparison. Sure, it
normally has ::1/128 as fixed address, but could one assign prefixes
to it using RA messages?

> architecture and static routing where prefixes are unique, store those

I think your concern is what happens if you compare two prefixes which
are shorter than /128. My guess is that you still have to check for
uniqueness of all 128 bits, as you we still talk about IP addresses
(not prefixes) on the MANET interface. (prefixes are only later
assigned on the egress interface of the router). However, the
following situation could appear: two MANET interfaces configured with
the following addresses:
  -- node A: a:b:c:d/64  (where each letter means 2 bytes)
  -- node B: a:b:c:d:e/64
The IP addresses are still unique, however, B would be in the subnet
of A. That's probably bad...

> _some_ relationship?  _No_ relationship whatsoever?

I don't know... I do not think that there is a common agreement on
this term. The border between a MANET and the Internet using an ICP
might be understandable (even though it has also been remarked that
when a MANET is connected to the Internet, it is at that moment part
of the Internet). However, when two or more MANETs are in the direct
neighborhod and do not merge but instead add inter-MANET routes
between them using aggregation, the MANET scope is less evident for
me. If MANETs could for example use aggregation for different
hierarchical levels of prefixes, it might be difficult to say: "The
MANET ends _here_".

> I can understand the above as well.

Same for me :-) That's why a description of the loopback interface
would be nice in the manetarch draft.

> things for these, sometimes random.

I don't understand this. Why do you say it is a virtual interface? I
thought that it is a real interface on a mobile node, and that it is
the only interface on the node which knows and cares about MANET
characteristics (e.g. by running a MANET routing protocol on it).

> have a means to form a link-local address for it.

Ah, know I think I understood you. So you mean that a MANET interface
is virtual in the sense that it only a "caption" somehow for a real
(e.g. 802.11) network interface, do you? Well, to my understanding it
probably makes thinks more complicate to talk about a virtual
interface instead of a "real" MANET interface

Regards,
Ulrich