Re: [MEXT] Finishing RFC 3775bis

"Laganier, Julien" <julienl@qualcomm.com> Wed, 06 October 2010 20:19 UTC

Return-Path: <julienl@qualcomm.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 6605A3A71F4 for <mext@core3.amsl.com>; Wed, 6 Oct 2010 13:19:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.537
X-Spam-Level:
X-Spam-Status: No, score=-106.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 Gp8Gu2zmOLLX for <mext@core3.amsl.com>; Wed, 6 Oct 2010 13:18:58 -0700 (PDT)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id CE8A03A720A for <mext@ietf.org>; Wed, 6 Oct 2010 13:18:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1286396399; x=1317932399; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20<julienl@qualcomm.com> |To:=20Suresh=20Krishnan=20<suresh.krishnan@ericsson.com> ,=20"charliep@computer.org"=0D=0A=09<charliep@computer.or g>|CC:=20"mext@ietf.org"=20<mext@ietf.org>|Date:=20Wed, =206=20Oct=202010=2013:19:54=20-0700|Subject:=20RE:=20[ME XT]=20Finishing=20RFC=203775bis|Thread-Topic:=20[MEXT]=20 Finishing=20RFC=203775bis|Thread-Index:=20ActljrnXKwHsFix 6RkWYQlw7RZxsYwABN6Nw|Message-ID:=20<BF345F63074F8040B58C 00A186FCA57F29EDEA34F8@NALASEXMB04.na.qualcomm.com> |References:=20<BF345F63074F8040B58C00A186FCA57F1F68025E4 E@NALASEXMB04.na.qualcomm.com>=0D=0A=09<BF345F63074F8040B 58C00A186FCA57F1F6826E7BD@NALASEXMB04.na.qualcomm.com>=0D =0A=09<4CA12C64.1090606@computer.org>=20<4CACD0EF.2010603 @ericsson.com>|In-Reply-To:=20<4CACD0EF.2010603@ericsson. com>|Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=y7xqzbDjwQ4jBOsEnAbd9/D+gK7FD84ZpFerLyM0C5E=; b=juEO14CJELZ6hnSoIFkDmdLJh010k2TPyAmDe/ifIFidfz2E8tTgjNzg 7N3vgHpCBq96agzBg2zaG0Reaoys/fz24/lHlrYyYtr+EuPKuAIowp99W /5q6SHdANazLawb2Q5mOcUbTBzV5KS6Mv3YErlL8UvLKR1+iFlMJXYiXa o=;
X-IronPort-AV: E=McAfee;i="5400,1158,6128"; a="56847767"
Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine02.qualcomm.com with ESMTP; 06 Oct 2010 13:19:59 -0700
X-IronPort-AV: E=Sophos;i="4.57,290,1283756400"; d="scan'208";a="11302835"
Received: from nasanexhub06.na.qualcomm.com ([129.46.134.254]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-MD5; 06 Oct 2010 13:19:59 -0700
Received: from nalasexhc01.na.qualcomm.com (10.47.129.185) by nasanexhub06.na.qualcomm.com (129.46.134.254) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 6 Oct 2010 13:19:59 -0700
Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhc01.na.qualcomm.com ([10.47.129.185]) with mapi; Wed, 6 Oct 2010 13:19:59 -0700
From: "Laganier, Julien" <julienl@qualcomm.com>
To: Suresh Krishnan <suresh.krishnan@ericsson.com>, "charliep@computer.org" <charliep@computer.org>
Date: Wed, 06 Oct 2010 13:19:54 -0700
Thread-Topic: [MEXT] Finishing RFC 3775bis
Thread-Index: ActljrnXKwHsFix6RkWYQlw7RZxsYwABN6Nw
Message-ID: <BF345F63074F8040B58C00A186FCA57F29EDEA34F8@NALASEXMB04.na.qualcomm.com>
References: <BF345F63074F8040B58C00A186FCA57F1F68025E4E@NALASEXMB04.na.qualcomm.com> <BF345F63074F8040B58C00A186FCA57F1F6826E7BD@NALASEXMB04.na.qualcomm.com> <4CA12C64.1090606@computer.org> <4CACD0EF.2010603@ericsson.com>
In-Reply-To: <4CACD0EF.2010603@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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 20:19:00 -0000

Just for clarification: We will request to IESG publication of the next version of the document that fixes remaining IDnits. 

--julien

> -----Original Message-----
> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of
> Suresh Krishnan
> Sent: Wednesday, October 06, 2010 12:42 PM
> To: charliep@computer.org
> Cc: mext@ietf.org
> Subject: Re: [MEXT] Finishing RFC 3775bis
> 
> 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
> 
> _______________________________________________
> MEXT mailing list
> MEXT@ietf.org
> https://www.ietf.org/mailman/listinfo/mext