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 688613A6A18 for <autoconf@core3.amsl.com>; Sat, 28 Feb 2009 05:43:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.966
X-Spam-Level:
X-Spam-Status: No, score=-3.966 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_55=0.6, J_CHICKENPOX_56=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 dG-A9FNdGMra for <autoconf@core3.amsl.com>; Sat, 28 Feb 2009 05:43:27 -0800 (PST)
Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 632413A69E0 for <autoconf@ietf.org>; Sat, 28 Feb 2009 05:43:27 -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 smtp02.uc3m.es (Postfix) with ESMTP id 942ED65A1F3; Sat, 28 Feb 2009 14:43:48 +0100 (CET)
From: Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es>
To: Teco Boot <teco@inf-net.nl>
In-Reply-To: <007b01c99911$907facf0$b17f06d0$@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> <49A7E58C.2020303@gmail.com> <007201c99903$c4182c80$4c488580$@nl> <49A82E55.10208@gmail.com> <007b01c99911$907facf0$b17f06d0$@nl>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-zdLy5X1gE8l+qVyIL3so"
Organization: Universidad Carlos III de Madrid
Date: Sat, 28 Feb 2009 14:43:44 +0100
Message-Id: <1235828624.6096.26.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:29 -0000

Hi,

El vie, 27-02-2009 a las 20:28 +0100, Teco Boot escribió:
> Inline.
> 
> |-----Oorspronkelijk bericht-----
> |Van: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]
> |Verzonden: vrijdag 27 februari 2009 19:18
> |Aan: Teco Boot
> |CC: autoconf@ietf.org
> |Onderwerp: Re: Autoconf addressing model
> |
> |Teco Boot a écrit :
> |[...]
> |>>> 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.
> |
> |I think you mean a virtual interface actually, not necessarily the
> |loopback interface (and yes, lo is a 'virtual' interface).
> |
> |Not all virtual interfaces are loopback.
> 
> Router folks use "loopback" for what is meant here. Virtual interfaces have
> a much, much broader meaning. A tunnel interface or VLAN / FR / ATM
> subinterface is a virtual interface but definitely not what I intent to use.
> I prefer keep using the term loopback here.

Agree, I prefer that term as well.

> 
> |
> |> RFC3871: It is a common practice among operators to configure
> |> "loopback" pseudo-interfaces to use as the source and destination of
> |> management traffic.
> |
> |Well that RFC is completely wrong please someone correct it.  The
> |loopback address is ::1 and it can't be used to communicate outside the
> |computer. Yes pseudo-interface (and maybe 'virtual') but no loopback.
> 
> I think you mix up "host loopback" and "router loopback". These are very,
> very different!

Agree, don't know if the semantic difference is documented somewhere,
but I share the same understanding.

Regards,

Carlos

