[Autoconf] Autoconf addressing model

"Teco Boot" <teco@inf-net.nl> Fri, 27 February 2009 09:41 UTC

Return-Path: <teco@inf-net.nl>
X-Original-To: autoconf@core3.amsl.com
Delivered-To: autoconf@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id A7D683A6AEB for <autoconf@core3.amsl.com>; Fri, 27 Feb 2009 01:41:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.49
X-Spam-Status: No, score=-1.49 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_21=0.6]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id w3wkMJVIqxVS for <autoconf@core3.amsl.com>; Fri, 27 Feb 2009 01:41:13 -0800 (PST)
Received: from hpsmtp-eml20.kpnxchange.com (hpsmtp-eml20.KPNXCHANGE.COM []) by core3.amsl.com (Postfix) with ESMTP id CDAFA3A6821 for <autoconf@ietf.org>; Fri, 27 Feb 2009 01:41:11 -0800 (PST)
Received: from cpsmtp-eml101.kpnxchange.com ([]) by hpsmtp-eml20.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Feb 2009 10:41:27 +0100
Received: from M90Teco ([]) by cpsmtp-eml101.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Feb 2009 10:41:26 +0100
From: "Teco Boot" <teco@inf-net.nl>
To: <autoconf@ietf.org>
References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost>
In-Reply-To: <1235680887.4585.5.camel@localhost>
Date: Fri, 27 Feb 2009 10:41:26 +0100
Message-ID: <002f01c998bf$8f112210$ad336630$@nl>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcmYUp3cco28S7uzQmigySHelCL5AgAWx55A
Content-Language: nl
X-OriginalArrivalTime: 27 Feb 2009 09:41:26.0855 (UTC) FILETIME=[8F629D70:01C998BF]
Subject: [Autoconf] Autoconf addressing model
X-BeenThere: autoconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/autoconf>
List-Post: <mailto:autoconf@ietf.org>
List-Help: <mailto:autoconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Feb 2009 09:41:14 -0000


Here my opinion on the to be defined addressing model for MANETs / Autoconf.
I opened a separate thread, as I think (and hope) there will be an intensive
and productive discussion.

Some of us like an address model with /32 (IPv4) or /128 (IPv6)
prefix-length addresses attached to an interface to a multi-access link.
These addresses do not have an  Interface-ID. 

Such a model excludes usage of /64 "prefix swapping", which is IMHO an
extremely important attribute of IPv6. And it is specified as mandatory in
some standard track RFCs (e.g. RFC2464). 

We could discuss and analyze the effect of adopting the /128 (or /32) prefix
lengths for MANET interfaces, but I prefer taking this option as last
resort. I think there is a much more obvious option, using the RFC2464 model
for the MANET interface and /128 (or /32) for loopback interfaces. Both
would use high probability globally unique Interface IDs like EUI-64
(Extended Unique Identifier).

RFC4291   2.1.  Addressing Model:
 All interfaces are required to have at least one Link-Local unicast
 address (see Section 2.8 for additional required addresses).  A
 single interface may also have multiple IPv6 addresses of any type
 (unicast, anycast, and multicast) or scope.  Unicast addresses with a
 scope greater than link-scope are not needed for interfaces that are
 not used as the origin or destination of any IPv6 packets to or from
 non-neighbors.  This is sometimes convenient for point-to-point

RFC2464   4.  Stateless Autoconfiguration:
 An IPv6 address prefix used for stateless autoconfiguration [ACONF]
 of an Ethernet interface must have a length of 64 bits.

It is not only because the RFC texts that I dislike the /128 in MANET
interfaces, it is also backward compatibility with current IP stacks (and
probably many applications). I think an interface with /128 is stub, and
thus protocols may assume that there is no other node on this link in the
same subnet. Think of ARP and routing protocols. I verified this with some
product, the outcome confirmed my assumption. I was able to adjust the
configuration on one platform so that it worked (Linux), but still the
indication is that the model has a high impact.

I think using /128 for loopback interfaces fits the requirements for the
addressing model. If a loopback interface is used, MANET interfaces do not
require a globally unique address. RFC4291 once more (out of section, also
cited above):
 Unicast addresses with a
 scope greater than link-scope are not needed for interfaces that are
 not used as the origin or destination of any IPv6 packets to or from
So "host functionality" can be provided using the globally (or MANET local)
unique address assigned to a loopback address, or another non-MANET

This results in the following addressing model, where all nodes are routers:

    +-------+ wifi "adhoc1" +-------+ wifi "adhoc2" +-------+
    +---L---+ LL1      LL21 +---L---+ LL22      LL3 +---L---+
        |M1                     |M2                     |M3

    "adhoc1" and "adhoc2": 802.11 SSIDs in "IBSS" mode.
    Each IBSS is an IPv6 subnet.

    L: Loopback interface.

    >, <: MANET interface.

    LL1, LL21, LL22, LL3: IPv6 link-local addresses.
       Self-formed according to rfc2464.

    M1, M2, M3: IPv6 MANET local addresses, for example
       FD01:db8::1/128, FD01:db8::2/128 and FD01:db8::3/128.
       Manually assigned, or pre-configured (e.g. with SNMP)
       or formed according to a to be defined [Autoconf for MANETs]
       protocol, with a to-be-defined prefix (e.g. ULA, RFC4193).

Although all nodes are marked as router, this does not imply all nodes
forward packets. All nodes run a MANET routing protocol for learning the
MANET topology.

