Re: [Autoconf] Autoconf addressing model

"Teco Boot" <> Wed, 04 March 2009 22:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D6A8C28C12C for <>; Wed, 4 Mar 2009 14:57:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.683
X-Spam-Status: No, score=-1.683 tagged_above=-999 required=5 tests=[AWL=0.363, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id azGt6ZGVcIAh for <>; Wed, 4 Mar 2009 14:57:20 -0800 (PST)
Received: from (hpsmtp-eml20.KPNXCHANGE.COM []) by (Postfix) with ESMTP id 4A0883A68DA for <>; Wed, 4 Mar 2009 14:57:20 -0800 (PST)
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Mar 2009 23:57:47 +0100
Received: from M90Teco ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Mar 2009 23:57:46 +0100
From: "Teco Boot" <>
To: "'Charles E. Perkins'" <>
References: <> <> <> <000001c99845$1dc56190$595024b0$@nl> <> <1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl> <> <007201c99903$c4182c80$4c488580$@nl> <> <007b01c99911$907facf0$b17f06d0$@nl> <> <009501c99920$92154340$b63fc9c0$@nl> <> <003001c99b2c$a3fcf4a0$ebf6dde0$@nl> <> <000101c99c3c$3121a870$9364f950$@nl> <> <000c01c99c4f$d1ab1750$750145f0$@nl> <>
In-Reply-To: <>
Date: Wed, 4 Mar 2009 23:57:47 +0100
Message-ID: <000901c99d1c$a2d939c0$e88bad40$@nl>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcmcV5tlk+ckocSzSGSdnilki1aSFgAqPI/Q
Content-Language: nl
X-OriginalArrivalTime: 04 Mar 2009 22:57:47.0039 (UTC) FILETIME=[A2A8DAF0:01C99D1C]
Subject: Re: [Autoconf] Autoconf addressing model
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 04 Mar 2009 22:57:21 -0000

Hi Charlie,

Yes, I think the issues in this thread touch our basic problems. Here some

- on little wireless nodes that have a single interface:
The scope of MANETs is quite large, e.g. from aircraft carriers to smart
dust. For the most tiny devices, I am not sure we should deal with these.
There are other WGs working on PAN / sensor networks, maybe we could focus
on the somewhat larger stuff. And were a device type have a single
interface, new versions in this category may have more. 
Example: my 8 years old phone has 2 wireless interfaces, 1 wired and one IR.
Only one is IP enabled. Maybe I'll buy a new one some time, I think this one
would have almost all interfaces IP enabled and it would have more than 4

- on guideline for using router loopback interface for management:
I think this is a no-brainer for ISP / enterprise network engineers. Many
documents provide this advice, but I was looking for something that has not
a logo from a certain company. The problem here is, this company has a high
market share in this arena and also publish a lot of guidelines.
Here some refs, I hope this will convince you this is a well accepted

- on status of address / interface; socket api for this:
I discussed this with some colleagues, on what the requirements are. We came
to the conclusion that applications should be able to select an address that
belongs to a stable (ifup) interface, e.g. the loopback interface.
Applications should also be able to select an address that belongs to a
physical interface. Multicast applications can take benefits here. Having
different options could make defining default behavior somewhat complex.
Shim mechanisms (MIP/MIP6, Shim6, HIP) and socket interfaces based on names
hide addressing details from the applications. But such an approach may
affect applications for high availability, and in my environment this is

== back to the addressing model:
After some more thoughts, I come to the conclusion that MANET Routers should
advertize as little as possible, for reducing overhead. This is about
routing prefixes. The advertized prefix should "belong" to the indivisible
"mobile object", this means the summary prefix must not split and
sub-prefixes (subnets??) shall be interconnected within the "mobile object".
Single router "mobile object" has this behavior by nature.
Addresses assigned to interfaces come from the advertized prefix and may
have any prefix-length equal or longer than the advertized prefix-length.
Loopback interfaces should have /128 (or /32), as defined in RFCs for this.
Ethernet typically have /64, this is specified in std track RFC and it is a
MUST if SLAAC is used.
Still the question on using /128, /64 or other for globally unique
address-prefixes that are assigned to MANET interfaces of this "mobile
object". Maybe we do not need to restrict this. Mentioning the options and
the consequences is good enough, I think. 
Some consequences with /127 are described in RFC3627. This RFC also mentions
      Using two /128 addresses is also one, though often cumbersome,
      approach.  Naturally, not much would be lost if even a shorter
      prefix was used, e.g., /112 or /120.

The diagram in MANET-ARCH 5.1 could be adjusted to reflect my thoughts.
Below, it is more an example and less a "model".

                        |    Assigned Prefix   
                        |    ===================
   2001:db8:0::EUI-64/64| <=== 2001:db8:0::/64 =   
         FE80::EUI-64/64|    ===================             
         MANET Interface|                         Delegated Prefix
           +-----------------------+              /-------------\
           |                       | <<<<<<<<<<<<| 2001:db8::/60 |
           |       MANET           |              \-------------/
           |       Router          |
           |                       |    
           |  ...................  |    Assigned Prefix
           |  !Loopback         !  |    =====================
           |  !2001:db8:F::0/128!  | <=== 2001:db8:F::0/128 =   
           |  '''''''''''''''''''  |    =====================
         Ethernet Interface:          Assigned Prefix
            FE80::EUI-64/64:          ===================
      2001:db8:1::EUI-64/64:  <======== 2001:db8:1::/64 =      
                           :          ===================
                    :            :      
     FE80::EUI-64/64:            :FE80::EUI-64/64
 2001:db8:1::dhcp/64:            :2001:db8:1::EUI-64/64
     +--------------+-+       +--+--------------+
     | Host with DHCP | * * * | Host with SLAAC |
     +----------------+       +-----------------+

In a table format:

 Delegated summary prefix:      2001:db8::/60
   15 x /64: MANET Interface:	       2001:db8:0::/64
             Ethernet Interface:     2001:db8:1::/64
               " "     " "             " "     "
             up to:                  2001:db8:E::/64
   Block for longer prefix lengths:  2001:db8:F::/64      
     Loopback Interface #0:              2001:db8:F::0/128
     (others, e.g. P2P)                    " "     "

This model provides RFC4862 SLAAC service for nearby hosts, also useful for
MANET Router (or NEMO Router) bootstrapping. For getting a delegated prefix,
the a SLAAC address could be used for communication with a DHCP server,
using unicast (to be verified). Important: the /64 prefix that corresponds
with the SLAAC address-prefix MUST NOT be advertized in the MANET Routing
Protocol. Advertizing this as a host prefix is allowed, but getting an own
/60 or whatsoever summary is advised. The result here is a MANET Routing
Protocol requirement (not advertizing /64 SLAAC prefixes).
The MANET Router may act as DHCP Server (or relay agent) for its Delegated
Prefix(es). SLAAC is also supported.

On dec 2007 I posted similar thoughts
Are we making progress? I think: yes!


|-----Oorspronkelijk bericht-----
|Van: Charles E. Perkins []
|Verzonden: woensdag 4 maart 2009 0:27
|Aan: Teco Boot
|Onderwerp: Re: [Autoconf] Autoconf addressing model
|Hello Teco,
|You raise interesting questions, but I think mostly
|not definitive for the questions at hand.  I don't know
|if I have any good answers, but here are some comments.
|Teco Boot wrote:
|> As long as I designed and maintained network infrastructures, I worked
|> "/32 management addresses" on loopback interfaces. Still, I have
|> experiences with routers that select the outgoing interface address as
|> default source address. Shutting down an interface could have
|unintended bad
|> impact on your terminal session. Same for link flapping due to other
|I guess this is relevant for packet forwarders with more than one
|network interface.  For our little wireless nodes that have a single
|interface, I don't imagine we'd see that kind of interface aggravation.
|> For this reason, many routers on the Internet use the loopback
|interface for
|> "management". "Management" is the host application on routers. There
|> lots of design guidelines for this. My proposal is using the "Internet
|> lessons learned" in the MANET. Nothing wrong with this, agreed?
|I know only a small bit about this.  Do you have a favorite
|document that I could read to learn more?
|> With MobileIP, we are discussing a host (could be NEMO Router, but
|then it
|> acts as host on the visiting link). The MobileIP stack is interested
|in the
|> status of the visiting link, but does it propagate this to the
|> Or use the applications some kind of virtual interface (e.g. a
|> interface)? Or spoof ifup for interface to home link?
|Whether or not applications have access to link information is
|something not closely related to Mobile IP.  Whether or not
|the care-of address is available to applications is a surprisingly
|complicated question, which in my opinion opens the door to
|many interesting questions and indicates the insufficiency of
|today's typical application socket interface.
|I've had a lot of ideas about how to fix this, but never been
|able to initiate a project to supply a finished proposal.
|Charlie P.