> 
> 
> 
> |And yes the interface in the routing table for the entry address/128 is
> |'lo' which is yes the loopback interface but no, never will that address
> |be in the src nor dst fields of any packet leaving the computer (other
> |than encapsulated maybe).
> 
> I checked this on the Linux host. I assigned another address on the lo
> interface. And the Linux host is reachable on this address, as long as other
> nodes has a path to this /128 prefix.
> 
> Sorry, you are wrong.
> 
> Detailed info:
> 
> debian-fs1:/proc/sys/net/ipv6/neigh/eth0# ifconfig lo  
> lo        Link encap:Local Loopback  
>           inet addr:127.0.0.1  Mask:255.0.0.0
>           inet6 addr: 2001:db8:1::3333/128 Scope:Global
>           inet6 addr: ::1/128 Scope:Host
>           UP LOOPBACK RUNNING  MTU:16436  Metric:1
>           RX packets:185 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:185 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:0 
>           RX bytes:13568 (13.2 KiB)  TX bytes:13568 (13.2 KiB)
> 
> Tested from IOS router:
> nbs3725#ping 2001:db8:1::3333
> Type escape sequence to abort.
> Sending 5, 100-byte ICMP Echos to 2001:DB8:1::3333, timeout is 2 seconds:
> !!!!!
> Success rate is 100 percent (5/5), round-trip min/avg/max = 0/0/4 ms
> nbs3725#
> 
> I added reachability manually:
> nbs3725#show ipv6 route
> IPv6 Routing Table - 4 entries
> Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
>        U - Per-user Static route, M - MIPv6
>        I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
>        O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
>        ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
>        D - EIGRP, EX - EIGRP external
> C   2001:DB8:1::/64 [0/0]
>      via ::, FastEthernet0/0.22
> L   2001:DB8:1::1/128 [0/0]
>      via ::, FastEthernet0/0.22
> S   2001:DB8:1::3333/128 [1/0]
>      via FE80::20C:29FF:FEE3:BDF5, FastEthernet0/0.22
> L   FF00::/8 [0/0]
>      via ::, Null0
> nbs3725#
> 
> Debug info, showing that you are wrong, the IP address in interface lo is
> reachable:
> Feb 27 19:08:08.018: IPv6: SAS picked source 2001:DB8:1::1 for
> 2001:DB8:1::3333 (FastEthernet0/0.22)
> Feb 27 19:08:08.018: IPv6: nexthop FE80::20C:29FF:FEE3:BDF5,
> Feb 27 19:08:08.018: IPV6: source 2001:DB8:1::1 (local)
> Feb 27 19:08:08.018:       dest 2001:DB8:1::3333 (FastEthernet0/0.22)
> Feb 27 19:08:08.018:       traffic class 0, flow 0x0, len 100+0, prot 58,
> hops 64, originating
> Feb 27 19:08:08.018: IPv6: Sending on FastEthernet0/0.22
> 
> Feb 27 19:08:08.022: IPV6: source 2001:DB8:1::3333 (FastEthernet0/0.22)
> Feb 27 19:08:08.022:       dest 2001:DB8:1::1
> Feb 27 19:08:08.022:       traffic class 0, flow 0x0, len 100+14, prot 58,
> hops 64, forward to ulp
> 
> SSH works well also. NTP used the address automatically:
> debian-fs1:~# netstat -anp | grep 3333
> tcp6       0     52 2001:db8:1::3333:22     2001:db8:1::1:61026
> ESTABLISHED 4756/5          
> udp6       0      0 2001:db8:1::3333:123    :::*
> 2308/ntpd     
> 
> 
> |>> [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).
> |
> |I agree with this.  But in the immediately above text you're saying
> |"using /128 for loopback interfaces fits" - I think you meant 'virtual'
> |interface, not 'loopback' interface, right?
> 
> No, absolutely not.
> I provided the evidence that the loopback is perfectly usable already.
> 
> 
> |>>> 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.
> |
> |Ok.
> |
> |
> |> 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.
> |
> |I thought the unplanned aspect could be treated by IPv6 stateless
> |autoconf and IPv6-over-Ethernet link-local addresses.
> 
> Yes and no. I like SLAAC, but with SLAAC, thewre is an address per
> interface. In this model, the node is reachable via the loopback address via
> whatever interface.
> 
> 
> 
> |> 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.
> |
> |Before deciding on the solution (address assigned to a virtual
> |interface) I need to udnerstand how path swap occurs and why.
> 
> Because movement. A MANET Router may have multiple interfaces, some of them
> could be MANET, others wireless infrastructure mode and others MANET. When a
> fire truck leaves the brigade, it looses its wired / wifi ESS connection,
> but can still communicate with other vehicles nearby using MANET links.
> 
> 
> 
> |> Problems started with ARP processing, and I swapped to another
> |> addressing model immediately.
> |
> |>> 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.
> |
> |Ah!  So a correct ULA address would be fd01::1/128?  In this sense, when
> |drawing pictures I have a choice between fd01::1/128 ULA and
> |2001:db8::1/128 global address, it's ambiguous.
> |
> |>>> 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.
> |
> |Ok.
> |
> |> 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.
> |
> |Sounds interesting.  But I think normal DHCP could run ok, provided the
> |Relays know the address of the Server.  In a first practical step would
> |be to manually configure the Server's address on each Relays.
> 
> When many DHCP Relay Agenst are nearby, who to select? If multicast is used,
> all of them will relay and this ends in a DHCP Relay storm (collisions,
> loss, retry .....)
> 
> 
> 
> |> 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.
> |
> |Well it is the case in a MANET made of 25meter IPv6 subnets.
> 
> Voice over IP over WLAN for 25meter? Just shout!!
> My requirements are over 25meter. 25km is no joke. Wifi is not usable here.
> 
> 
> |> 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.
> |
> |Well I think this is indeed a very chickeneggy problem: are addresses in
> |place before routing is, or vice-versa.  But what would we do in
> |practice?  Certainly we'd manually assign some addresses - let's see
> |these cases first.
> 
> No.
> MANETs are often used in workgroups, whit lack of knowledge of configuring
> something. The network must be plug&play / zero-config.
> 
> 
> 
> |>> 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.
> |
> |I think we should consider first the practical cases.
> 
> No. I think we have a clear picture of why MANETs are being used. 
> We need an [Autoconf] solution. Let's take the next steps defining an
> addressing model, write down the requirements and then look for solutions.
> 
> 
> Teco.
> 
> 
> |Alex
> 
> _______________________________________________
> Autoconf mailing list
> Autoconf@ietf.org
> https://www.ietf.org/mailman/listinfo/autoconf
-- 
 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/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++