Review: draft-ietf-v6ops-onlinkassumption-00.txt

["Bound, Jim" <jim.bound@hp.com>]

WG sorry.  mean't to send this one to v6ops too.
/jim

-----Original Message-----
From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On Behalf Of
Bound, Jim
Sent: Saturday, October 25, 2003 6:38 PM
To: ipv6@ietf.org
Subject: Review: draft-ietf-v6ops-onlinkassumption-00.txt


Review input on draft-ietf-v6ops-onlinkassumption-00.txt and suggestions
for next steps.

   1. Introduction

   Neighbor Discovery for IPv6 [ND] defines a conceptual sending
   algorithm for hosts.  This algorithm states that if a host's default
   router list is empty, then the host assumes that all destinations are
   on-link.

   This assumption creates problems for destination address selection as
   defined in [ADDRSEL], and adds connection delays associated with
   unnecessary address resolution and neighbor unreachability detection.
   The behavior associated with the assumption is undefined in
   multihomed scenarios, and has some subtle security implications.  All
   of these issues are discussed in this document.

This entire spec is predicated on statement in 2461 that are conceptual
and not required as compliance to ND RFC 2461.  In fact I know multiple
implementations that approached some of the specifics of this
differently, which is fine as this part of ND gets into a suggestion and
not an IETF compliance to the standard.  Also below is the wording I
think relative I provide from 2461.  I also want to note the caveat
stated in section 5. below where ND clearly states it is not addressing
the issues of source address selection and multihomed hosts. I recall
when this was added to ND and the spec in review here is exactly why it
made me nervous to put it in ND, thus the lower paragraph in section 5.
inroduction below my comments.

I believe the L bit with prefix options is an excellent optimzation for
communications for IPv6 if used correctly.  That is not the issue.  So I
would like to suggest that the title currently of the draft "IPv6
Neighbor Discovery On-Link Assumption Considered Harmful" is not a good
reference to the problem the spec is concerned with.  At a minimum it
should have something like "conceptual sending algorithm" should be
checked or however best to denote this spec's issue.  But the current
title I feel is misleading.

My input to the authors and the IPv6 WG is that providing a BCP update
to section 5 for address selection, and then probably a different spec
for multihomed hosts is the work to be done.  ND section 5 is very clear
as a spec this is a "conceptual" reference and that it is specifically
not to be used for address selection or multihomed hosts.  See 2461
references below.

From 2461 5. Conceptual Model of a Host

   5.  CONCEPTUAL MODEL OF A HOST

   This section describes a conceptual model of one possible data
   structure organization that hosts (and to some extent routers) will
   maintain in interacting with neighboring nodes.  The described
   organization is provided to facilitate the explanation of how the
   Neighbor Discovery protocol should behave.  This document does not
   mandate that implementations adhere to this model as long as their
   external behavior is consistent with that described in this document.

   This model is only concerned with the aspects of host behavior
   directly related to Neighbor Discovery.  In particular, it does not
   concern itself with such issues as source address selection or the
   selecting of an outgoing interface on a multihomed host.

From 2461 5.2 Conceptual Sending Algorithm

   Next-hop determination for a given unicast destination operates as
   follows.  The sender performs a longest prefix match against the
   Prefix List to determine whether the packet's destination is on- or
   off-link.  If the destination is on-link, the next-hop address is the
   same as the packet's destination address.  Otherwise, the sender
   selects a router from the Default Router List (following the rules
   described in Section 6.3.6).  If the Default Router List is empty,
   the sender assumes that the destination is on-link.

Thanks,
/jim



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