Re: [Autoconf] Autoconf addressing model

"Teco Boot" <teco@inf-net.nl> Mon, 02 March 2009 11:46 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 2C5F228C223 for <autoconf@core3.amsl.com>; Mon, 2 Mar 2009 03:46:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.996
X-Spam-Level: *
X-Spam-Status: No, score=1.996 tagged_above=-999 required=5 tests=[AWL=-1.700, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_13=0.6, MANGLED_LIST=2.3, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-1]
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 I6x0F0S2+YrX for <autoconf@core3.amsl.com>; Mon, 2 Mar 2009 03:46:56 -0800 (PST)
Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 6C47A28C215 for <autoconf@ietf.org>; Mon, 2 Mar 2009 03:46:54 -0800 (PST)
Received: (qmail 15488 invoked from network); 2 Mar 2009 12:47:17 +0100
Received: from static.kpn.net (HELO M90Teco) (77.61.241.196) by server9.hosting2go.nl with SMTP; 2 Mar 2009 12:47:17 +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> <007b01c99911$907facf0$b17f06d0$@nl> <49A8471E.6090506@gmail.com> <009501c99920$92154340$b63fc9c0$@nl> <49A944FF.9000102@gmail.com>
In-Reply-To: <49A944FF.9000102@gmail.com>
Date: Mon, 02 Mar 2009 12:46:48 +0100
Message-ID: <003001c99b2c$a3fcf4a0$ebf6dde0$@nl>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcmZreP63KOEox2JTDSgiOwp9x9iRgBdoqdQ
Content-Language: nl
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: Mon, 02 Mar 2009 11:46:57 -0000

Hi Alex,

More on "loopback interface".
And more on non-blocking obstacles.



|> Check for example ISP BCP, rfc5375
|
|Checked.  The fact that Cisco uses 'loopback interface' to be something
|completely different than the interface holding the loopback address
|doesn't mean I should too.  I disagree with Cisco on this particular
|point.

RFC5373 is not a "Cisco document". It is a IETF product, produced by v6ops.
V6ops produces informational or BCP RFCs only.
Many router vendors support loopback interfaces.
Do you disagree with the v6ops document, best practices of most (all?) ISPs
and most router vendors?


ID.autoconf-manetarch-07 section 5.1 also suggests using the loopback
interface for binding a globally unique address. 
My suggestion is using the loopback interface for the /128 (or /32)
address(es), not the MANET Interface(s) as suggested in 5.2.




|>    The unicast address 0:0:0:0:0:0:0:1 is called the loopback address.
|>    It may be used by a node to send an IPv6 packet to itself.  It must
|>    not be assigned to any physical interface.  It is treated as having
|>    Link-Local scope, and may be thought of as the Link-Local unicast
|>    address of a virtual interface (typically called the "loopback
|>    interface") to an imaginary link that goes nowhere.
|>
|> Note the wording "may be".
|
|Note the status of that rfc compared to the two rfcs you cited
|previously calling the loopback interface a virtual interface.

Yes. A loopback interface is a virtual interface. A virtual interface is NOT
a loopback interface. Another example of non-transitivity.




|> Assigning non-"loopback addresses" on the loopback interfaces is
|permitted.
|
|YEs, it is permitted, I agree.
|
|But why should one do it?

I came up with a handful advantages already:  
 o Lower overhead. If each MANET interface would use a [MANET local]
   and optionally a set of globally unique addresses, more addresses
   are used and load on the MANET (and other) protocols is higher.
 o No address swap needed when session swaps from one interface to the
   other. Protocols like MIP6, HIP and SHIM6 could repair the issue in
   some cases, in other cases they cannot. How to reach a MIP6 HA in
   a disconnected MANET?)
 o If a MANET interfaces goes up and down (e.g. single neighbor flapping), 
   the application may get affected. Using a virtual interface (typically
   the loopback interface), application layer recovery is circumvented.




|> Your assumption is single hop communication and no MANET routing
|protocol. I
|> am interested in the more complex topologies.
|
|The pictures I drawn are multihop.  And indeed I don't assume a MANET
|routing protocol.  Neither does the charter.  And that's ok.

Sorry, I missed this. Do you mean that host - router is multi-hop? Who is
forwarding?
Let's use figure 1-2 below. Is there connectivity between B and C, via A?



|> There is no "essid" in ad hoc mode. It is the "ssid" of the IBSS. Only
|ESS
|> has essid.
|> Let's try to be accurate.
|
|iwconfig essid "adhoc1" mode ad-hoc
|is also accurate.

Please use terms as standardized.
ESSID stands for the name of an extended service set (ESS). An ESS is a set
of basic service sets, connected over a distribution service. ESS is far
from IBSS (more or less the opposite). I can't help the Linux iwconfig
syntax uses essid for what should be the well defined 802.11 SSID.




