RE: Off-link mode supported?

"Templin, Fred L" <Fred.L.Templin@boeing.com> Thu, 29 June 2006 16:49 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvzhz-0000Pd-Hd; Thu, 29 Jun 2006 12:49:39 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvzhy-0000PY-JL for ipv6@ietf.org; Thu, 29 Jun 2006 12:49:38 -0400
Received: from stl-smtpout-01.boeing.com ([130.76.96.56] helo=stl-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvzhx-0000RN-7v for ipv6@ietf.org; Thu, 29 Jun 2006 12:49:38 -0400
Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by stl-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id k5TGnacZ000634; Thu, 29 Jun 2006 11:49:36 -0500 (CDT)
Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k5TGnZw24838; Thu, 29 Jun 2006 09:49:35 -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.1830); Thu, 29 Jun 2006 09:49:34 -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, 29 Jun 2006 09:49:33 -0700
Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1017740D5@XCH-NW-7V2.nw.nos.boeing.com>
In-Reply-To: <11996864.3705311151549110352.JavaMail.root@vms063.mailsrvcs.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Off-link mode supported?
Thread-Index: AcabJii5+hvcLBU5Qb6s70wopm9FxgAdE7zQ
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: timbeck04@verizon.net, Alun Evans <alun@cisco.com>, ipv6@ietf.org
X-OriginalArrivalTime: 29 Jun 2006 16:49:34.0077 (UTC) FILETIME=[FFD122D0:01C69B9B]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290
Cc:
Subject: RE: Off-link mode supported?
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
Errors-To: ipv6-bounces@ietf.org

Here is an instance in which the off-link model is applied:

http://www.ietf.org/internet-drafts/draft-ietf-netlmm-mn-ar-if-01.txt

Note that for some links, it might be that two communicating
endpoints would be on-link with a router but not on-link wrt
each other - in which case, traffic would have to go through
the router and the router cannot generate a redirect. (MANETs
are one example; cellular wireless is another.)

Fred
fred.l.templin@boeing.com 

-----Original Message-----
From: timbeck04@verizon.net [mailto:timbeck04@verizon.net] 
Sent: Wednesday, June 28, 2006 7:45 PM
To: Alun Evans; ipv6@ietf.org
Subject: Re: Off-link mode supported?

>From: Alun Evans <alun@cisco.com>
>Date: Tue Jun 27 12:13:17 CDT 2006
>To: ipv6@ietf.org
>Subject: Off-link mode supported?

>I'm considering a deployment where it could be nice to make use of some
of the
>notes as described in :
>
>draft-ietf-ipv6-multilink-subnets-00.txt (expired June 2002)
>
>particularly the notion of "off-link" mode:
>
>-----------------------------------------------------------------------
-------
>4.1.1.  Making hosts not use ND
>
>If the MSR sets the A (autonomous address-configuration) flag on,
>and the L (on-link) flag off, then hosts on the link will attempt
>stateless address configuration [ADDRCONF] in the given prefix,
>but will not treat the prefix as being on-link. 
>As a result, neighbor discovery is effectively disabled

To say that setting the 'L' flag to '0' effectively disables ND is a bit
of a stretch.

> and packets to new
>destinations always go to the router first, which will then either
>forward them if the destination is off-link, or redirect them if
>the destination is on-link.
>
>In the remainder of this document, we will refer to this model as
>the "off-link" model, since hosts initially treat all addresses in
>the subnet as being off-link.
>
>...
>
>Collisions would result if the interface identifier were unique on
>the link, but not across the entire multilink subnet.  To avoid
>this, MSRs must get involved in duplicate address detection even
>for link-local addresses, to ensure that all addresses are unique
>across a multilink subnet.
>
>...
>
>Off-link model
>     If the subnet is treated as being off-link, all packets are
>     sent to a default router.  It is then the default router's
>     responsibility to figure out the next-hop of the packets.  If
>     the next-hop is on-link, it sends a Redirect to the source.
>-----------------------------------------------------------------------
-------
>
>The I-D seemed to die due to the problems described in:
>
>draft-thaler-intarea-multilink-subnet-issues-00.txt (expires August
2006)
>
>and was replaced with ND Proxies [RFC4389] for the multi-link support.
>
>
>However, nothing seems to have deprecated off-link mode, but I cannot
think of
>a single deployment that currently uses it, thus do people think it's
safe to
>use it? i.e. is it likely to be well supported?

Neither am I aware of any deployments currently using the off-link
model. To use that model seems inefficient at best, especially given the
likelihood that nodes on the same link would ever need to communicate
with one another. To have even the initial such traffic first go to a
default router (just to have a Redirect generated) both makes the router
do more work (however little it may be) than it needs to do, and delays
communication (however little) between on-link nodes. I'm not aware of a
compelling technical reason for ever using it, though I'm open to
hearing from those who are.

Best regards,

Tim Enos
Rom 8:28

>
>(If it's not, then why is the O bit still in the specs...)
>
>
>
>
>thanks,
>
>
>
>Alun.
>
>
>-- 
>Alun Evans
>IOS Software Engineer, cisco Systems.
>http://www.cisco.com/go/ipv6/
>
>--------------------------------------------------------------------
>IETF IPv6 working group mailing list
>ipv6@ietf.org
>Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
>--------------------------------------------------------------------


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------