Re: [Autoconf] Autoconf addressing model

Alexandru Petrescu <alexandru.petrescu@gmail.com> Fri, 27 February 2009 13:07 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 83AA13A6932 for <autoconf@core3.amsl.com>; Fri, 27 Feb 2009 05:07:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.884
X-Spam-Level:
X-Spam-Status: No, score=-1.884 tagged_above=-999 required=5 tests=[AWL=-0.235, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_21=0.6]
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 1U0bP7T33tPP for <autoconf@core3.amsl.com>; Fri, 27 Feb 2009 05:07:04 -0800 (PST)
Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id C6E913A6821 for <autoconf@ietf.org>; Fri, 27 Feb 2009 05:07:03 -0800 (PST)
Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n1RD7P3i017632; Fri, 27 Feb 2009 14:07:25 +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 n1RD7OKu023761; Fri, 27 Feb 2009 14:07:25 +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 n1RD7OKC016064; Fri, 27 Feb 2009 14:07:24 +0100
Message-ID: <49A7E58C.2020303@gmail.com>
Date: Fri, 27 Feb 2009 14:07:24 +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>
In-Reply-To: <002f01c998bf$8f112210$ad336630$@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 13:07:05 -0000

Whoa, that's text Teco :-)  Let me see where can I practically agree 
with you:

Teco Boot a écrit :
[...]
> 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 fully agree with you.  I find /128 prefix lengths for subnets to be a 
departure from the typical less-than-64 prefix lengths for subnets.  It 
may even break networks.

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

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

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

> This results in the following addressing model, where all nodes are routers:
> 
>     +-------+ wifi "adhoc1" +-------+ wifi "adhoc2" +-------+
>     |Router1|>-------------<|Router2|>-------------<|Router3|
>     +---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.

The MANET interface is a loopback interface?  I disagree.  The loopback 
interface is needed for local inter-process communication, I don't want 
that to go on to the network.

But, most importantly, why is there a need to add other special 
interfaces to the example pictured above?

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

For my clarification, what's fd01? (2001:db8:: is a prefix for 
documentation rfc3849, ULA is fc00 rfc4193).

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

> 
>                             Internet
>                                 |
>                                 |
>                         +-------+-------+
>                         | Access Router |
>                         +-------+-------+
>                                 |
>                                 | | Prefix information
>                                 | V
>                                 |
>     +-------+ wifi "adhoc1" +---+---+ wifi "adhoc2" +-------+
>     |Router1|>-------------<|Router2|>-------------<|Router3|
>     +---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.

Above, and in the following figures, I don't understand "--->, Prefix 
Information".  Is that RA?  Or OSPF?  Or routing protocol?   Or DHCP 
Prefix Delegation?


> Multi-homing can easily be supported:

maybe.

Alex

> 
>      ---+-------Internet--------+---
>         |                       |
>         |                       |
> +-------+-------+       +-------+-------+
> |Access Router H|       |Access Router G|
> +-------+-------+       +-------+-------+
>         |                       |
>         ||Prefix information H  | |Prefix information G
>         |V                      | V
>         |                       |
>     +---+---+ wifi "adhoc1" +---+---+ wifi "adhoc2" +-------+
>     |Router1|>-------------<|Router2|>-------------<|Router3|
>     +---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".
> 
> 
> 
>      ---+-------Internet------
>         |                     
>         |           
> +-------+-------+      
> |Access Router H|       
> +-------+-------+        
>         |                       
>         ||Prefix information H  
>         |V                     wifi "adhoc1"
>         |                   <---------------------------v--------> 
>  <------|--v---------------------->                     | 
>         |<-|--------------------v-----------------------|--->
>         |  |                    |                       |
>     +---+--'+               +---'---+               +---'---+
>     |Router1|>-------------<|Router2|>-------------<|Router4|
>     +---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?
> Teco.
> 
> 
> 
> |-----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
> |
> |--
> | 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/
> |++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 
>