[Autoconf] Autoconf addressing model
"Teco Boot" <teco@inf-net.nl> Fri, 27 February 2009 09:41 UTC
Return-Path: <teco@inf-net.nl>
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 A7D683A6AEB for <autoconf@core3.amsl.com>; Fri, 27 Feb 2009 01:41:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.49
X-Spam-Level:
X-Spam-Status: No, score=-1.49 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 w3wkMJVIqxVS for <autoconf@core3.amsl.com>; Fri, 27 Feb 2009 01:41:13 -0800 (PST)
Received: from hpsmtp-eml20.kpnxchange.com (hpsmtp-eml20.KPNXCHANGE.COM [213.75.38.85]) by core3.amsl.com (Postfix) with ESMTP id CDAFA3A6821 for <autoconf@ietf.org>; Fri, 27 Feb 2009 01:41:11 -0800 (PST)
Received: from cpsmtp-eml101.kpnxchange.com ([213.75.84.101]) by hpsmtp-eml20.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Feb 2009 10:41:27 +0100
Received: from M90Teco ([86.83.9.22]) by cpsmtp-eml101.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Feb 2009 10:41:26 +0100
From: Teco Boot <teco@inf-net.nl>
To: autoconf@ietf.org
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>
In-Reply-To: <1235680887.4585.5.camel@localhost>
Date: Fri, 27 Feb 2009 10:41:26 +0100
Message-ID: <002f01c998bf$8f112210$ad336630$@nl>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcmYUp3cco28S7uzQmigySHelCL5AgAWx55A
Content-Language: nl
X-OriginalArrivalTime: 27 Feb 2009 09:41:26.0855 (UTC) FILETIME=[8F629D70:01C998BF]
Subject: [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 09:41:14 -0000
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). 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. 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. 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/ |++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
- 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