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/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
- Re: [Autoconf] new charter Jari Arkko
- Re: [Autoconf] new charter Carlos Jesús Bernardos Cano
- Re: [Autoconf] new charter Paul Lambert
- [Autoconf] new charter Jari Arkko
- Re: [Autoconf] new charter Carlos Jesús Bernardos Cano
- Re: [Autoconf] new charter Ryuji Wakikawa
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter Teco Boot
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter Charles E. Perkins
- Re: [Autoconf] new charter Teco Boot
- Re: [Autoconf] new charter Carlos Jesús Bernardos Cano
- Re: [Autoconf] new charter HyungJin Lim
- Re: [Autoconf] new charter Carlos Jesús Bernardos Cano
- Re: [Autoconf] new charter HyungJin Lim
- [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter HyungJin Lim
- Re: [Autoconf] new charter Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter HyungJin Lim
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter HyungJin Lim
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter HyungJin Lim
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter Teco Boot
- Re: [Autoconf] practical addressing (was: new cha… Alexandru Petrescu
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] practical addressing (was: new cha… Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] new charter Stan Ratliff (sratliff)
- Re: [Autoconf] practical addressing Alexandru Petrescu
- Re: [Autoconf] new charter Alexandru Petrescu
- [Autoconf] radio neighbors in range Alexandru Petrescu
- Re: [Autoconf] new charter Stan Ratliff (sratliff)
- Re: [Autoconf] radio neighbors in range Stan Ratliff (sratliff)
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model HyungJin Lim
- Re: [Autoconf] new charter Rex Buddenberg
- Re: [Autoconf] practical addressing Teco Boot
- Re: [Autoconf] new charter Teco Boot
- Re: [Autoconf] radio neighbors in range Teco Boot
- Re: [Autoconf] new charter Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] radio neighbors in range Alexandru Petrescu
- Re: [Autoconf] new charter Stan Ratliff (sratliff)
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter Stan Ratliff (sratliff)
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] new charter Carlos Jesús Bernardos Cano
- Re: [Autoconf] Autoconf addressing model Carlos Jesús Bernardos Cano
- Re: [Autoconf] new charter Carlos Jesús Bernardos Cano
- Re: [Autoconf] Autoconf addressing model Carlos Jesús Bernardos Cano
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Carlos Jesús Bernardos Cano
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Carlos Jesús Bernardos Cano
- Re: [Autoconf] Autoconf addressing model Carlos Jesús Bernardos Cano
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model HyungJin Lim
- Re: [Autoconf] Autoconf addressing model HyungJin Lim
- Re: [Autoconf] new charter Dearlove, Christopher (UK)
- Re: [Autoconf] new charter Dearlove, Christopher (UK)
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter Joe Macker
- Re: [Autoconf] new charter Dearlove, Christopher (UK)
- Re: [Autoconf] radio neighbors in range Dearlove, Christopher (UK)
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Stan Ratliff (sratliff)
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Charles E. Perkins
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Charles E. Perkins
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Charles E. Perkins
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Charles E. Perkins
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Charles E. Perkins
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Stan Ratliff (sratliff)
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Stan Ratliff (sratliff)
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Charles E. Perkins
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Stan Ratliff (sratliff)
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Dearlove, Christopher (UK)
- Re: [Autoconf] Autoconf addressing model Dearlove, Christopher (UK)
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Dearlove, Christopher (UK)
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Joe Macker
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Joe Macker
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Dearlove, Christopher (UK)
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- [Autoconf] new charter Ryuji Wakikawa
- Re: [Autoconf] new charter Teco Boot