|> What about this scenario: here, the obstacle is moving:
|>
|> (802.11 term: STA is station)
|>
|>           +------------------------+   +------------------------+
|>           |                        |   |                        |
|>           |           ____STA-B    |   |           ____STA-B    |
|>           |       ___/      |      |   |       ___/             |
|>           |  STA-A          |      |   |  STA-A      OBSTACLE   |
|>           |      '--_       |      |   |      '--_              |
|>           |          '----STA-C    |   |          '----STA-C    |
|>           |  OBSTACLE              |   |                        |
|>           +------------------------+   +------------------------+
|>                1-1: No hindrance            1-2: B-C blocked
|>
|>           +------------------------+   +------------------------+
|>           |                        |   |          O             |
|>           |           ____STA-B    |   |          B    STA-B    |
|>           |       ___/      |      |   |          S      |      |
|>           |  STA-A      OB  |      |   |  STA-A   T      |      |
|>           |            ST   |      |   |          A      |      |
|>           |           AC  STA-C    |   |          C    STA-C    |
|>           |         LE             |   |          LE            |
|>           +------------------------+   +------------------------+
|>                1-3: A-C blocked         1-4: A-B & A-C blocked
|>
|>                 MANET Scenarios with blocking obstacle
|
|This is absolutely wonderful.  I set it aside.
|
|> Compare with this one:
|>
|> (802.11 term: AP is access point)
|>
|>           +------------------------+   +------------------------+
|>           |                        |   |                        |
|>           |           ____STA-B    |   |           ____STA-B    |
|>           |       ___/             |   |       ___/             |
|>           |   AP-A                 |   |   AP-A      OBSTACLE   |
|>           |      '--_              |   |      '--_              |
|>           |          '----STA-C    |   |          '----STA-C    |
|>           |  OBSTACLE              |   |                        |
|>           +------------------------+   +------------------------+
|>                4-1: No hindrance            4-2: No hindrance
|>
|>           +------------------------+   +------------------------+
|>           |                        |   |          O             |
|>           |           ____STA-B    |   |          B    STA-B    |
|>           |       ___/             |   |          S             |
|>           |   AP-A      OB         |   |   AP-A   T             |
|>           |            ST          |   |          A             |
|>           |           AC  STA-C    |   |          C    STA-C    |
|>           |         LE             |   |          LE            |
|>           +------------------------+   +------------------------+
|>            4-3: A-C & B-C blocked         4-4: All blocked
|>
|>              802.11 BSS L2 topology with blocking obstacle
|>
|>
|> In these scenario's, the MANET model provides better connectivity. I
|won't
|> say more bandwidth, lower loss or other link quality metrics, but for
|high
|> availability the MANET model definitely wins.
|
|I set this aside too.
|
|HAving them pictured, may I ask you: do you think anything will ever be
|able to communicate through Obstacles?


Yes, of course.


          +------------------------+   +------------------------+
          |                        |   |                        |
          |           ____STA-B    |   |           ____STA-B    |
          |       ___/ 1    |      |   |       ___/ 1    .      |
          |  STA-A          | 1    |   |  STA-A    obstacle 5   |
          |      '--_ 1     |      |   |      '--_ 1     .      |
          |          '----STA-C    |   |          '----STA-C    |
          |  obstacle              |   |                        |
          +------------------------+   +------------------------+
               2-1: No hindrance            2-2: B-C degraded

          +------------------------+   +------------------------+
          |                        |   |          o             |
          |           ____STA-B    |   |       5  b ...STA-B    |
          |       ___/ 1    |      |   |       ...s.     |      |
          |  STA-A      ob  | 1    |   |  STA-A  t       | 1    |
          |       ...  st   |      |   |       ...a.     |      |
          |       5  .ac..STA-C    |   |       5  c ...STA-C    |
          |         le             |   |          le            |
          +------------------------+   +------------------------+
               2-3: A-C degraded        2-4: A-B & A-C degraded

                Scenarios with degrading obstacle


I depicted the metrics: 1 is good, 5 is degraded.

Here the routing tables, with metrics:

      ROUTER   DEST   NEXTHOP METRIC    ROUTER   DEST   NEXTHOP METRIC
     +-------+-------+-------+------+  +-------+-------+-------+------+
     |   A   |   B   |   B   |    1 |  |   A   |   B   |   B   |    1 |
     |       |   C   |   C   |    1 |  |       |   C   |   C   |    1 |
     +-------+-------+-------+------+  +-------+-------+-------+------+
     |   B   |   A   |   A   |    1 |  |   B   |   A   |   A   |    1 |
     |       |   C   |   C   |    1 |  |       |   C   |   C   |    5 |
     +-------+-------+-------+------+  +-------+-------+-------+------+
     |   C   |   A   |   A   |    1 |  |   C   |   A   |   A   |    1 |
     |       |   B   |   B   |    1 |  |       |   B   |   B   |    5 |
     +-------+-------+-------+------+  +-------+-------+-------+------+
          11-1: No hindrance                11-2: B-C is degraded

     +-------+-------+-------+------+  +-------+-------+-------+------+
     |   A   |   B   |   B   |    1 |  |   A   |   B   |   B   |    5 |
     |       |   C   |   C   |    5 |  |       |   C   |   C   |    5 |
     +-------+-------+-------+------+  +-------+-------+-------+------+
     |   B   |   A   |   A   |    1 |  |   B   |   A   |   A   |    5 |
     |       |   C   |   C   |    1 |  |       |   C   |   C   |    1 |
     +-------+-------+-------+------+  +-------+-------+-------+------+
     |   C   |   A   |   A   |    5 |  |   C   |   A   |   A   |    5 |
     |       |   B   |   B   |    1 |  |       |   B   |   B   |    1 |
     +-------+-------+-------+------+  +-------+-------+-------+------+
           11-3: A-C degraded               11-4: A-B & A-C degraded


This is for the MANET scenario. I can provide this for infrastructure mode
also, if you want me to.


Teco.


|Alex