[MEXT] Issue #16 on 3775bis
"Pascal Thubert (pthubert)" <pthubert@cisco.com> Tue, 02 December 2008 17:04 UTC
Return-Path: <mext-bounces@ietf.org>
X-Original-To: monami6-archive@megatron.ietf.org
Delivered-To: ietfarch-monami6-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id C21B73A6811;
Tue, 2 Dec 2008 09:04:05 -0800 (PST)
X-Original-To: mext@core3.amsl.com
Delivered-To: mext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 087D628C17D
for <mext@core3.amsl.com>; Tue, 2 Dec 2008 09:04:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.383
X-Spam-Level:
X-Spam-Status: No, score=-10.383 tagged_above=-999 required=5
tests=[AWL=0.216, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 QKB6kr4Lfz2o for <mext@core3.amsl.com>;
Tue, 2 Dec 2008 09:04:04 -0800 (PST)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140])
by core3.amsl.com (Postfix) with ESMTP id 40F1A3A6811
for <mext@ietf.org>; Tue, 2 Dec 2008 09:04:02 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.33,702,1220227200"; d="scan'208";a="27443517"
Received: from ams-dkim-1.cisco.com ([144.254.224.138])
by ams-iport-1.cisco.com with ESMTP; 02 Dec 2008 17:03:55 +0000
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150])
by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mB2H3tHA023356;
Tue, 2 Dec 2008 18:03:55 +0100
Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com
[144.254.231.87])
by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mB2H3r1Q010683;
Tue, 2 Dec 2008 17:03:55 GMT
Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by
xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);
Tue, 2 Dec 2008 18:03:54 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 2 Dec 2008 18:03:50 +0100
Message-ID: <7892795E1A87F04CADFCCF41FADD00FC06A3A8CB@xmb-ams-337.emea.cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Issue #16 on 3775bis
Thread-Index: AclUn/Jo/oYdfCw4QZC43Sg0uVPi4w==
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: <charliep@computer.org>
X-OriginalArrivalTime: 02 Dec 2008 17:03:54.0877 (UTC)
FILETIME=[F54D0AD0:01C9549F]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1393; t=1228237435;
x=1229101435; c=relaxed/simple; s=amsdkim1002;
h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
d=cisco.com; i=pthubert@cisco.com;
z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20<pthubert@ci
sco.com> |Subject:=20Issue=20#16=20on=203775bis |Sender:=20;
bh=lIdqwtx1qvMbywpuzZQ/Q8zN5Zx+cTYJqUomgIxXkbg=;
b=OEg1mZQZiytdI6oQkNBWnMt2fLhacass5lqwk6Pg3T/O4XFaw59YxOrfq8
jz3w3eo+ztDeOBa43ct24n6YszL2t7lgwkUs5TdM47R6KPXL82Zh8ziY+m7L
f0/6py5E5Z;
Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass (
sig from cisco.com/amsdkim1002 verified; );
Cc: mext@ietf.org
Subject: [MEXT] Issue #16 on 3775bis
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>,
<mailto:mext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/mext>
List-Post: <mailto:mext@ietf.org>
List-Help: <mailto:mext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>,
<mailto:mext-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: mext-bounces@ietf.org
Errors-To: mext-bounces@ietf.org
Hi Charlie: There was little change to ticket 16 for awhile. The last update on the ticket said: " Vijay Devarapalli <vijay@wichorus.com>om>: - security: The HA defends an address that it does not own so it can not prove it owns it. With SeND, it would just be nonsense for a HA to try and reclaim SeND based addresses when a MN proves ownership on link. Well, if SeND is not being used, does it make sense for the home agent to allow the mobile node to claim its address, until the mobile node de-registers with a secure binding update? What if a misbehaving mobile node on the home link tries to claim the legitimate mobile node's home address while the home agent is defending the address? The proposal to fix this issue is to let the MN use DAD/oDAD over the Home Link with its Home Address. A proxy would defend the address without the O bit, This would modify the existing behavior. For unsolicited neighbor advertisements, the Home Agent sets the 'O' bit. See section 10.4.1. " Vijay is right, I'm asking for a change from 3775; OTOH RFC 3775 is in contradiction with RFC 4861 (7.2.8. Proxy Neighbor Advertisements) that states clearly that "All solicited proxy Neighbor Advertisement messages MUST have the Override flag set to zero." So what's best, maintain a debatable choice made in 3775 or comply with base ND rules? Pascal _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext
- [MEXT] Issue #16 on 3775bis Pascal Thubert (pthubert)