Re: [Autoconf] Autoconf addressing model

"Teco Boot" <> Fri, 27 February 2009 21:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A2F2828C0E5 for <>; Fri, 27 Feb 2009 13:15:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.583
X-Spam-Status: No, score=-0.583 tagged_above=-999 required=5 tests=[AWL=-0.937, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_44=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_55=0.6, J_CHICKENPOX_56=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NJ9WWrj6CPXC for <>; Fri, 27 Feb 2009 13:15:32 -0800 (PST)
Received: from (hpsmtp-eml16.KPNXCHANGE.COM []) by (Postfix) with ESMTP id 95B8D3A6832 for <>; Fri, 27 Feb 2009 13:15:31 -0800 (PST)
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Feb 2009 22:15:53 +0100
Received: from M90Teco ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Feb 2009 22:15:53 +0100
From: "Teco Boot" <>
To: "'Alexandru Petrescu'" <>
References: <> <> <> <000001c99845$1dc56190$595024b0$@nl> <> <1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl> <> <007201c99903$c4182c80$4c488580$@nl> <> <007b01c99911$907facf0$b17f06d0$@nl> <>
In-Reply-To: <>
Date: Fri, 27 Feb 2009 22:15:52 +0100
Message-ID: <009501c99920$92154340$b63fc9c0$@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: AcmZFo/wAf6La0ghTXWDTKfrSBgx/AAACemA
Content-Language: nl
x-cr-puzzleid: {FFA28AB4-D17D-4731-88D6-362800CF3D5C}
X-OriginalArrivalTime: 27 Feb 2009 21:15:53.0156 (UTC) FILETIME=[926F9840:01C99920]
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: Fri, 27 Feb 2009 21:15:33 -0000

|-----Oorspronkelijk bericht-----
|Van: Alexandru Petrescu []
|Verzonden: vrijdag 27 februari 2009 21:04
|Aan: Teco Boot
|Onderwerp: [SPAM] Re: Autoconf addressing model
|Urgentie: Laag
|Teco Boot a écrit :
|> |Not all virtual interfaces are loopback.
|Again, do you think all virtual interfaces are 'loopback'?

Not at all.

And "loopback" on its own is meaningless.

|> Router folks use "loopback" for what is meant here. Virtual
|> interfaces have a much, much broader meaning. A tunnel interface or
|> VLAN / FR / ATM subinterface is a virtual interface but definitely
|> not what I intent to use. I prefer keep using the term loopback here.
|I strongly disagree using the term loopback interface, at least because
|it can be easily interpreted as the interface on which there's a
|'loopback address'.  

Check for example ISP BCP, rfc5375

I agree on that there can be confusion on loopback address (node local) and
loopback interface.

|And you don't seem to intend to use the loopback

No, I don't.

|The loopback interface is the only interface on which there's a loopback
|address assigned.

This is NOT a node requirement.

2.5.3.  The Loopback Address

   The unicast address 0:0:0:0:0:0:0:1 is called the loopback address.
   It may be used by a node to send an IPv6 packet to itself.  It must
   not be assigned to any physical interface.  It is treated as having
   Link-Local scope, and may be thought of as the Link-Local unicast
   address of a virtual interface (typically called the "loopback
   interface") to an imaginary link that goes nowhere.

Note the wording "may be".

The other way around is definitely false:
RFC3484 (default address selection):
      Implementations that wish to support the use
      of global source addresses assigned to a loopback interface should
      behave as if the loopback interface originates and forwards the

Assigning non-"loopback addresses" on the loopback interfaces is permitted.

|> |> RFC3871: It is a common practice among operators to configure |>
|> "loopback" pseudo-interfaces to use as the source and destination of
|> |> management traffic. | |Well that RFC is completely wrong please
|> someone correct it.  The |loopback address is ::1 and it can't be
|> used to communicate outside the |computer. Yes pseudo-interface (and
|> maybe 'virtual') but no loopback.
|> I think you mix up "host loopback" and "router loopback". These are
|> very, very different!
|I think there's no difference between host and router loopback.

On a host (strong end system model, RFC1122), traffic sent out the host MUST
have the source address of the outgoing interface. On a router, this is not
the case. Therefore assignment of addresses on loopback interfaces on
routers is different than on (strong ES) hosts.

|> |And yes the interface in the routing table for the entry address/128
|> is |'lo' which is yes the loopback interface but no, never will that
|> address |be in the src nor dst fields of any packet leaving the
|> computer (other |than encapsulated maybe).
|> I checked this on the Linux host. I assigned another address on the
|> lo interface. And the Linux host is reachable on this address, as
|> long as other nodes has a path to this /128 prefix.
|WEll yes, it is possible to manually assign any 128bit address routable
|or non-routable, on the loopback interface, as it is possible to assign
|any address on any interface be it virtual or physical.
|> Sorry, you are wrong.
|> Detailed info:
|> debian-fs1:/proc/sys/net/ipv6/neigh/eth0# ifconfig lo lo        Link
|> encap:Local Loopback inet addr:  Mask: inet6 addr:
|> 2001:db8:1::3333/128 Scope:Global inet6 addr: ::1/128 Scope:Host UP
|> LOOPBACK RUNNING  MTU:16436  Metric:1 RX packets:185 errors:0
|> dropped:0 overruns:0 frame:0 TX packets:185 errors:0 dropped:0
|> overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:13568 (13.2
|> KiB)  TX bytes:13568 (13.2 KiB)
|> Tested from IOS router: nbs3725#ping 2001:db8:1::3333 Type escape
|> sequence to abort. Sending 5, 100-byte ICMP Echos to
|> 2001:DB8:1::3333, timeout is 2 seconds: !!!!! Success rate is 100
|> percent (5/5), round-trip min/avg/max = 0/0/4 ms
|Well yes, that's ok, I don't see anything wrong with nbs3725 pinging
|debian-fs1's loopback interface's routable address.
|But the loopback interface is not used for its intended loopback
|meaning.  That loopback interface doesn't use the loopback address -
|it's a virtual interface on which the loopback address is assigned.

Yes, the "lo" interface is used for loopback address and for other purposes.

|> Debug info, showing that you are wrong, the IP address in interface
|> lo is reachable:
|Well yes, because having a non-loopback IPv6 address on the loopback
|> No, absolutely not. I provided the evidence that the loopback is
|> perfectly usable already.
|Why the loopback interface and not another virtual interface?  Why
|mixing loopback semantics with a routable address semantics?
|> |I thought the unplanned aspect could be treated by IPv6 stateless
|> |autoconf and IPv6-over-Ethernet link-local addresses.
|> Yes and no. I like SLAAC, but with SLAAC, thewre is an address per
|> interface. In this model, the node is reachable via the loopback
|> address via whatever interface.
|I think this creates more headaches than it solves.
|In a first step, do we agree that the node has typically more than one
|interface?  We didn't seem to.  If not, then why should we need to have
|the node reachable via whatever interface, since there's only one.

If there is only one (external) interface, there is no redundancy and the
advantages do not apply.

|If there are at least two interfaces, then why can't we use a different
|address on each of the interfaces?  What's wrong with that?  The fact
|that the node moves?  Well, you seemed to accept host-based /128 routes
|- in this case instead of 1 there'll be 2 host-based /128 routes.
|What's wrong with that again?

At least 2 advantages:
 o 1 address: lower overhead
 o no address swap needed when session swaps from one interface to the other
(and if interfaces go down!).

|> |> o Connectivity is not broken if a path swap occurs (the RFC3781 |>
|> loopback BCP) o It provides some scalability, as only a single |>
|> address is needed, even if multiple interfaces are used. o |>
|> Applications are not confused by "host prefixes" to a link, where |>
|> other nodes are reachable. I tested this with linux and IPv4 with |>
|> /32. | |Before deciding on the solution (address assigned to a
|> virtual |interface) I need to udnerstand how path swap occurs and
|> why.
|> Because movement. A MANET Router may have multiple interfaces, some
|> of them could be MANET, others wireless infrastructure mode and
|> others MANET.
|Sorry, I can't go along these lines.  Movement described just like that,
|without any boundary, no pattern, just movement...
|I think I will simply summarize the topologies we discussed and leave it
|I also agree it's difficult to describe movement on paper (maybe easier
|on ppt) but we could at least try.
|> |Sounds interesting.  But I think normal DHCP could run ok, provided
|> the |Relays know the address of the Server.  In a first practical
|> step would |be to manually configure the Server's address on each
|> Relays.
|> When many DHCP Relay Agenst are nearby, who to select? If multicast
|> is used, all of them will relay and this ends in a DHCP Relay storm
|> (collisions, loss, retry .....)
|That issue is simple.  Before the node can even have the choice to talk
|to a Relay, it will have to connect to the wifi "adhoc".  The moment it
|connected to it it will only have one choice: the Relay present on that
|"adhoc" essid.

Your assumption is single hop communication and no MANET routing protocol. I
am interested in the more complex topologies.

There is no "essid" in ad hoc mode. It is the "ssid" of the IBSS. Only ESS
has essid.
Let's try to be accurate.

|> |> However, there is a chicken - egg problem. In a wired network, the
|>  |> DHCP client - DHCP relay agent relation is stable. This is
|> certainly |> not the case in a MANET. | |Well it is the case in a
|> MANET made of 25meter IPv6 subnets.
|> Voice over IP over WLAN for 25meter? Just shout!!
|:-) :-) I agree.
|But the IP in VoIP over a 25m IPv6 subnet allows me to talk to another
|IP much further who wouldn't hear my shout otherwise.

