Subject: [Autoconf] Review of tentative draft-ietf-autoconf-statement-03.txt

From: "Ulrich Herberg" <[email-masked]>
Date: Mon, 26 Nov 2007 15:05:11 +0100

Dear all,

I have some comments on the autoconf statement (03). In some way I
agree with Dave Thaler (comments inline):

> > From: Dave Thaler <[email-masked]>
> > Date: November 21, 2007 10:34:11 PM CEST
> > Subject: Review of draft-ietf-autoconf-statement-02.txt
> >
> > 1) The document is supposed to be a problem statement, and it does
> > not really state what the problem is.  It concludes that existing
> > solutions can't work, but provides no discussion of this to
> > motivate that conclusion.  That is what, in my view, is the point
> > of a problem statement document and as such should be a significant
> > contribution.  This is the main reason why I feel it needs
> > significant work before WGLC.

In my opinion, the problem statement should state more prominently the
problems of autoconfiguration and existing solutions (e.g. IPv6
stateless autoconfiguration, DHCPv6). In section 4.1.1, part of these
problems are mentioned, but under the section "goals". I would rather
change the order of section 4.1 and 4.2 and first speak of issues THEN
of goals how to solve these issues. To my understanding, a discussion
of problems of existing solutions would rather belong to the section
"issues" than to "goals".
Maybe one could also underline that the main problem of existing
solutions like IPv6 stateless autoconfiguration is not only that it
"do[es] not account for potential address duplication beyond a single
[...] link" (from section 4.1.1), but that it has a completely other
intention: namely to configure HOSTS, while we are talking about
assigning prefixes to ROUTERs.

In section 4.1., "the primary goal of MANET autoconfiguration is [...]
to provide mechanisms for IPv6 prefix provision and address assignment
for operation on MANETs". This formulation -- though probably correct
-- sounds a bit vague for me. I have another idea in my mind which
would be:
"The primary goal of MANET autoconfiguration is to allocate globally
unique and topologically correct prefixes, and IP addresses to MANET
interfaces. "

This primary goal is probably not always desirable or necessary;
that's why I would add some "subgoals" in a hierarchical sense:
1. configuration of unique link-local addresses / prefixes
2. configuration of unique MLA addresses / prefixes
3. configuration of global addresses / prefixes
One or more of these subgoals can be achieved by autoconfiguration.

Looking at the table of contents of the draft, I see the following
subsections of
  4.1 MANET Autoconfiguration Goals
    4.1.1 Multi-hop Support
    4.1.2 Dynamic Topology Support
    4.1.3 Network Merging Support
    4.1.4 Network Partitioning Support

Are these really the the main goals of autoconfiguration? If I think
of goals of autoconfiguration, I would have something different in
mind. Some of these would be (feel free to comment...)
    - MANET nodes need to have unique prefixes within the desired scope
    - The prefixes of MANET routers should be easily aggregatable
using Classless
      Inter-Domain Routing (CIDR).
    - Hosts should be automatically configured using the prefix of the
router they are
connected to (e.g. using IPv6 Stateless Autoconf.)
    - All subgoals mentioned above should be accomplishable:
      autoconfiguration of unique link-local addresses/prefixes,
autoconfiguration of
      MANET-local unique addresses/prefixes, and configuration of
global prefixes.
    - The achievement of one subgoal should not depend on the accomplishment of
another (e.g. allocation of MANET-local prefixes should not depend on link-local
addresses).
    - The solution should be independent of any particular routing protocol.

Another idea would be to think about the following question: "what do
we actually want to autoconfigure? hosts? routers?". I would propose
add some sentence like:
"FIRST we need to autoconfigure the MANET interface of the ROUTERS
(i.e. assigning a unique IP address to the MANET interface, and a
prefix to the router); THEN we can configure HOSTS attached to this
router e.g. by using existing protocols like IPv6 SA". Even if the
difference is stated in section 5.1 of the manetarch draft, it could
be useful to remind the difference of autoconfiguration of the ingress
interface (thus the MANET interface) and the egress interface (thus
the attached network to the router -- which may be any kind of
network).

Regards,
Ulrich

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 26 Nov 2007 15:50:32 +0100

I mainly agree with the tendency of this message.  One little comment 
with respect to formulating a problem stressing SLAAC (stateless 
autoconf) does not work for routers.

> assigning prefixes to ROUTERs.

I agree with the suggestion after having noticed myself and other 
colleagues assuming SLAAC autoconfiguration would work with MANET 
Routers and then correcting selves on second thought.  I'd push it further.

I'd add that maybe that tendency of assuming SLAAC working for Routers 
is from the simplicity on implementation to make SLAAC work for routers 
(on linux simply switch a sysctl flag) and on the spec to simply decide 
(for example) that a certain "MANET Interface" is acting as a "Host" 
instead of a "Router".  For example, a NEMO Mobile Router decides its 
"Egress Interface" is acting as a Host instead of a Router thus _can_ be 
autoconfigured with SLAAC.

This doesn't mean your remark is incorrect - I agree with it.

I'd rather try to identify _why_ SLAAC on a Router's interface would 
have limitations and what protocol would it break.

If we have two routers both sending RAs to each other with two different 
prefixes - which Router should configure its address from which Router? 
  Should Router1 auto-configure an address from the prefix in Router2's 
RA?  Or the other way?  Or both?  Is this a problem?

Just some thoughts.  I mainly agree with the direction of your message.

Alex

> the attached network to the router -- which may be any kind of

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

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 27 Nov 2007 10:52:12 +0100

Some questions on recent discussion on draft-ietf-autoconf-statement-03.txt:

Is there a -03 version?

Recently, it is posted that a MANET Interface have a unique prefix (e.g.
/128) and/or a link local address.
I do not understand why there would be no link-local. E.g. for OSPFv3 (and
OSPFv3-MANET, I do not expect an update):
>>>> RFC2740, page 6:
>>>> OSPF for IPv6 assumes that each router has been assigned 
>>>> link-local unicast addresses on each of the router's attached 
>>>> physical segments.
I think adding a unique prefix is OK, to be used for communication with
nodes on other links. But why not using the link local for MANET Routing
protocols and other link-local protocols? This seems so obvious to me.

I think the impact on using an unique prefix as source address for routing
protocols is not well understood. I know I speak for myself;-)

Teco.