Re: [Autoconf] Autoconf addressing model

Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es> Sat, 28 February 2009 13:43 UTC

Return-Path: <cjbc@it.uc3m.es>
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 9C7813A6A0C for <autoconf@core3.amsl.com>; Sat, 28 Feb 2009 05:43:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.699
X-Spam-Level:
X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
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 u4OG22b1iTsH for <autoconf@core3.amsl.com>; Sat, 28 Feb 2009 05:43:19 -0800 (PST)
Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id BF2EA3A68C0 for <autoconf@ietf.org>; Sat, 28 Feb 2009 05:43:18 -0800 (PST)
Received: from [192.168.1.209] (213.37.82.74.static.user.ono.com [213.37.82.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 43E37B4D459; Sat, 28 Feb 2009 14:43:40 +0100 (CET)
From: Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es>
To: Teco Boot <teco@inf-net.nl>
In-Reply-To: <002f01c998bf$8f112210$ad336630$@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>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-XFpBWjpEdx1XhkqiCOmc"
Organization: Universidad Carlos III de Madrid
Date: Sat, 28 Feb 2009 14:43:39 +0100
Message-Id: <1235828619.6096.24.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.3.1
X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16490.007
Cc: autoconf@ietf.org
Subject: Re: [Autoconf] Autoconf addressing model
X-BeenThere: autoconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: cjbc@it.uc3m.es
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: Sat, 28 Feb 2009 13:43:20 -0000

Hi Teco,

El vie, 27-02-2009 a las 10:41 +0100, Teco Boot escribió:
> All,
> 
> Here my opinion on the to be defined addressing model for MANETs / Autoconf.
> I opened a separate thread, as I think (and hope) there will be an intensive
> and productive discussion.
> 
> Some of us like an address model with /32 (IPv4) or /128 (IPv6)
> prefix-length addresses attached to an interface to a multi-access link.
> These addresses do not have an  Interface-ID. 
> 
> Such a model excludes usage of /64 "prefix swapping", which is IMHO an
> extremely important attribute of IPv6. And it is specified as mandatory in
> some standard track RFCs (e.g. RFC2464). 
> 
> 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 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).

Agree, this is also my understanding.

> 
> RFC4291   2.1.  Addressing Model:
>  All interfaces are required to have at least one Link-Local unicast
>  address (see Section 2.8 for additional required addresses).  A
>  single interface may also have multiple IPv6 addresses of any type
>  (unicast, anycast, and multicast) or scope.  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.  This is sometimes convenient for point-to-point
>  interfaces.
> 
> RFC2464   4.  Stateless Autoconfiguration:
>  An IPv6 address prefix used for stateless autoconfiguration [ACONF]
>  of an Ethernet interface must have a length of 64 bits.
> 
> 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 think an interface with /128 is stub, and
> thus protocols may assume that there is no other node on this link in the
> same subnet. Think of ARP and routing protocols. I verified this with some
> product, the outcome confirmed my assumption. I was able to adjust the
> configuration on one platform so that it worked (Linux), but still the
> indication is that the model has a high impact.
> 
> 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. 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.
> 
> 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.
> 
>     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.
>        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.
> 
I think I'm also agree here.
> 
> 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.
> 
> 
>                             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.
> 
> 
> Multi-homing can easily be supported:
> 
>      ---+-------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.
> 

While I think this is also much in linee with my thinking, I think it's
better to focus on the simplest cases before.

Thanks,

Carlos

> 
> 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/
> |++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 
-- 
 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/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++