In case one of the routers is connected to the Internet or private network,
this router can advertize a prefix in the MANET, and this information is
distributed in the MANET with an [Autoconf for MANETs] protocol.

                        | Access Router |
                                | | Prefix information
                                | V
    +-------+ wifi "adhoc1" +---+---+ wifi "adhoc2" +-------+
    +---L---+ LL1      LL21 +---L---+ LL22      LL3 +---L---+
        |M1                     |M2                     |M3
        |G1                     |G2                     |G3
                   <-------           ------->
         Prefix information           Prefix information 

    G1, G2, G3: IPv6 globally unique addresses, for example
       2001:db8:G:1/128, 2001:db8:G:2/128 and 2001:db8:G:3/128.
       Formed according to a to be defined [Autoconf for MANETs]
       protocol, with the prefix provided by (via) the Access Router.

Multi-homing can easily be supported:

        |                       |
        |                       |
+-------+-------+       +-------+-------+
|Access Router H|       |Access Router G|
+-------+-------+       +-------+-------+
        |                       |
        ||Prefix information H  | |Prefix information G
        |V                      | V
        |                       |
    +---+---+ wifi "adhoc1" +---+---+ wifi "adhoc2" +-------+
    +---L---+ LL1      LL21 +---L---+ LL22      LL3 +---L---+
        |M1                     |M2                     |M3
        |G1                     |G2                     |G3
        |H1                     |H2                     |H3
                   <-------           ------->
       Prefix information G         Prefix information G, H
              Prefix information H

    H1, H2, H3: IPv6 globally unique addresses, for example
       2001:db8:H:1/128, 2001:db8:H:2/128 and 2001:db8:H:3/128.
       Formed according to a to be defined [Autoconf for MANETs]
       protocol, with the prefix provided by (via) Access Router H.

Note that the impact of the number of interfaces is minimal, the address
configuration of Router2 is very similar to Router1 and Router3. Also, the
status of the MANET interface has no impact on communication in case of
multi-homing and redundant paths. (OK, we might need MIP6 / HIP / SHIM6 or
application layer address swapping mechanisms).

It doesn't matter how many ad hoc segments there are. In the following
scenario, the link to Access router G disappeared, Router 3 disappeared and
a Router4 joined IBSS "adhoc1".

|Access Router H|       
        ||Prefix information H  
        |V                     wifi "adhoc1"
        |                   <---------------------------v--------> 
 <------|--v---------------------->                     | 
        |  |                    |                       |
    +---+--'+               +---'---+               +---'---+
    +---L---+ LL1      LL21 +---L---+ LL22      LL4 +---L---+
        |M1                     |M2                     |M4
        |H1                     |H2                     |H4

              --------->               --------->
              Prefix information H     Prefix information H

Now, Router2 acts as a relay for Router4, so Router4 can reach Router1 and
the Internet. Router1 acts as Border Router for all nodes in the MANET.

I have some thoughts on IPv4 supports. Of course IPv4 misses lots of
flexibility that is used in above model. But there are ways to support it,
e.g. IPv4 link local (RFC3927) accompanied by some extended form of
duplicate address detection (passive checking routing tables). For globally
unique address assignment I think of DHCP-IPv4 over an IPv6 path, provided
as described above. (e.g. Router4 gets its /32 address for its loopback
interface from/via Access Router H, using M4 or H4 address and the IPv6
MANET protocol.

Any comments?

|-----Oorspronkelijk bericht-----
|Van: Carlos Jesús Bernardos Cano [mailto:cjbc@it.uc3m.es]
|Verzonden: donderdag 26 februari 2009 21:41
|Aan: Alexandru Petrescu
|CC: Teco Boot; autoconf@ietf.org
|Onderwerp: Re: [Autoconf] new charter
|Hi Alex:
|	One question below.
|El jue, 26-02-2009 a las 20:44 +0100, Alexandru Petrescu escribió:
|> Sorry, I made an error indeed putting same prefix.  How about this
|> updated picture with the prefixes being distinct:
|>          -----  wifi "adhoc1"  ------  wifi "adhoc2"  -----
|>         |Host1|---------------|Router|---------------|Host2|
|>          ----- LL1         LL2 ------ LL3        LL4  -----
|>                G1                                G4
|>         "adhoc1" and "adhoc2": 802.11 ESSIDs in "ad-hoc" mode.
|>                                Each is an IPv6 subnet.
|>         LL1...4: IPv6 link-local addresses.
|>                  Self-formed according to rfc2464.
|>         G1, G4:  IPv6 global addresses, for example
|>                  2001:db8:1::1/64 and
|>                  2001:db8:2::4/64
|>                  Manually assigned, or pre-configured with SNMP
|>                  or formed according to stateless autoconf rfc4862;
|>                  the prefixes are advertised by Router in RAs.
|Does this model only apply to Host-Router-Host scenarios? I mean, does
|this model apply for Router-Router-Router scenarios? I fully agree the
|model fits the first scenario, but I don't for the second, since
|routers' mobility within the ad-hoc network would force them to change
|prefixes often, I guess. For those scenarios it might be better to think
|of addressing models in which MANET routers are configured with /128
|(or /32 for IPv4) addresses, so they don't need to change their
|addresses as a result of link changes.
|Kind Regards,
| Carlos Jesús Bernardos Cano     http://www.netcoms.net
| GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
|  WEEDEV 2009: 2nd Workshop on Experimental Evaluation and
|        Deployment Experiences on Vehicular networks
|                  http://www.weedev.org/