RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt

"Hemant Singh (shemant)" <shemant@cisco.com> Mon, 14 July 2008 15:11 UTC

Return-Path: <ipv6-bounces@ietf.org>
X-Original-To: ipv6-archive@megatron.ietf.org
Delivered-To: ietfarch-ipv6-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 920703A6B44; Mon, 14 Jul 2008 08:11:53 -0700 (PDT)
X-Original-To: ipv6@core3.amsl.com
Delivered-To: ipv6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91F603A6B2C for <ipv6@core3.amsl.com>; Mon, 14 Jul 2008 08:11:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.807
X-Spam-Level:
X-Spam-Status: No, score=-5.807 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, J_CHICKENPOX_13=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 9LdhP9yH1cay for <ipv6@core3.amsl.com>; Mon, 14 Jul 2008 08:11:51 -0700 (PDT)
Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id AC6E03A6B39 for <ipv6@ietf.org>; Mon, 14 Jul 2008 08:11:24 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.30,359,1212364800"; d="scan'208";a="86964620"
Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 14 Jul 2008 15:11:50 +0000
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m6EFBoj1009377; Mon, 14 Jul 2008 08:11:50 -0700
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id m6EFBn5V012268; Mon, 14 Jul 2008 15:11:50 GMT
Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jul 2008 11:11:49 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
Date: Mon, 14 Jul 2008 11:11:49 -0400
Message-ID: <B00EDD615E3C5344B0FFCBA910CF7E1D04E41F46@xmb-rtp-20e.amer.cisco.com>
In-Reply-To: <986DCE2E44129444B6435ABE8C9E424D01861D4D@SGSINSMBS02.ad4.ad.alcatel.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
Thread-Index: AcjjiL2JL7mumBJPQYigdSKP+J0ZSQBzTEQgABlQEnA=
References: <mailman.69.1215802811.29651.ipv6@ietf.org> <986DCE2E44129444B6435ABE8C9E424D01861D4D@SGSINSMBS02.ad4.ad.alcatel.com>
From: "Hemant Singh (shemant)" <shemant@cisco.com>
To: MILES DAVID <David.Miles@alcatel-lucent.com.au>, ipv6@ietf.org, erik.nordmark@sun.com, "Wes Beebee (wbeebee)" <wbeebee@cisco.com>
X-OriginalArrivalTime: 14 Jul 2008 15:11:49.0472 (UTC) FILETIME=[F066EE00:01C8E5C3]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2520; t=1216048310; x=1216912310; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20<shemant@cisco. com> |Subject:=20RE=3A=206MAN=20WG=20Last=20Call=3Adraft-ietf-6m an-ipv6-subnet-model-00.txt |Sender:=20; bh=4VrtVEHoOGgVyXnXb+8bFqRMldHuSm6abGJVq8OXGzQ=; b=stkaFrdrVua4UeLQBktyuSwz/zlcCchNAmIsw+ZzV536t94KTF8VOqW+Jf +N/Iu0sOvXv2A6tpv2vGiqAaHmFud041rAbGbTY4Y/KSyKwdIAm5sv/HMkVs B/Fgi/8+IL;
Authentication-Results: sj-dkim-3; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; );
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

David,

What is UHL?

Then please see in line below between <hs> and </hs>

-----Original Message-----
From: MILES DAVID [mailto:David.Miles@alcatel-lucent.com.au] 
Sent: Sunday, July 13, 2008 11:15 PM
To: ipv6@ietf.org; Hemant Singh (shemant); erik.nordmark@sun.com; Wes
Beebee (wbeebee)
Subject: RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt

Wes,

There are implementations that update their routing table on the receipt
of a Neighbour Advertisement which we should consider. One example is
the code developed in the KAME project, which can be found in many
BSD-based distros. On receipt of a valid NS, the neighbour cache is
updated with a stale entry and if a route does not exist for the
destination a host route is created (with flags UHL). 
This behaviour makes sense if we consider the old on-link assumption -
but it opens the security concern I expressed in v6ops. It is quite
possible for an on-link node to create route entries in that may affect
other links (say the target of this were an ISP router). I do not think
this behaviour is desirable in a router.

I would prefer to avoid behaviours that create bogus entries. It seems
that we defiantly need clarification around correct node behaviour, and
if we are clarifying (to be explicit that the receipt of a ND has no
affect on forwarding) then should we go so far as to avoid the bogus
entry?


For interest; in the KAME example will drop a received NA when the
target-address is not in its Neighbour Cache (the NA is discarded).

<hs>
This behavior by KAME is correct. See text snipped from section 7.2.5
that mentions this behavior reported by you for KAME.
[When a valid Neighbor Advertisement is received (either solicited or
   unsolicited), the Neighbor Cache is searched for the target's entry.
   If no entry exists, the advertisement SHOULD be silently discarded.]
</hs>

Hemant


-David


>>>
Sorry to reopen this, but do you think that the following clarification
could be added to the IPv6 Subnet Models draft to address bullets three
and four of the on-link definition in the Terminology section of RFC
4861:

"Since only the Neighbor Cache is updated with the source address of a
received ND packet or the target of an NA packet, and the Destination
Cache and Prefix List are not updated, an ND packet cannot indicate that
a destination is on-link in the absence of corresponding on-link prefix
information."

What does the WG think?

- Wes

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