[Autoconf] FW: Comments ondraft-clausen-manet-autoconf-recommendations-00

"Templin, Fred L" <Fred.L.Templin@boeing.com> Thu, 26 March 2009 17:05 UTC

Return-Path: <Fred.L.Templin@boeing.com>
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 748963A6803 for <autoconf@core3.amsl.com>; Thu, 26 Mar 2009 10:05:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.985
X-Spam-Level:
X-Spam-Status: No, score=-5.985 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, 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 WZM6R9hzpnQP for <autoconf@core3.amsl.com>; Thu, 26 Mar 2009 10:05:56 -0700 (PDT)
Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 78F943A67E3 for <autoconf@ietf.org>; Thu, 26 Mar 2009 10:05:56 -0700 (PDT)
Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n2QH6iNF008132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <autoconf@ietf.org>; Thu, 26 Mar 2009 12:06:49 -0500 (CDT)
Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n2QH6iqU023824 for <autoconf@ietf.org>; Thu, 26 Mar 2009 10:06:44 -0700 (PDT)
Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n2QH6h9g023737 for <autoconf@ietf.org>; Thu, 26 Mar 2009 10:06:44 -0700 (PDT)
Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Mar 2009 10:06:44 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 26 Mar 2009 10:06:42 -0700
Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A105BB549C@XCH-NW-7V2.nw.nos.boeing.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Autoconf] Comments ondraft-clausen-manet-autoconf-recommendations-00
Thread-Index: AcmsOOqOPrq0smnpSVCmRVatUq53GwAlxlJwAFk0UnA=
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: autoconf@ietf.org
X-OriginalArrivalTime: 26 Mar 2009 17:06:44.0148 (UTC) FILETIME=[3D493F40:01C9AE35]
Subject: [Autoconf] FW: Comments ondraft-clausen-manet-autoconf-recommendations-00
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: Thu, 26 Mar 2009 17:05:57 -0000

Ronald,

I thought this might be of general interest to the
list (below):

Fred
fred.l.templin@boeing.com

-----Original Message-----
From: Templin, Fred L 
Sent: Tuesday, March 24, 2009 3:48 PM
To: 'Velt, R. (Ronald) in 't'
Subject: RE: [Autoconf] Comments
ondraft-clausen-manet-autoconf-recommendations-00

Ronald,

(off-list) see below:
 
> Furthermore, the use of /32's (/128's) appears to exclude a
> configuration
> as depicted below:
> 
> 		 <------------------>	<----------------->
>           \|/		         \|/                   \|/
>            |			    |                     |
>          +-+-+                  +-+-+                 +-+-+
>    \|/   | R |   \|/            | R |          \|/    | R |	  \|/
>     |	   +---+    |             +---+           |     +---+	   |
>   +-+-+         +-+-+	                      +-+-+          +-+-+
>   | H |         | H |                         | H |          | H |
>   +---+         +---+                         +---+          +---+
> 
>   H = host
>   R = router
> 
> Here, all nodes just have a single radio interface. Some are
configured
> to be
> hosts, wheras others are routers. Hosts can be considered as
> "satellites" of
> routers, in the sense that each of them is associated with a
particular
> router
> and travels with it. Each host has a default route, with its
associated
> router
> as the next hop.
> 
> This can be made to work by assigning e.g. /24's from different
> "subnets"
> to the routers. For instance, in the picture above, the leftmost
router
> gets
> 192.168.1.254, the middle one 192.168.2.254 and the rightmost router
> 192.168.3.254. The broadcast address on the routers should be set to
> have a wider
> "scope" (shorter prefix)than their unicast addresses, e.g.
> 192.168.255.255 or even
> 255.255.255.255. This ensures that any protocols that rely on
broadcast
> still work
> between routers. (Autoconfiguration protocols could potentially fall
> into this
> category, as do some older implementations of MANET routing
protocols).
> Hosts
> are configured with addresses from the same subnet as their associated
> router. The
> hosts in the leftmost cluster in the picture above would e.g. be
> 192.168.1.1 and
> 192.168.1.2.
> 
> It could be argued that for this scenario, separate virtual interfaces
> should
> be configured on top of the radio interface. One virtual interface
would
> then serve
> as MANET interface, while the other(s) would be used for communication
> with local
> hosts. However, depending on the L2 technology / implementation used,
> this may not
> be readily achievable.
> 
> The above may not be a very common case and therefore we could agree
to
> not
> support it. However, in my opinion this should be a conscious and
> documented
> decision.

If we are willing to let the "tethered" hosts be IPv6-only,
I think this is not such a difficult challenge. As long
as the router 'R' has a spare IPv6 prefix 'P', it can
send RAs over the MANET interface with a router lifetime,
with a PIO containing 'P' and with 'A'=1, 'L'=0. Note that
'R' assigns an IPv6 link-local only to the MANET interface;
it does *not* assign an IPv6 global.

The reason for 'L'=0 is that two hosts 'H1' and 'H2' may
be tethered to 'R' but for some reason not able to reach
each other directly. So, to avoid communications failures
and neighbor cache pollution it is important that 'H1'
and 'H2' send all packets through 'R' as a default router.

The reason for 'A'=1 is that we want to use SLAAC per
RFC4862 to autoconfigure the addresses. But with 'L'=0,
that would mean a /128, and not a /64, etc.