Subject: Re: [Autoconf] tentative draft-ietf-autoconf-problem-statement-03.txt

From: Shubhranshu <[email-masked]>
Date: Thu, 22 Nov 2007 14:06:50 +0530

----- Original Message -----
From: "Alexandru Petrescu" <[email-masked]>

> This is what I've just sent to Emmanuel about noticed shortcomings of
> DHCP in some MANET-like deployemnts.
>
> Alex
>
>> For the following text:
>>
>>    For example, in Fig. 1, the MANET router MR3 cannot communicate
>>    directly with a DHCP server [4] that would be available through a
>>    border router, since the border router and MR3 are not located on
>>    the same logical link.  While DHCP can to some extent overcome this
>>    issue in a static network, it is not the case in a dynamic
>>    topology, as explained below.  On the other hand IPv6 Stateless
>>    Address Autoconfiguration [5] and Neighbor Discovery for IPv6 [3]
>>    do not account for potential address duplication beyond a single
>>    multicast-capable link.

I can see the problem being described here but yes I agree that it
needs to be expanded, to further calrify things. See below.

<snip>
>>    For example, in Figure 1, we assume that the "p2p Link"
>>    (point-to-point link) and the links BR-MR1, MR1-MR2 and MR2-MR3 all
>>    have distinctive IP subnets assigned.  The MR3 needs to be assigned
>>    an IPv6 prefix.  The MANET router MR3 does not yet know the IP
>>    address of the DHCPv6 Server, so it needs to discover it by using
>>    link-layer multicast mechanisms and IP-layer multicast.  It is
>>    possible for MR2 to run DHCP Relay software.  In this case the MR3
>>    would send a DHCP Solicit message (IP dst address is a IP multicast
>>    address), message preceded by a header containing a link-layer
>>    multicast address as destination.  The Solicit message would be
>>    further sent by MR2 (DHCP Relay) to the the ISP Edge Router (DHCP
>>    Server).  After this initial step the next DHCPv6 exchanges would
>>    be performed such that the MR3 obtains a prefix.

Looks like you are proposing that the problem statement assume or
suggest this way of solving the problems. Are you proposing text for
the problem ID or for the solution ID?

>>
>>
>>                                                        ----- MR1-MR2-MR3
>>                                                       /      .
>>               +-------------+         +------------+ /       .
>>               |             |   p2p   |            |/        .  (MANET)
>>               |  ISP Edge   |   Link  |  Border    |         .
>>               |   Router    +---------+  Router    |\        .
>>               |             |         |            | \       .
>>               +-------------+         +------------+  \----- MRn
>>
>>                        Fig. 1. Connected MANET router topology.
>>
>>    This is a DHCP behaviour that would work in this MANET topology.
>>    However, there may be at least the following two issues:
>>
>>    -in the group of MANET Routers described above there should be a
>>     dynamic decision of roles about who is a Relay and at what moment.
>>     If MR2 disappears from its place and another MR takes its place
>>     then that router should receive the DHCPv6 Solicit sent by MR3 and
>>     relay it to the DHCPv6 Server.

Agree, this is one of the issue. And one possible solution of this may
be, as for an example "Each MANET router should act as a dynamic DHCP
relay".

>>
>>    -some implementations of DHCPv6 Prefix Delegation will not update
>>     routes on the DHCP Server with respect to the allocated prefix.
>>     Or, when assigning prefixes that don't respect a hierarchical
>>     structure it is necessary when using a Relay to add a new routing
>>     table entry at the DHCP Server whenever a new prefix is assigned
>>     to a new MANET Router.  This route should point to the Relay
>>     address.

Hmmm.... again I see lots of text which I think would make a good
content of a proposed solution document.

>>
>>    These are two issues that appear in the topology pictured in Figure
>>    1.  In this figure the DHCP Server, Border Router, MR1 and MR3 are
>>    assumed to be stable non-moving (only MR2 moves).  If we consider
>>    that any entities will also move then there may be more DHCP issues
>>    that could be identified.
>

Yes.

- Shubhranshu

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 22 Nov 2007 14:37:28 +0100

Shubhranshu wrote:
[...]
> needs to be expanded, to further calrify things. See below.

