Re: [Autoconf] Autoconf addressing model

"Teco Boot" <teco@inf-net.nl> Fri, 27 February 2009 17:49 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 C09A728C36C for <autoconf@core3.amsl.com>; Fri, 27 Feb 2009 09:49:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.454
X-Spam-Level:
X-Spam-Status: No, score=-1.454 tagged_above=-999 required=5 tests=[AWL=-0.008, 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 FmdnT1UrtQrI for <autoconf@core3.amsl.com>; Fri, 27 Feb 2009 09:49:22 -0800 (PST)
Received: from hpsmtp-eml20.kpnxchange.com (hpsmtp-eml20.KPNXCHANGE.COM [213.75.38.85]) by core3.amsl.com (Postfix) with ESMTP id C3CA228C34D for <autoconf@ietf.org>; Fri, 27 Feb 2009 09:49:20 -0800 (PST)
Received: from cpsmtp-eml104.kpnxchange.com ([213.75.84.104]) by hpsmtp-eml20.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Feb 2009 18:49:42 +0100
Received: from M90Teco ([86.83.9.22]) by cpsmtp-eml104.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Feb 2009 18:49:42 +0100
From: Teco Boot <teco@inf-net.nl>
To: 'Alexandru Petrescu' <alexandru.petrescu@gmail.com>
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> <49A7E58C.2020303@gmail.com>
In-Reply-To: <49A7E58C.2020303@gmail.com>
Date: Fri, 27 Feb 2009 18:49:40 +0100
Message-ID: <007201c99903$c4182c80$4c488580$@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: AcmY3FfMqdkQoAIbSxCSbSzcti9/QgAIRi0Q
Content-Language: nl
x-cr-hashedpuzzle: A3hK A4bu D5BA GmCm Gn/g H6K9 JNRP K1+O LNCn OCi8 Obcj QO74 T2Sr U6jd U9kM WDdb; 2; YQBsAGUAeABhAG4AZAByAHUALgBwAGUAdAByAGUAcwBjAHUAQABnAG0AYQBpAGwALgBjAG8AbQA7AGEAdQB0AG8AYwBvAG4AZgBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {41593C1C-282D-4064-99A0-B3321CEBA27B}; dABlAGMAbwBAAGkAbgBmAC0AbgBlAHQALgBuAGwA; Fri, 27 Feb 2009 17:49:35 GMT; UgBFADoAIABBAHUAdABvAGMAbwBuAGYAIABhAGQAZAByAGUAcwBzAGkAbgBnACAAbQBvAGQAZQBsAA==
x-cr-puzzleid: {41593C1C-282D-4064-99A0-B3321CEBA27B}
X-OriginalArrivalTime: 27 Feb 2009 17:49:42.0231 (UTC) FILETIME=[C4CA3E70:01C99903]
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 17:49:23 -0000

Inline.

|-----Oorspronkelijk bericht-----
|Van: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]
|Verzonden: vrijdag 27 februari 2009 14:07
|Aan: Teco Boot
|CC: autoconf@ietf.org; cjbc@it.uc3m.es
|Onderwerp: Re: Autoconf addressing model
|
|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.

See other mail also, on Linux.
I think loopback addresses are often used for stable connections to routers,
where interfaces flap but due to redundancy there are alternative paths.
When addresses are used on physical interfaces, and the interface goes down,
connectivity might be broken. I think using router loopback interface
addresses for talking to other nodes is best current practice. It is a basic
principle in my network designs.

RFC3871:
   It is a common practice among operators to configure "loopback"
   pseudo-interfaces to use as the source and destination of
   management traffic.  These are preferred to physical interfaces
   because they provide a stable, routable address.  Services bound
   to the addresses of physical interface addresses might become
   unreachable if the associated hardware goes down, is removed, etc.

I think the same arguments are valid for non-management traffic in a MANET.


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

The MANET interface is not a loopback interface! It is the interface to a
radio, e.g. 802.11 NIC in IBSS mode (your wifi adhoc).



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

Typo, I meant:
So "host functionality" can be provided using the globally (or MANET local)
unique address assigned to a loopback interface, 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.
|
|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.

There is some misunderstanding her, the MANET interface is NOT a loopback
interface. It is an interface that enables communication to other MANET
nodes.



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

I think this model solves some problems.
  o The assigned address can be used over whatever interface.
    This fulfills a requirement of "ad hoc", something works without
planning.
  o Connectivity is not broken if a path swap occurs (the RFC3781 loopback
BCP)
  o It provides some scalability, as only a single address is needed, 
    even if multiple interfaces are used.
  o Applications are not confused by "host prefixes" to a link, 
    where other nodes are reachable. I tested this with linux and IPv4 with
/32. 
    Problems started with ARP processing, and I swapped to another
addressing 
    model immediately.



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

ULA prefix is FC00::/7. 8th but is L, set to 1 if locally assigned. So all
ULA would start with FD, the FC is for the future where a registration body
maintains the universal uniqueness.

0xFC + 0x01 = 0xFD.



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

In a MANET, there are some problems with standard OSPF. OSPF-MANET is
perfectly fine to use in a MANET.

DHCP (with relay) can be used for "pull", but there is a problem finding the
best relay agent. I think there should be a mechanism that informs nodes of
available facilities, e.g. shortest path to a DHCP server. Updating ND RA
with some info for finding a DHCP server looks a good idea to me, and I
updated my Border Router Discovery Protocol (BRDP) [Autoconf] proposal for
DHCP support already.

However, there is a chicken - egg problem. In a wired network, the DHCP
client - DHCP relay agent relation is stable. This is certainly not the case
in a MANET. Therefore, I think a DHCP client should start with building
reliable communication to a DHCP server, and the MANET routing protocols can
provide such. But the MANET routing protocol needs a prefix that corresponds
to this MANET node. For this reason, I think it makes sense to start with
generating a prefix without DHCP, and we could use a prefix "push model"
here.
Anyway, ND /SLAAC works with the "push model" already, so nothing new here.




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

This is under discussion, and the reason we have an [Autoconf] WG.
There are proposals that rely on a routing protocol, but the old charter
mentioned being independent of a routing protocol.
My BRDP used ND as a transport vehicle, and prefix information was carried
in "Border Router Information Option" which is a look-alike of the Prefix
Information Option. PIO is single-hop, BRIO is multi-hop. 



|> Multi-homing can easily be supported:
|
|maybe.

Just write some code and compile :-)

The problem is border router swapping. If session continuity is required, we
need something like MIP/NEMO, HIP, SHIM6 or NAT / NAT66 at the border. This
is not our focus, I think.


Teco.

 

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