Re: [Autoconf] Autoconf addressing model

Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es> Mon, 02 March 2009 10:57 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 377FC3A6C10 for <autoconf@core3.amsl.com>; Mon, 2 Mar 2009 02:57:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.866
X-Spam-Level:
X-Spam-Status: No, score=-4.866 tagged_above=-999 required=5 tests=[AWL=-0.367, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_35=0.6, J_CHICKENPOX_45=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 VUo-B7xwDJW4 for <autoconf@core3.amsl.com>; Mon, 2 Mar 2009 02:57:14 -0800 (PST)
Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id F34613A682B for <autoconf@ietf.org>; Mon, 2 Mar 2009 02:57:13 -0800 (PST)
From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano <cjbc@it.uc3m.es>
To: Teco Boot <teco@inf-net.nl>
In-Reply-To: <001c01c99b16$f12b1c90$d38155b0$@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> <1235828619.6096.24.camel@localhost> <001c01c99b16$f12b1c90$d38155b0$@nl>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-BTPLL01Mcsen0rjWa2me"
Organization: Universidad Carlos III de Madrid
Date: Mon, 02 Mar 2009 11:57:37 +0100
Message-Id: <1235991457.5456.10.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-16494.006
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: Mon, 02 Mar 2009 10:57:16 -0000

Hi Teco,

El lun, 02-03-2009 a las 10:11 +0100, Teco Boot escribió:
> Hi Carlos,
> 
> |While I think this is also much in line with my thinking, I think it's
> |better to focus on the simplest cases before.
> 
> You placed this comment just below a figure with just one Internet access
> and three MANET Routers.
> I think this is the simple case.
> 
> Maybe you intended to say "focus on single-homing and leave multi-homing for
> future enhancements".

I meant something similar: "focus on single-homing first, to agree on
the basics of the addressing model arquitecture, and leave the rest for
a little bit later (not for future enhancements).

> If so, I do not agree. In my use case (tactical networks), multi-homing is
> an important requirement. I think it applies also for public safety /
> disaster relief networks. More important, if we leave multi-homing
> out-of-scope, we may easily make wrong decisions and block support for
> multi-homing or it may not be optimal.

I didn't mean out-of-the-scope. I just meant that there are very basic
things we haven't agreed yet. Better to solve that first..., IMHO.

> 
> It is not that difficult to support multi-homing. Fred Templin VET solution
> uses map&encap approach, as my NEMO4MANET idea (both IRTF RRG strategy A).
> BRDP based routing use "source address based routing" to the border router
> (IRTF RRG strategy B).  
> 
> I think the routing aspect of multi-homing is more a [MANET WG] topic, and
> [Autoconf WG] could ask [MANET WG] to work on solutions for it, based on a
> defined addressing model.

Fully agree.

Regards,

Carlos

> 
> Regards, Teco
> 
> 
> 
> |-----Oorspronkelijk bericht-----
> |Van: Carlos Jesús Bernardos Cano [mailto:cjbc@it.uc3m.es]
> |Verzonden: zaterdag 28 februari 2009 14:44
> |Aan: Teco Boot
> |CC: autoconf@ietf.org; 'Alexandru Petrescu'
> |Onderwerp: Re: Autoconf addressing model
> |
> |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/
> |++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 
-- 
 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/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++