Shubhranshu, thank you for reading my proposal text.  I'm taking the 
comments.  I think I will make modifications as you suggest (see below) 
but I don't think I will do them right away.  I think I will do that for 
the next next IETF (after Vancouver), to let time for things to settle.

Besides, there may be some impact in how the manetarch document is 
written: should the manetarch document picture a non-hierarchical 
addressing architecture (in addition to the pictured _hierarchical_ 
addressing architecture Figure 6).  I think yes because that (manetarch) 
draft says that "MANETs of those sizes can perform reasonably well in 
many cases w/o hierarchy" - what does "hierachy" mean?

> the problem ID or for the solution ID?

For the problem ID.  The DHCP behaviour described above is standard 
behaviour, not anything new.  My use of "would be sent" is to mean that 
I really think that that happens, but to check whether anyone else 
thinks that doesn't happen that way.

> be, as for an example "Each MANET router should act as a dynamic DHCP

I think this is solution indeed.  I think we can discuss this solution 
at further length in solution draft.  But I think an issue should be 
described in the problemstatement as well.

> content of a proposed solution document.

Shubhranshu, I can try to re-formulate that text to express better that 
that is a problem not a solution.  If one tries to run DHCPv6 Server and 
a DHCPv6 Relay, and then a Router behind the Relay requests for a prefix 
(with DHCPv6 PRefix Delegation) then one realizes that (1) the allocated 
prefix must be hierarchically[*] fit within the prefix administratively 
assigned on the Relay's interface towards Router and (2) once the prefix 
is allocated it will unfortunately _not_ be inserted in DHCP Server's 
routing table (because it is already covered by the routing entry 
pointing to Relay's prefix).

This is a problem from implementation.

It could help if we had a requirement (within a bulleted list of Req 
items) on architecture of unicast prefixes assigned on MANET subnets to 
be able to be both hierarchical and non-hierarchical - i.e. there should 
be no strict hierarchical relationship between IPv6 prefixes assigned to 
the MANET subnets (even when the pictured topology seems hierarchical 
tree-like).

To better explain that need to support non-hierarchical addressing 
architectures one would first have to explain hierarchical address 
architecture and then, keeping the same topology, one would do a 
non-hierarchical addressing architecture.  I describe this below. 
(Remark that the manetarch draft only pictures a _hierarchical_ 
addressing architecture in Figure 6.)

An example of a non-hierarchical address architecture followed by a 
hierarchical address architecture is illustrated below.  Assume three 
prefixes: 8000::/length (also represented as "100..." meaning first 3 
bits are "100" and then followed by 125 0s), 4000::/length (010...) and 
c000::/length (110...) and three MANET Routers.

Hierarchical IPv6 address architecture on a topology illustrated as a tree:
                            ------
                           |MANET |
                           |Router|
                            ------
                          /        \
               8000::/1  /          \ 4000::/1
               (100...) /            \(010...)
                     ------        ------
                    |MANET |      |MANET |
                    |Router|      |Router|
                     ------        ------
                        |
                        | c000::/2
                          (110...)

Same topology illustrated linearly, and with a IPv6 non-hierarchical 
addressing architecture:

                 ------            ------            ------
         -------|MANET |----------|MANET |----------|MANET |
        8000::/1|Router| 4000::/1 |Router| c000::/1 |Router|
        (100...) ------  (010...)  ------  (110...)  ------

Both types of IPv6 addressing architecture should be supported by an 
address auto-configuration protocol for MANETs.  This is a requirement, 
within a buletted list.

(if/when this description of hierarchy is agreed then I can suggest
  another useful addressing architecture from MANEMO).

For solution, for example, one could write spec to say that a MANET 
Router acting as a DHCP Server and requesting PD requests from a MANET 
Router acting as a Relay will always update its forwarding information 
base with respect to that Relay and the allocated prefix.  This is 
indeed part of solution.

>>>    that could be identified.

Ok.  I think some more could be identified.  Emmanuel asked the same 
thing.  I think it will take some time to identify them, that's why I 
postpone it to next next IETF.

Please accept my excuses if this looks too pedagogical... it's just my 
means to communicate...

Alex

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 22 Nov 2007 15:41:12 +0100

Correction...

[...]
> Same topology illustrated linearly, and with a IPv6 non-hierarchical 
---------------------------------------------------^ I meant '2' not '1'

Alex