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

From: "Bound, Jim" <[email-masked]>
Date: Sat, 25 Oct 2003 18:38:27 -0400

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
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 27 Oct 2003 11:04:26 +0100 (CET)

> and not required as compliance to ND RFC 2461.  

Well, the behavior is actually used in section
6.3.6 "Default Router Selection" where section 6 is "host specificatio",
thus it isn't only a conceptual thing.  
6.3.6 says:
     3) If the Default Router List is empty, assume that all
        destinations are on-link as specified in Section 5.2.

At a minimum the specification is unclear on the requirements in this space,
but the way I read it (and wrote it :-) this is something that nodes
are recommended to do.

Thus I think we need to change that recommendation and make the
specification clearer in the process.

   Erik

---

From: Pekka Savola <[email-masked]>
Date: Mon, 27 Oct 2003 16:03:32 +0200 (EET)

> Review input on draft-ietf-v6ops-onlinkassumption-00.txt and suggestions

(For information to those who'd like to follow up on Jim's two review 
messages..)

I think it would be useful to continue the debate on:

draft-ietf-v6ops-onlinkassumption and
draft-ietf-v6ops-v6onbydefault

.. documents on the v6ops list, [email-masked], to ensure that the
document editors and the WG don't miss any parts of discussion on these
documents.

The draft-ietf-v6ops-onlinkassumption could also be additionally Cc:'ed to
th IPv6 WG as it's more pertinent to the current discussion of revising
RFC2461 and the IPv6 WG members may be interested to stay on the loop..

Writing as *visiting* v6ops WG co-chair :-),
 Pekka