Re: [Autoconf] Autoconf addressing model

Alexandru Petrescu <alexandru.petrescu@gmail.com> Wed, 04 March 2009 23:40 UTC

Return-Path: <alexandru.petrescu@gmail.com>
X-Original-To: autoconf@core3.amsl.com
Delivered-To: autoconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C68A528C19C for <autoconf@core3.amsl.com>; Wed, 4 Mar 2009 15:40:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, HELO_EQ_FR=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wsbUbbcpie1P for <autoconf@core3.amsl.com>; Wed, 4 Mar 2009 15:40:49 -0800 (PST)
Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) by core3.amsl.com (Postfix) with ESMTP id C8DC83A6B14 for <autoconf@ietf.org>; Wed, 4 Mar 2009 15:40:47 -0800 (PST)
Received: from smtp4-g21.free.fr (localhost [127.0.0.1]) by smtp4-g21.free.fr (Postfix) with ESMTP id 72DB74C8079; Thu, 5 Mar 2009 00:41:11 +0100 (CET)
Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp4-g21.free.fr (Postfix) with ESMTP id 2A9494C809B; Thu, 5 Mar 2009 00:41:09 +0100 (CET)
Message-ID: <49AF1191.1080307@gmail.com>
Date: Thu, 05 Mar 2009 00:41:05 +0100
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: Teco Boot <teco@inf-net.nl>
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> <002f01c998bf$8f112210$ad336630$@nl> <49A7E58C.2020303@gmail.com> <007201c99903$c4182c80$4c488580$@nl> <49A82E55.10208@gmail.com> <007b01c99911$907facf0$b17f06d0$@nl> <49A8471E.6090506@gmail.com> <009501c99920$92154340$b63fc9c0$@nl> <49A944FF.9000102@gmail.com> <003001c99b2c$a3fcf4a0$ebf6dde0$@nl> <49AD5184.6080300@gmail.com> <000101c99c3c$3121a870$9364f950$@nl> <49AD90D9.5040100@earthlink.net> <000c01c99c4f$d1ab1750$750145f0$@nl> <49ADBCD8.9040301@earthlink.net> <000901c99d1c$a2d939c0$e88bad40$@nl>
In-Reply-To: <000901c99d1c$a2d939c0$e88bad40$@nl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Antivirus: avast! (VPS 090303-2, 04/03/2009), Outbound message
X-Antivirus-Status: Clean
Cc: autoconf@ietf.org
Subject: Re: [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: Wed, 04 Mar 2009 23:40:50 -0000

Teco Boot a écrit :
> Hi Charlie,
> 
> Yes, I think the issues in this thread touch our basic problems. Here some
> follow-up:
> 
> - 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
> interfaces.
> 
> 
> - 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
> practice.
> http://www.apnic.net/training/download/irm-1/irm1-7-addrplan.pdf
> http://ws.edu.isoc.org/data/2004/604610702427ef01785c49/loopback-6up.pdf
> ftp://ftp.hp.com/pub/networking/software/ProCurve-SR-BGP-Config-Guide-08-05.
> pdf
> http://www.juniper.net/techpubs/software/junos-es/junos-es92/junos-es-swconf
> ig-interfaces-and-routing/special-interfaces.html#loopback-interface-section
> http://www.apnic.net/meetings/26/program/apops/transcript.html#yoshinobu-arc
> hitecture
> 
> 
> - 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
> important.
> 
> 
> 
> == 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
> /128: 
>       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 the above figure: I agree with many points that I won't mention.

But I don't agree using the loopback interface for this.

And I don't understand why there's a "MANET Interface" and a "Ethernet 
interface".  I really don't see the need for any virtual interface.

Let me give my take on virtual interfaces...

Some routing protocols use virtual interfaces because at least the 
following problem: it has been shown in practice that when a e.g. wifi 
interface gets disassociated from the AP the interface may go down, and 
in some implementations it may SIGKILL (or worse) the app using that 
socket.  And if the app is the routing protocol the net effect is very 
bad: routing protocol crashes.  This was very bad.  It also meant that 
whenever I would disconnect the Ethernet cable (on some implementations, 
again), the routing protocol implementation would crash; or when my 
bluetooth interface gets down.  Or similar 'mobility' event which would 
never previously appear in the fixed-router-Internet, because people 
wouldn't consciously disconnect Ethernet cables whereas phone lines 
would still get jammed (a modem line being overloaded wouldn't SIGKILL 
the app running on that kernel, because modem separated from computer by 
rs-232 and rs-232 no interface structure).

To cope with that, put up a virtual interface and add routes between 
that virtual interface and the wifi interface.  And run the routing 
protocol on top of _that_ virtual interface instead of the wifi 
interface.  Since it is virtual it never gets down (unless maybe a tree 
falls), the routing protocol implementation will crash less.  It was 
thus shown that the routing protocol running on a virtual interface is 
advantageous, dealing better with mobility events - at least it could be 
deterministic!

However, there exist also implementations of wifi drivers which won't 
put the interface down when the interface gets dissasociated.  Also 
there exist kernels which won't SIGKILL the app, and there exist also 
protocols implementations who'd deal with that SIGKILL more gently if it 
popped up.

Also there exist implementations of routing protocols who would not deal 
at all with any particular interface structure (be that real or virtual) 
- they're independent on the kernel's interface structures being up or 
down or whatever state, but use directly the card's buffers to send or 
receive data.  I agree though these implementations are less widespread.

Overall, I think a safe bet is somewhere in the middle: to not talk 
about virtual interfaces (neither loopback, nor others) but only about 
real interfaces and of specific types.  And to consider the virtual 
interfaces to be a detail of _some_ implementations.

Alex

> 
> 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
> (http://www.ietf.org/mail-archive/web/autoconf/current/msg00901.html).
> Are we making progress? I think: yes!
> 
> 
> Teco.
> 
> 
> 
> 
> 
> |-----Oorspronkelijk bericht-----
> |Van: Charles E. Perkins [mailto:charles.perkins@earthlink.net]
> |Verzonden: woensdag 4 maart 2009 0:27
> |Aan: Teco Boot
> |CC: autoconf@ietf.org
> |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
> |with
> |> "/32 management addresses" on loopback interfaces. Still, I have
> |annoying
> |> 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
> |causes.
> |>
> |
> |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
> |are
> |> 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
> |applications?
> |> Or use the applications some kind of virtual interface (e.g. a
> |loopback
> |> 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.
> |
> |
> |Regards,
> |Charlie P.
> 
> _______________________________________________
> Autoconf mailing list
> Autoconf@ietf.org
> https://www.ietf.org/mailman/listinfo/autoconf
>