Yes. a MANET topology could be a short-range / high data rate radio link to
another MANET Router, with low data rate / long range to a remote peer, and
another hop via short-range / high data radio link. In a mobile ad hoc
environment, nodes are free to move and the network should provide the best
connectivity to the users that is technical feasible. 

Not only the nodes may move, obstacles may also move (teapot, truck).

|> My requirements are over 25meter. 25km is no joke. Wifi is not usable
|> here.
|Well then.  I think the mechanisms are completely different.  A 25km
|radio link would use an addressing mechanism completely different.

Not sure on this. 
The to-be-defined [Autoconf] MANET addressing mechanism MUST support the
basics also!

|> |> Therefore, I think a DHCP client should start with building
|> reliable |> communication to a DHCP server, and the MANET routing
|> protocols can |> provide such. But the MANET routing protocol needs a
|> prefix that |> corresponds to this MANET node. For this reason, I
|> think it makes |> sense to start with generating a prefix without
|> DHCP, and we could |> use a prefix "push model" here. | |Well I think
|> this is indeed a very chickeneggy problem: are addresses in |place
|> before routing is, or vice-versa.  But what would we do in |practice?
|> Certainly we'd manually assign some addresses - let's see |these
|> cases first.
|> No. MANETs are often used in workgroups, whit lack of knowledge of
|> configuring something. The network must be plug&play / zero-config.
|> |>> Above, and in the following figures, I don't understand "--->,
|> |>> Prefix Information".  Is that RA?  Or OSPF?  Or routing protocol?
|>  |>> Or DHCP Prefix Delegation? |> |> This is under discussion, and
|> the reason we have an [Autoconf] WG. |> There are proposals that rely
|> on a routing protocol, but the old |> charter mentioned being
|> independent of a routing protocol. | |I think we should consider
|> first the practical cases.
|> No. I think we have a clear picture of why MANETs are being used. We
|> need an [Autoconf] solution. Let's take the next steps defining an
|> addressing model, write down the requirements and then look for
|> solutions.
|Sorry, it seems the Autoconf solution will come to live only if the
|first practical addressing solution can get agreement on.

