Re: Off-link mode supported?

<timbeck04@verizon.net> Thu, 29 June 2006 02:45 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvmWr-00040x-Q7; Wed, 28 Jun 2006 22:45:17 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvmWq-00040r-16 for ipv6@ietf.org; Wed, 28 Jun 2006 22:45:16 -0400
Received: from vms046pub.verizon.net ([206.46.252.46]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvmWo-0001FD-Nh for ipv6@ietf.org; Wed, 28 Jun 2006 22:45:16 -0400
Received: from vms063.mailsrvcs.net ([192.168.1.4]) by vms046.mailsrvcs.net (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPA id <0J1L008LJOZAIMI5@vms046.mailsrvcs.net> for ipv6@ietf.org; Wed, 28 Jun 2006 21:45:10 -0500 (CDT)
Date: Wed, 28 Jun 2006 21:45:10 -0500
From: timbeck04@verizon.net
To: Alun Evans <alun@cisco.com>, ipv6@ietf.org
Message-id: <11996864.3705311151549110352.JavaMail.root@vms063.mailsrvcs.net>
MIME-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: 7bit
X-Spam-Score: 0.7 (/)
X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43
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

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