Re: [Autoconf] Autoconf addressing model

"Teco Boot" <teco@inf-net.nl> Fri, 27 February 2009 19:28 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 E5CD03A6A89 for <autoconf@core3.amsl.com>; Fri, 27 Feb 2009 11:28:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.575
X-Spam-Level:
X-Spam-Status: No, score=-0.575 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_44=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_55=0.6, J_CHICKENPOX_56=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 MH9t+5i9bUmg for <autoconf@core3.amsl.com>; Fri, 27 Feb 2009 11:28:28 -0800 (PST)
Received: from cpsmtpo-eml02.kpnxchange.com (cpsmtpo-eml02.KPNXCHANGE.COM [213.75.38.151]) by core3.amsl.com (Postfix) with ESMTP id 21A653A6A45 for <autoconf@ietf.org>; Fri, 27 Feb 2009 11:28:27 -0800 (PST)
Received: from cpsmtp-eml109.kpnxchange.com ([10.94.168.109]) by cpsmtpo-eml02.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Feb 2009 20:28:28 +0100
Received: from M90Teco ([86.83.9.22]) by cpsmtp-eml109.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Feb 2009 20:28:28 +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> <007201c99903$c4182c80$4c488580$@nl> <49A82E55.10208@gmail.com>
In-Reply-To: <49A82E55.10208@gmail.com>
Date: Fri, 27 Feb 2009 20:28:27 +0100
Message-ID: <007b01c99911$907facf0$b17f06d0$@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: AcmZB7nuNP3vnYWDSVSxqkIY+onCOQAA8YfQ
Content-Language: nl
x-cr-hashedpuzzle: BjwL DhGr DrxE D1v0 EcOL Fzq6 Hlfc IkZY KW9k LW8M LnJX MfBD Rl+E SAYq Tlnu VHkq; 2; YQBsAGUAeABhAG4AZAByAHUALgBwAGUAdAByAGUAcwBjAHUAQABnAG0AYQBpAGwALgBjAG8AbQA7AGEAdQB0AG8AYwBvAG4AZgBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {2D4501FF-44F0-410D-8F0C-7AB1A93A2828}; dABlAGMAbwBAAGkAbgBmAC0AbgBlAHQALgBuAGwA; Fri, 27 Feb 2009 19:28:21 GMT; UgBFADoAIABBAHUAdABvAGMAbwBuAGYAIABhAGQAZAByAGUAcwBzAGkAbgBnACAAbQBvAGQAZQBsAA==
x-cr-puzzleid: {2D4501FF-44F0-410D-8F0C-7AB1A93A2828}
X-OriginalArrivalTime: 27 Feb 2009 19:28:28.0069 (UTC) FILETIME=[90DD5D50:01C99911]
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 19:28:30 -0000

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.

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



|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