Re: [Autoconf] Autoconf addressing model

Alexandru Petrescu <alexandru.petrescu@gmail.com> Fri, 27 February 2009 18:17 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 BB0BE28C1BF for <autoconf@core3.amsl.com>; Fri, 27 Feb 2009 10:17:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.189
X-Spam-Level:
X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=0.060, 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 KQt2g1fphgrl for <autoconf@core3.amsl.com>; Fri, 27 Feb 2009 10:17:36 -0800 (PST)
Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 49FB93A683E for <autoconf@ietf.org>; Fri, 27 Feb 2009 10:17:36 -0800 (PST)
Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n1RIHwW9032414; Fri, 27 Feb 2009 19:17:58 +0100
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n1RIHvJa001083; Fri, 27 Feb 2009 19:17:58 +0100 (envelope-from alexandru.petrescu@gmail.com)
Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n1RIHvJ4032531; Fri, 27 Feb 2009 19:17:57 +0100
Message-ID: <49A82E55.10208@gmail.com>
Date: Fri, 27 Feb 2009 19:17:57 +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>
In-Reply-To: <007201c99903$c4182c80$4c488580$@nl>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
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: Fri, 27 Feb 2009 18:17:37 -0000

Teco Boot a écrit :
[...]
>>> 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).
>> 
>> I don't agree going that way.  I think loopback addresses are for
>> self addressing not for talking to other nodes.
> 
> See other mail also, on Linux. I think loopback addresses are often
> used for stable connections to routers, where interfaces flap but due
> to redundancy there are alternative paths.

I think you mean a virtual interface actually, not necessarily the
loopback interface (and yes, lo is a 'virtual' interface).

Not all virtual interfaces are loopback.

> 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.

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).


>> [rfc4291 and 2464 citations]
>>> 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 agree.
>> 
>>> 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.
>> 
>> I'm not sure I could agree with the MANET interface being the
>> loopback interface.  It sounds as a significant departure.
> 
> The MANET interface is not a loopback interface! It is the interface
> to a radio, e.g. 802.11 NIC in IBSS mode (your wifi adhoc).

I agree with this.  But in the immediately above text you're saying
"using /128 for loopback interfaces fits" - I think you meant 'virtual'
interface, not 'loopback' interface, right?

>>> 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 non-neighbors. So "host functionality"
>>> can be provided using the globally (or MANET local) unique
>>> address assigned to a loopback address, or another non-MANET 
>>> interface.
>> 
>> An address assigned to an address?  I think it risks many 
>> misunderstandings.
> 
> Typo, I meant: So "host functionality" can be provided using the
> globally (or MANET local) unique address assigned to a loopback
> interface, or another non-MANET interface.

Ok.


> I think this model solves some problems. o The assigned address can
> be used over whatever interface. This fulfills a requirement of "ad
> hoc", something works without planning.

I thought the unplanned aspect could be treated by IPv6 stateless
autoconf and IPv6-over-Ethernet link-local addresses.

> 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.

> Problems started with ARP processing, and I swapped to another 
> addressing model immediately.

>> For my clarification, what's fd01? (2001:db8:: is a prefix for 
>> documentation rfc3849, ULA is fc00 rfc4193).
> 
> ULA prefix is FC00::/7. 8th but is L, set to 1 if locally assigned.
> So all ULA would start with FD, the FC is for the future where a
> registration body maintains the universal uniqueness.
> 
> 0xFC + 0x01 = 0xFD.

Ah!  So a correct ULA address would be fd01::1/128?  In this sense, when
drawing pictures I have a choice between fd01::1/128 ULA and
2001:db8::1/128 global address, it's ambiguous.

>>> 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.
>> 
>> Why shouldn't it be distributed with DHCP and with OSPF, for
>> example.
> 
> In a MANET, there are some problems with standard OSPF. OSPF-MANET is
>  perfectly fine to use in a MANET.

Ok.

> DHCP (with relay) can be used for "pull", but there is a problem
> finding the best relay agent. I think there should be a mechanism
> that informs nodes of available facilities, e.g. shortest path to a
> DHCP server. Updating ND RA with some info for finding a DHCP server
> looks a good idea to me, and I updated my Border Router Discovery
> Protocol (BRDP) [Autoconf] proposal for DHCP support already.

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.

> 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.

> 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.

>> 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.

Alex