The we may come up with some guidelines using current technologies.
We already know this is broken if we want to support the more complex

What about this scenario: here, the obstacle is moving:

(802.11 term: STA is station)

          +------------------------+   +------------------------+
          |                        |   |                        |
          |           ____STA-B    |   |           ____STA-B    |
          |       ___/      |      |   |       ___/             |
          |  STA-A          |      |   |  STA-A      OBSTACLE   |
          |      '--_       |      |   |      '--_              |
          |          '----STA-C    |   |          '----STA-C    |
          |  OBSTACLE              |   |                        |
          +------------------------+   +------------------------+
               1-1: No hindrance            1-2: B-C blocked

          +------------------------+   +------------------------+
          |                        |   |          O             |
          |           ____STA-B    |   |          B    STA-B    |
          |       ___/      |      |   |          S      |      |
          |  STA-A      OB  |      |   |  STA-A   T      |      |
          |            ST   |      |   |          A      |      |
          |           AC  STA-C    |   |          C    STA-C    |
          |         LE             |   |          LE            |
          +------------------------+   +------------------------+
               1-3: A-C blocked         1-4: A-B & A-C blocked

                MANET Scenarios with blocking obstacle

Compare with this one:

(802.11 term: AP is access point)

          +------------------------+   +------------------------+
          |                        |   |                        |
          |           ____STA-B    |   |           ____STA-B    |
          |       ___/             |   |       ___/             |
          |   AP-A                 |   |   AP-A      OBSTACLE   |
          |      '--_              |   |      '--_              |
          |          '----STA-C    |   |          '----STA-C    |
          |  OBSTACLE              |   |                        |
          +------------------------+   +------------------------+
               4-1: No hindrance            4-2: No hindrance

          +------------------------+   +------------------------+
          |                        |   |          O             |
          |           ____STA-B    |   |          B    STA-B    |
          |       ___/             |   |          S             |
          |   AP-A      OB         |   |   AP-A   T             |
          |            ST          |   |          A             |
          |           AC  STA-C    |   |          C    STA-C    |
          |         LE             |   |          LE            |
          +------------------------+   +------------------------+
           4-3: A-C & B-C blocked         4-4: All blocked

             802.11 BSS L2 topology with blocking obstacle

In these scenario's, the MANET model provides better connectivity. I won't
say more bandwidth, lower loss or other link quality metrics, but for high
availability the MANET model definitely wins.