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

Erik Nordmark <erik.nordmark@sun.com> Mon, 14 July 2008 10:23 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 7AE2428C25F; Mon, 14 Jul 2008 03:23:05 -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 A6D8628C25F for <ipv6@core3.amsl.com>; Mon, 14 Jul 2008 03:23:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.742
X-Spam-Level:
X-Spam-Status: No, score=-2.742 tagged_above=-999 required=5 tests=[AWL=0.304, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_LOW=-1]
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 sow62XYT9Qwf for <ipv6@core3.amsl.com>; Mon, 14 Jul 2008 03:23:03 -0700 (PDT)
Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id D50E228C258 for <ipv6@ietf.org>; Mon, 14 Jul 2008 03:23:01 -0700 (PDT)
Received: from jurassic.eng.sun.com ([129.146.108.31]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m6EAMJCw010231; Mon, 14 Jul 2008 10:22:19 GMT
Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6EAM2dw747273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jul 2008 03:22:13 -0700 (PDT)
Message-ID: <487B289B.3020003@sun.com>
Date: Mon, 14 Jul 2008 03:21:15 -0700
From: Erik Nordmark <erik.nordmark@sun.com>
User-Agent: Thunderbird 2.0.0.4 (X11/20070723)
MIME-Version: 1.0
To: Thomas Narten <narten@us.ibm.com>
Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
References: <D9872168DBD43A41BD71FFC4713274D405429068@xmb-ams-33b.emea.cisco.com> <BB56240F3A190F469C52A57138047A03A2C459@xmb-rtp-211.amer.cisco.com> <986DCE2E44129444B6435ABE8C9E424D0170C2BD@SGSINSMBS02.ad4.ad.alcatel.com> <B00EDD615E3C5344B0FFCBA910CF7E1D04E41E2B@xmb-rtp-20e.amer.cisco.com> <986DCE2E44129444B6435ABE8C9E424D01762084@SGSINSMBS02.ad4.ad.alcatel.com> <B00EDD615E3C5344B0FFCBA910CF7E1D04E41E52@xmb-rtp-20e.amer.cisco.com> <986DCE2E44129444B6435ABE8C9E424D01762C38@SGSINSMBS02.ad4.ad.alcatel.com> <200807031533.m63FXZdM030742@cichlid.raleigh.ibm.com>
In-Reply-To: <200807031533.m63FXZdM030742@cichlid.raleigh.ibm.com>
Cc: ipv6@ietf.org, MILES DAVID <David.Miles@alcatel-lucent.com.au>
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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

Thomas Narten wrote:

> It is clear to me that bullet four in RFC 4861:
> 
>>    on-link     - an address that is assigned to an interface on a
>>                  specified link.  A node considers an address to be on-
>>                  link if:
>>
>>                     - it is covered by one of the link's prefixes (e.g.,
>>                       as indicated by the on-link flag in the Prefix
>>                       Information option), or
>>
>>                     - a neighboring router specifies the address as the
>>                       target of a Redirect message, or
>>
>>                     - a Neighbor Advertisement message is received for
>>                       the (target) address, or
>>
>>                     - any Neighbor Discovery message is received from
>>                       the address.
> 
> Is wrong and needs tweaking. We should fix that on the next update of
> the ND spec. :-)

I agree that bullet four doesn't seem useful.
But I think the same thing applies to the third bullet above; I know of 
no case where it is necessary or useful, and I think it is a potential 
security issue if implemented on multi-interfaced nodes, since the 
receipt of an NA on interface B could conflict with the fact that the 
while prefix is on-link on interface A.


Popping up a level, we set out to clarify the subnet model in this 
draft. Until recently I considered David's on-link issues to be separate 
from the subnet model. But after catching up on this whole thread it 
seems the two issues are closely related.

Hence my question for the WG. Should we expand the scope of 
draft-ietf-6man-ipv6-subnet-model to also clarify/change the on-link 
handling in RFC 4861?

    Erik

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