Re: [MEXT] Finishing RFC 3775bis

Suresh Krishnan <suresh.krishnan@ericsson.com> Wed, 06 October 2010 19:42 UTC

Return-Path: <suresh.krishnan@ericsson.com>
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 AC7BF3A7111 for <mext@core3.amsl.com>; Wed, 6 Oct 2010 12:42:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.514
X-Spam-Level:
X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 STrCKKjZPWKf for <mext@core3.amsl.com>; Wed, 6 Oct 2010 12:42:11 -0700 (PDT)
Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 6F5D23A7074 for <mext@ietf.org>; Wed, 6 Oct 2010 12:42:11 -0700 (PDT)
Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id o96JwWIg032124; Wed, 6 Oct 2010 14:58:35 -0500
Received: from [142.133.10.113] (147.117.20.213) by eusaamw0711.eamcs.ericsson.se (147.117.20.179) with Microsoft SMTP Server id 8.2.234.1; Wed, 6 Oct 2010 15:42:59 -0400
Message-ID: <4CACD0EF.2010603@ericsson.com>
Date: Wed, 06 Oct 2010 15:41:35 -0400
From: Suresh Krishnan <suresh.krishnan@ericsson.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20100411)
MIME-Version: 1.0
To: "charliep@computer.org" <charliep@computer.org>
References: <BF345F63074F8040B58C00A186FCA57F1F68025E4E@NALASEXMB04.na.qualcomm.com> <BF345F63074F8040B58C00A186FCA57F1F6826E7BD@NALASEXMB04.na.qualcomm.com> <4CA12C64.1090606@computer.org>
In-Reply-To: <4CA12C64.1090606@computer.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "mext@ietf.org" <mext@ietf.org>
Subject: Re: [MEXT] Finishing RFC 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/mail-archive/web/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>
X-List-Received-Date: Wed, 06 Oct 2010 19:42:12 -0000

Hi Charlie,
   I am happy with the resolution for issue #13 and I think the document 
is ready to go forward on the publication process.

Thanks
Suresh

On 10-09-27 07:44 PM, Charles E. Perkins wrote:
> Hello folks,
> 
> One of the new requirements for rfc3775bis is a section
> detailing the changes from RFC 3775.  Here's what I wrote
> up.  If I forgot one, please remind me and I will
> add it.  It's quite painful to go through rfcdiff, yow.
> The numbers are the issue numbers from:
> 	http://trac.tools.ietf.org/wg/mext/trac/report/6
> 
> ===========================================================
> 
> #1 	Last Accepted SQN [Ahmad Muhanna] 	
> 
> 	Solution: specify that the mobile node update its binding
> 	sequence number to match the sequence number given in the
> 	Binding Acknowledgement (if the Binding Acknowledgement
> 	correctly passes authentication and the status is 135
> 	(Sequence Number out of window).
> 
> 
> #4 	Remove references to site-local addresses [George Tsirtsis] 	
> 
> 	fixed.
> 
> #5 	Wrong protocol number used in discussion about checksum
> 		pseudo-header: 	
> 
> 	fixed.
> 
> #8 	Application using the care-of address [Julien Laganier]
> 
> 	Cite IPv6 Socket API for Source Address Selection [RFC5014].
> 
> #10 	The usage of "HA lifetime" [Ryuji Wakikawa] 	
> 
> 	The mobile node SHOULD store the list of home agents for later
> 	use in case the home agent currently managing the mobile node's
> 	care-of address forwarding should become unavailable.
> 
> #11 	De-registration when returning home [Vijay Devarapalli] 	
> 
> 	To be able to send and receive packets using its home address
> 	from the home link, the mobile node MUST send a Binding Update to
> 	its home agent to instruct its home agent to no longer intercept
> 	or tunnel packets for it. Until the mobile node sends such a
> 	de-registration Binding Update, it MUST NOT attempt to send and
> 	receive packets using its home address from the home link.
> 
> 
> #12 	BErr sent by HA too, not only by CN [Alexandru Petrescu]
> 
> 	Fixed.
>   	
> #13 	Home Link Detection [Suresh Krishnan] 	
> 
> 	Proposal: add new section [11.5.2] for Home Link Detection,
> 	drawing on Internet Draft draft-krishnan-mext-hld.
> 
> #14 	References to Bootstrapping [Vijay Devarapalli] 	
> 
> 	Cited "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026
> 
> #17 	Multi-homed mobile node can cause routing loop between
> 		home agents [Benjamin Lim]
> 
> 	Added advisory security considerations in section 15.1, to
> 	highlight risk of routing loop among HAs (e.g., in 3GPP):
> 
> 	A malicious mobile node associated to multiple home agents
> 	could create a routing loop amongst them. This would happen
> 	when a mobile node binds one home address located on a first
> 	home agent to another home address on a second home agent.
> 
> #18 	Subject: Issues regarding Home Address Option & ICMP /
> 						Binding errors 	
> 						[Fabian Mauchle]
> 
> 	Proposal: Use the value in the Next Header field {50 (ESP),
> 	51 (AH), 135 (Mobility Header)} to determine, if a Binding
> 	Cache entry is required.
> 
> 	Proposal: To avoid spoofing, add to the first paragraph in
> 	11.3.6: If the source of the ICMP error message is a Home
> 	Agent, it MUST be ignored.
> 
> 	Proposal: If the Binding Error Message was sent by the Home
> 	Agent, the Mobile Node SHOULD send a Binding Update to the
> 	Home Agent according to Section 11.7.1.
> 	
> 
> #19 	BU de-registration race condition [Kilian Weniger] 	
> 
> 	Problem arises if de-registration arrives at Home Agent
> 	before an immediately preceding Binding Update.
> 
> 	Solution: Home Agent defers BCE removal after sending
> 	the Binding Acknowledgement.
> 
> #6 	Minor editorial corrections and updates 	
> 
> NOT done:
> #3 	BRR, BErr are sent by HA too, not only by CN
> 					[Alexandru Petrescu] 	
> #7 	DSMIPv6 BU format and RFC 3775 [Tero Kauppinen] 	
> #9 	Simultaneous Mobility [Ashutosh Dutta] 	
> #15 	BRR sent by HA too, not only by CN [Ahmad Muhanna] 	
> #16 	HA behaviour upon MN returning Home [Pascal Thubert] 	
> 
> 
> ===========================================================
> 
> Regards,
> Charlie P.
> _______________________________________________
> MEXT mailing list
> MEXT@ietf.org
> https://www.ietf.org/mailman/listinfo/mext