Subject: [Autoconf] List of requirements in draft-ietf-autoconf-problem-statement

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 05 Dec 2007 23:55:50 +0100

Hi all,

	As expressed by me and others, it may be helpful to add a list of clear
requirements of MANET IP autoconf mechanisms in the problem statement
draft. This would help to understand what (and maybe how) has to be done
to solve the problem of IP autoconf in MANETs.

	Collecting this list is not easy, and therefore this mail is a humble
attempt to get other people's opinion and start discussing what this
list should contain. To start, I'd propose the following:

R01. The solution must be implemented at the IP layer level.

(Following recent discussions, my understanding is that we are working
at the IP layer...)

R02. The solution must provide a MANET Router with an IPv6 address for 
     each of its MANET interfaces.

R03. The solution must provide a MANET Router with an IPv6 prefix to 
     configure each of its non-MANET interfaces and be advertised for 
     configuration of non-MANET attached nodes.

R04. The solution must work for MANETs using symmetric and assymetric 
     links.

R05. The solution should not be independent of any particular MANET 
     routing protocol.

R06. The solution must provide MANET routers with unique addresses and 
     non-overlapping IPv6 prefixes.

R07. The solution should detect and resolve IP address conflicts as a 
     result of network mergers.

R08. The solution must provide MANET routers with IPv6 
     addresses/prefixes topologically correct/coherent when the MANET
     is connected to an external network (e.g., the Internet).

R09. The solution should present the same level of security than 
     existing IP autoconfiguration mechanisms.

R10. The solution must ensure backward compatibility with other 
     standards defined by the IETF. In particular, this includes the 
     following:

	R10.1. The solution must not prevent the proper operation of
               Mobile IPv6 (i.e., the solution must allow MIPv6-enabled
               nodes attached to a MANET router to operate either the
	       CN, HA, or MN operations defined in [RFC3775]).

R11. The solution must not require modifications to any node other than 
     MANET routers and required provisioning servers.

R12. The solution may be designed in such a modular way that some of
     the previous requirements are not met if not required by a 
     particular application scenario.

	As previously stated, this is mainly for discussion. I'm not even
saying I agree with all of them ;-).

	Comments are welcome :-D.

	Regards,

	Carlos

-- 
¡ASÓCIATE! Gratis para estudiantes  http://www.telematica.ws
 Carlos Jesús Bernardos Cano     http://www.netcoms.net
 GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  WEEDEV 2008: 1st Workshop on Experimental Evaluation and
        Deployment Experiences on Vehicular networks
                  http://www.weedev.org/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
_______________________________________________
Autoconf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/autoconf

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 05 Dec 2007 18:44:37 -0800

Carlos Jesús Bernardos Cano wrote:
> Hi all,
> 
> As expressed by me and others, it may be helpful to add a list of 
> clear requirements of MANET IP autoconf mechanisms in the problem 
> statement draft. This would help to understand what (and maybe how) 
> has to be done to solve the problem of IP autoconf in MANETs.
> 

Sounds good.  More specifically would be: implement in the IP stack, not
the MAC.  To me, I don't know others.

> (Following recent discussions, my understanding is that we are 
> working at the IP layer...)
> 
> R02. The solution must provide a MANET Router with an IPv6 address 
> for each of its MANET interfaces.

Reasonable.

> configuration of non-MANET attached nodes.

Sounds as modifiable.  One would want a 'distinct' (see the other
thread) prefix for each of these interfaces.

Sounds as colliding with the MEXT WG looking at providing an IPv6 prefix
for use as prefix in the moving network.  That could be collision or
happy coexistence.

> R04. The solution must work for MANETs using symmetric and assymetric

Sounds ok.

> R05. The solution should not be independent of any particular MANET 

Right.

> R06. The solution must provide MANET routers with unique addresses 
> and non-overlapping IPv6 prefixes.

Ok, provided we can qualify these with examples.

>  result of network mergers.

Sounds reasonable.  Not sure though whether there should be a mechanism
for detection or some insurance from a registry.  For example I as
humble seller of MANETs I preconfigure them all with distinct addresses.
  Is this a mechanism, or a central assignment (ULA is an example).

> addresses/prefixes topologically correct/coherent when the MANET is 
> connected to an external network (e.g., the Internet).

Right.

> existing IP autoconfiguration mechanisms.

Sounds reasonable, and I'd enhance it with the 'do no harm' statement
(don't add more insecurity than already is there).  This could be
refined further by a threat analysis.

> R10.1. The solution must not prevent the proper operation of Mobile 
> IPv6 (i.e., the solution must allow MIPv6-enabled nodes attached to a
>  MANET router to operate either the CN, HA, or MN operations defined 
> in [RFC3775]).

ok.

> R11. The solution must not require modifications to any node other 
> than MANET routers and required provisioning servers.

Sounds good, excellent to identify the entities we work on.  But
'provisioning servers' is?  (sounds new term to me).

> particular application scenario.

Ha!

I'd suggest R13 to recommend extension/modification of widely available
software.  For discussion, of course.

> saying I agree with all of them ;-).

I agree with the form of such a list, and I find it pretty useful
actually.  I would be very happy to learn others' opinions on this -
thanks for starting it!

Alex

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

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Thu, 06 Dec 2007 18:23:01 +0100

Hi Alex,

	Just a reply to your question below...

El mié, 05-12-2007 a las 18:44 -0800, Alexandru Petrescu escribió:
[snip]
> 'provisioning servers' is?  (sounds new term to me).

Well, I tried to mean servers, such as DHCPv6 servers or something like
this that might be considered to participate in the address
configuration procedure. Sorry for the new terminology, I didn't know
how to call that.

Regards,

Carlos

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 06 Dec 2007 09:44:11 -0800

> configuration procedure. Sorry for the new terminology, I didn't know

Sounds like we need a name for that?

Looks as if the MANET Router is the one who's going to use the addresses 
and prefixes delivered by a Server.  Or maybe even if the address and 
prefix are to be used by the MANET Router, they are constructed in 
conjunction by the MANET Router and the Server.

That Server seems an important entity.  Maybe another MANET Router can 
be a Server.

Alex

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 12 Dec 2007 10:33:23 +0100

Somewhat late response on this.

I prefer splitting requirements in MUST / SHOULD and MAY sections.
draft-eddy-nemo-aero-reqs-02.txt use sections Required Characteristics and
Desirable Characteristics.

I propose a new desire:

===

Des# - Address generation for efficient signaling

The assigned addresses may be optimized for compression when using
Generalized MANET Packet/Message Format [packetbb]. Used addresses in the
MANET, with a common first set or last set of octets can be signaled more
efficient. 

The assigned prefixes may be optimized for aggregation. Aggregation on the
MANET router reduce advertized prefixes to a minimum. In the optimal case,
only one prefix is advertized per MANET Router.

===

I think this functionality is needed with these large IPv6 addresses, in
cases where bandwidth on MANET links is restricted or frame size is an
issue.

Teco.

> -----Oorspronkelijk bericht-----
> Van: Carlos Jesús Bernardos Cano [mailto:[email-masked]]
> Verzonden: woensdag 5 december 2007 23:56
> Aan: [email-masked]
> Onderwerp: [Autoconf] List of requirements in draft-ietf-autoconf-
> problem-statement
> 
> Hi all,
> 
> statement draft. This would help to understand what (and maybe how) has
> to be done to solve the problem of IP autoconf in MANETs.
> 
> 	Collecting this list is not easy, and therefore this mail is a
> humble attempt to get other people's opinion and start discussing what
> this list should contain. To start, I'd propose the following:
>