From exim@www1.ietf.org Mon Mar 1 00:23:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05304 for ; Mon, 1 Mar 2004 00:23:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxftD-0004ag-O9 for mip4-archive@odin.ietf.org; Mon, 01 Mar 2004 00:22:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i215MpfO017642 for mip4-archive@odin.ietf.org; Mon, 1 Mar 2004 00:22:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxftD-0004aT-Er for mip4-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 00:22:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05249 for ; Mon, 1 Mar 2004 00:22:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxftB-0001lG-00 for mip4-web-archive@ietf.org; Mon, 01 Mar 2004 00:22:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxfsJ-0001c7-00 for mip4-web-archive@ietf.org; Mon, 01 Mar 2004 00:21:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxfrP-0001Sf-00 for mip4-web-archive@ietf.org; Mon, 01 Mar 2004 00:20:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxfrR-0004NO-1g; Mon, 01 Mar 2004 00:21:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axfqq-0004GC-JJ for mip4@optimus.ietf.org; Mon, 01 Mar 2004 00:20:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05056 for ; Mon, 1 Mar 2004 00:20:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axfqo-0001Nw-00 for mip4@ietf.org; Mon, 01 Mar 2004 00:20:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axfpq-0001HE-00 for mip4@ietf.org; Mon, 01 Mar 2004 00:19:23 -0500 Received: from mac-0-40-96-34-df-d2.dhcp.ietf59.or.kr ([218.37.226.227] helo=chardonnay.local.levkowetz.com) by ietf-mx with esmtp (Exim 4.12) id 1Axfoq-0001Au-00; Mon, 01 Mar 2004 00:18:21 -0500 Received: from chardonnay ([127.0.0.1] helo=chardonnay.local.levkowetz.com) by chardonnay.local.levkowetz.com with smtp (Exim 3.36 #1 (Debian)) id 1Axfon-0004yI-00; Mon, 01 Mar 2004 06:18:17 +0100 Date: Mon, 1 Mar 2004 06:18:17 +0100 From: Henrik Levkowetz To: mip4@ietf.org, mip6@ietf.org Subject: Re: [Mip4] REVISED: MIPv4/MIPv6-IPv4/IPv6 interaction bar-bof Message-Id: <20040301061817.6bcecbab.henrik@levkowetz.com> In-Reply-To: <20040225023657.260676cd.henrik@levkowetz.com> References: <20040225023657.260676cd.henrik@levkowetz.com> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Signature=_Mon__1_Mar_2004_06_18_17_+0100_Wobcbpcqzg2MlGYt" Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 --Signature=_Mon__1_Mar_2004_06_18_17_+0100_Wobcbpcqzg2MlGYt Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit I've gotten a bit of pusback about the early hour of the bar-bof, so the time has been changed: REVISED Bar-bof details: Monday evening 22:00 - in the seating area outside Emerald. Possibly we can use Emerald if more people turn up than the area can hold. Henrik Wednesday 25 February 2004, Henrik Levkowetz wrote: > > Proposal of a bar-bof > --------------------- > > With the coming (we hope) of heterogenous deployment of IPv4 and IPv6 > access and transport networks, and Mobile Nodes with MIPv4 and/or MIPv6 > capability and IPv4 and/or IPv6 stacks, the question has been raised > of how to best run Mobile IP in such circumstances, and some solutions > has been proposed. > > The "trivial cases" of MIP4 carrying IPv4 in an all-IPv4 network, and > MIP6 carrying IPv6 in an all-IPv6 network are covered in the MIPv4 and > MIPv6 standards. But by one way of counting, that still leaves about 6 > combinations (14 if you count NAT-PT versions) which may occur in > practice which are not covered by the current standards. A number of > drafts (some mentioned below) has been written, proposing solutions > to some of these cases. > > Some cases may be handled without any additional MIP work if other > transition mechanisms such as e.g. ISATAP is available, but as a Mobile > Node may be expected to come across all conceivable kinds of visited > networks, it cannot rely on any particular other transition mechanism > being in place. > > Below is a list of possible combinations of Host IP stack version, MIP > client/agent version and transport network IP version, followed by a > short summary of my understanding of where the current and proposed > solutions fit in. There exist 8 similar combinations using NAT-PT > which are not explicitly listed here. > > Which solutions will be needed? Which should we work on? How much > interest does this have currently? > > We plan to hold a bar-bof in Seoul, to see how many show up, and what > kind of interest there is in this subject. Place will be announced > on the lists Monday March 1st, and in the MIP4 and MIP6 sessions. > > Henrik > > > > Table of MIP4/6-IP4/6 combinations: > =================================== > > # MN's MIP Access Transpt Short description > IP-stack Client Net & HA if. > --- -------- ------ ------ ------- ----------------- > 1 IPv4 MIP v4 IP v4 v4 "native MIPv4" > 2 IPv6 " " v4 "IPv6 in MIPv4" > > 3 IPv4 MIP v6 " v4 "IPv4 in MIPv6 over IPv4" > 4 IPv6 " " v4 "MIPv6 over IPv4" > > 5 IPv4 MIP v4 IP v6 v6 "MIPv4 over IPv6" > 6 IPv6 " " v6 "IPv6 in MIPv4 over IPv6" > > 7 IPv4 MIP v6 " v6 "IPv4 in MIPv6" > 8 IPv6 " " v6 "native MIPv6" > --- -------- ------ ------ ------- ----------------- > > Variant 1 is the native IP/MIP combination for v4 > > Variant 2 would be supported by the MIPv4 signalling extensions proposed in > draft-tsirtsis-v4v6-mipv4-00.txt > > Variant 5 is known to be supported by an experimental thesis implementation > and is fairly simple > > Variant 6 is known to be supported by an experimental thesis implementation > and is fairly simple > > Variant 7 would be supported by the MIPv6 signalling extensions proposed in > draft-soliman-v4v6-mipv4-00.txt > > Variant 8 is the native IP/MIP combination for v6 > > > > --Signature=_Mon__1_Mar_2004_06_18_17_+0100_Wobcbpcqzg2MlGYt Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAQseZeVhrtTJkXCMRAh3cAJ0emUOyIq9apB+g/79c+xNmwFtf5ACdFujZ h/nMne1IpJsTMwfshW0rEd0= =Ucpc -----END PGP SIGNATURE----- --Signature=_Mon__1_Mar_2004_06_18_17_+0100_Wobcbpcqzg2MlGYt-- -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Tue Mar 2 00:31:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03133 for ; Tue, 2 Mar 2004 00:31:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay2UH-0007OG-45 for mip4-archive@odin.ietf.org; Tue, 02 Mar 2004 00:30:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i225UbGF028407 for mip4-archive@odin.ietf.org; Tue, 2 Mar 2004 00:30:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay2UG-0007O6-T9 for mip4-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 00:30:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03102 for ; Tue, 2 Mar 2004 00:30:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay2UE-0006R6-00 for mip4-web-archive@ietf.org; Tue, 02 Mar 2004 00:30:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay2T9-0006J2-00 for mip4-web-archive@ietf.org; Tue, 02 Mar 2004 00:29:28 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ay2Sk-0006Ay-00 for mip4-web-archive@ietf.org; Tue, 02 Mar 2004 00:29:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay2Sm-00074E-CT; Tue, 02 Mar 2004 00:29:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay2Rz-00072k-0r for mip4@optimus.ietf.org; Tue, 02 Mar 2004 00:28:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03029 for ; Tue, 2 Mar 2004 00:28:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay2Rw-000697-00 for mip4@ietf.org; Tue, 02 Mar 2004 00:28:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay2R6-00063h-00 for mip4@ietf.org; Tue, 02 Mar 2004 00:27:21 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Ay2QY-0005vg-00 for mip4@ietf.org; Tue, 02 Mar 2004 00:26:46 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 01 Mar 2004 21:37:41 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i225QFY6010289; Mon, 1 Mar 2004 21:26:16 -0800 (PST) Received: from kleung-w2k01.cisco.com (sjc-vpn1-1091.cisco.com [10.21.100.67]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQU38204; Mon, 1 Mar 2004 21:26:13 -0800 (PST) Message-Id: <4.3.2.7.2.20040301151757.02f79038@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 01 Mar 2004 21:26:12 -0800 To: sami.vaarala@iki.fi From: Kent Leung Subject: Re: [Mip4] Negotiating maximum packet size (draft-vaarala-mip4-fragmtu-00) Cc: mip4@ietf.org In-Reply-To: <1077651874.403ba9a2c18fc@webmail2.hut.fi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Hi Sami. Interesting problem of dropping packets with DF bit unset. Haven't experience that. The ICMP filter is common. Some questions below. 1) Why GRE encap not supported? Seems like adding a few words would allow that since there's no technical hurdle to cover supported encapsulation modes. 2) Does it make sense for FA to advertise the Frag-MTU-Pref value so the MN can send that info to the HA in a protected manner? 3) Not clear how the MN's IP stack use this effective MTU? Is the IP MTU set to this value to tune the TCP MSS negotiation between MN and CN? IMHO, this is the most important objective so Tunnel MTU Discovery is not needed for obtain optimal MTU size. 4) If effective MTU is not related to IP MTU to affect TCP MSS, then we will still have the black hole problem between CN and MN due to ICMP filters. 5) If effective MTU is used for TCP MSS, then does it make sense to re-negotiate on each registration? Should this be accomplished only in the initial registration? How would active TCP session deal with changing IP MTU? 6) Let's say that MN has 2 interfaces, one that use IP-in-IP and the other use UDP. Initially, MN roams to a network that uses IP-in-IP. TCP sessions are started with CNs. Then MN roams to network that requires UDP. We would be back at not having optimum MSS. 7) Seems like the lowest common denominator is the effective MTU of the lowest MTU among UDP, IPinIP, GRE? And if one enables IPSec too, the optimal MTU shrinks more. Just wondering at the end of the day, it may be just easier to say regardless which tunneling method is used, go with MTU size 1400 for one size fits all? 8) Is it expected that the HA which receives the effective MTU will set the tunnel mtu soft state accordingly for tunnel mtu discovery? So if tunnel mtu discovery is enabled on the tunnel between HA and CoA, then soft state is set. If tunnel mtu discovery is disabled, the effective mtu is not used for forwarding MN traffic toward CoA? General question is how is the effective MTU linked to tunnel MTU Discovery? 9) Though this draft seems to say that the HA processes the effective MTU by ensuring that all encapsulated traffic (original packet is fragmented if too big) are within the size of effective MTU, when the DF bit is unset. In this case, when DF bit is set, HA will send ICMP unreachable to source. This message may be filtered. Kent At 09:44 PM 2/24/2004 +0200, sami.vaarala@iki.fi wrote: >Hi, > >Here's a short draft on how the MN and the HA can negotiate the >maximum packet size used for IP-IP or IP-over-UDP encapsulation. > > http://www.ietf.org/internet-drafts/draft-vaarala-mip4-fragmtu-00.txt > >Although RFC 3519 already specifies that you first fragment and >then encapsulate, the maximum size of encapsulated UDP packets >is implementation specific (most likely link MTU). > >We've run into some configurations where a box is configured to >drop packets larger than a certain size even when DF is unset. >Limiting packet size helped, but cannot be controlled using a >policy in the HA (for instance). The intent of the mechanism in >the draft is to make this possible. > >Has anyone else run into similar issues in practice? Any >feedback is appreciated. > >Best, > >-Sami >-- >Sami Vaarala >http://www.hut.fi/~svaarala > >-- >Mip4 mailing list >Mip4@ietf.org >https://www.ietf.org/mailman/listinfo/mip4 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Tue Mar 2 06:49:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04635 for ; Tue, 2 Mar 2004 06:49:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay8O5-0001fY-0I for mip4-archive@odin.ietf.org; Tue, 02 Mar 2004 06:48:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i22BmajA006412 for mip4-archive@odin.ietf.org; Tue, 2 Mar 2004 06:48:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay8O4-0001fL-Qv for mip4-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 06:48:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04632 for ; Tue, 2 Mar 2004 06:48:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay8O0-0000su-00 for mip4-web-archive@ietf.org; Tue, 02 Mar 2004 06:48:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay8N5-0000ll-00 for mip4-web-archive@ietf.org; Tue, 02 Mar 2004 06:47:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ay8MW-0000eq-00 for mip4-web-archive@ietf.org; Tue, 02 Mar 2004 06:47:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay8MX-0001Pb-Kx; Tue, 02 Mar 2004 06:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay8MA-0001P7-Bb for mip4@optimus.ietf.org; Tue, 02 Mar 2004 06:46:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04562 for ; Tue, 2 Mar 2004 06:46:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay8M6-0000dc-00 for mip4@ietf.org; Tue, 02 Mar 2004 06:46:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay8LB-0000W3-00 for mip4@ietf.org; Tue, 02 Mar 2004 06:45:38 -0500 Received: from nuoli.com ([212.182.218.5]) by ietf-mx with smtp (Exim 4.12) id 1Ay8Ki-0000O4-00 for mip4@ietf.org; Tue, 02 Mar 2004 06:45:08 -0500 Received: (qmail 4683 invoked by uid 89); 2 Mar 2004 11:44:04 -0000 Message-ID: <20040302114404.4682.qmail@nuoli.com> References: <4.3.2.7.2.20040301151757.02f79038@mira-sjcm-2.cisco.com> In-Reply-To: <4.3.2.7.2.20040301151757.02f79038@mira-sjcm-2.cisco.com> From: sami.vaarala@iki.fi To: Kent Leung Cc: sami.vaarala@iki.fi, mip4@ietf.org Date: Tue, 02 Mar 2004 13:44:04 +0200 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip4] Re: Negotiating maximum packet size (draft-vaarala-mip4-fragmtu-00) Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Kent, Thanks for the comments, some responses and questions below. > 1) Why GRE encap not supported? Seems like adding a few words would > allow that since there's no technical hurdle to cover supported > encapsulation modes. No particular reason - this draft just documents what we thought would solve our most immediate problems. GRE is no different, except that you may run protocols over GRE that don't support the notion of fragmentation. (Of course IP over GRE will work just fine.) > 2) Does it make sense for FA to advertise the Frag-MTU-Pref value so > the MN can send that info to the HA in a protected manner? I'm not sure what you mean here, can you elaborate? The preference is protected using MN-HA authenticator? And the MN and HA are configured with their respective values, so they don't need input from network. > 3) Not clear how the MN's IP stack use this effective MTU? Is the IP MTU > set to this value to tune the TCP MSS negotiation between MN and CN? > IMHO, this is the most important objective so Tunnel MTU Discovery is > not needed for obtain optimal MTU size. Well, that's one thing you can do, and should do (if possible). You can also do MSS rewriting and other such things. > 4) If effective MTU is not related to IP MTU to affect TCP MSS, then > we will still have the black hole problem between CN and MN due > to ICMP filters. That's true - but this would also be the case if the MN was at home and trying to communicate with the MN. The intent of the mechanism in the draft is to solve the case where the MN is away, and the route between the MN and the HA is poor - although a connection from the MN home network would work just fine. (Tweaking the TCP MSS for initiated connections so that it will work when initiated from the home network is outside the MIP4 scope - there isn't necessarily even a registration involved if the MN boots up at home.) > 5) If effective MTU is used for TCP MSS, then does it make sense to > re-negotiate on each registration? Should this be accomplished > only in the initial registration? How would active TCP session > deal with changing IP MTU? If DF was set, the MIP code could simply manufacture an ICMP back to the stack with packet too big (i.e. a local ICMP). There are other possibilities, though. > 6) Let's say that MN has 2 interfaces, one that use IP-in-IP and the > other use UDP. Initially, MN roams to a network that uses IP-in-IP. > TCP sessions are started with CNs. Then MN roams to network > that requires UDP. We would be back at not having optimum > MSS. Yes, that's true. But if you do MSS tweaks (which are local matters anyway), you may take the maximum packet size and subtract the maximum overhead (UDP) when determining your offered MSS? > 7) Seems like the lowest common denominator is the effective MTU > of the lowest MTU among UDP, IPinIP, GRE? And if one enables > IPSec too, the optimal MTU shrinks more. Just wondering at the > end of the day, it may be just easier to say regardless which > tunneling method is used, go with MTU size 1400 for one size fits > all? That's what we've done in our previous product version, but actually 1400 is too large, at least for some specific networks (it's precisely the value we ran into problems with :-). Choosing a value that will work for sure is black magic as the routers where this is a problem are clearly broken in any event. > 8) Is it expected that the HA which receives the effective MTU will > set the tunnel mtu soft state accordingly for tunnel mtu discovery? > So if tunnel mtu discovery is enabled on the tunnel between HA > and CoA, then soft state is set. If tunnel mtu discovery is disabled, > the effective mtu is not used for forwarding MN traffic toward CoA? > General question is how is the effective MTU linked to tunnel MTU > Discovery? The HA and the MN should do whatever they do with plain RFC 2003 / RFC 3519. There is no difference, except that the tunnel MTU may occasionally change. To overcome the IP-IP vs. IP-over-UDP difference, the tunnel MTU can be taken to be the worst case, but that's an implementation decision IMO. Other than that, the tunnel MTU should change extremely rarely (e.g. HA is reconfigured). > 9) Though this draft seems to say that the HA processes the effective MTU > by ensuring that all encapsulated traffic (original packet is > fragmented if > too big) are within the size of effective MTU, when the DF bit is unset. > In this case, when DF bit is set, HA will send ICMP unreachable to > source. This message may be filtered. Yes, if we have a filter between HA and CN we're in trouble, unless we stop honoring the DF bit (which is tempting after dealing with a number of black hole problems..:). I don't think there is a way around this problem. However, we don't have to rely on ICMP between the MN and the HA, which is a larger problem, because the MN moves around in whatever networks that are out there. Best, -Sami -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Wed Mar 3 01:59:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07227 for ; Wed, 3 Mar 2004 01:59:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQKv-00059Q-JX for mip4-archive@odin.ietf.org; Wed, 03 Mar 2004 01:58:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i236wXqQ019796 for mip4-archive@odin.ietf.org; Wed, 3 Mar 2004 01:58:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQKv-00059D-DL for mip4-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 01:58:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07217 for ; Wed, 3 Mar 2004 01:58:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyQKs-0003mR-00 for mip4-web-archive@ietf.org; Wed, 03 Mar 2004 01:58:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyQK1-0003cR-00 for mip4-web-archive@ietf.org; Wed, 03 Mar 2004 01:57:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyQJP-0003Rt-00 for mip4-web-archive@ietf.org; Wed, 03 Mar 2004 01:56:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQJR-0004h0-3c; Wed, 03 Mar 2004 01:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQIq-0004b9-PJ for mip4@optimus.ietf.org; Wed, 03 Mar 2004 01:56:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06995 for ; Wed, 3 Mar 2004 01:56:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyQIn-0003Oq-00 for mip4@ietf.org; Wed, 03 Mar 2004 01:56:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyQI1-0003DB-00 for mip4@ietf.org; Wed, 03 Mar 2004 01:55:34 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AyQH0-0002nj-00 for mip4@ietf.org; Wed, 03 Mar 2004 01:54:30 -0500 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i236rwY6006515; Tue, 2 Mar 2004 22:53:59 -0800 (PST) Received: from kleung-w2k01.cisco.com (sjc-vpn1-464.cisco.com [10.21.97.208]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQV46008; Tue, 2 Mar 2004 22:53:56 -0800 (PST) Message-Id: <4.3.2.7.2.20040302135940.02f7f2e0@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 02 Mar 2004 22:53:55 -0800 To: sami.vaarala@iki.fi From: Kent Leung Subject: Re: [Mip4] Re: Negotiating maximum packet size (draft-vaarala-mip4-fragmtu-00) Cc: sami.vaarala@iki.fi, mip4@ietf.org In-Reply-To: <20040302114404.4682.qmail@nuoli.com> References: <4.3.2.7.2.20040301151757.02f79038@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040301151757.02f79038@mira-sjcm-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Generally, I like the idea, and like to extend it a bit further to deal with the broader problem of avoiding fragmentations which is introduced by the MIP tunnel for roaming MNs. More comments below. At 01:44 PM 3/2/2004 +0200, sami.vaarala@iki.fi wrote: GRE is no different, except that >you may run protocols over GRE that don't support the notion of >fragmentation. (Of course IP over GRE will work just fine.) Yes, I implied IP over GRE. >>2) Does it make sense for FA to advertise the Frag-MTU-Pref value so >> the MN can send that info to the HA in a protected manner? >I'm not sure what you mean here, can you elaborate? The preference >is protected using MN-HA authenticator? And the MN and HA are >configured with their respective values, so they don't need input >from network. In this case, MN is using an FA. When MN learns about an FA, the FA advertises an effective MTU to use to connect to any HA. MN adds that to the extension in the RRQ. This way, the info is protected by the MN-HA AE. The current method in draft specifies the extension is after MN-HA AE. Just a thought if it makes sense to follow the same model as GRE tunnel support using G bit. >>3) Not clear how the MN's IP stack use this effective MTU? Is the IP MTU >> set to this value to tune the TCP MSS negotiation between MN and CN? >> IMHO, this is the most important objective so Tunnel MTU Discovery is >> not needed for obtain optimal MTU size. > >Well, that's one thing you can do, and should do (if possible). You can >also do MSS rewriting and other such things. OK. This would be very useful. >>4) If effective MTU is not related to IP MTU to affect TCP MSS, then >> we will still have the black hole problem between CN and MN due >> to ICMP filters. > >That's true - but this would also be the case if the MN was at home >and trying to communicate with the MN. The intent of the mechanism >in the draft is to solve the case where the MN is away, and the route >between the MN and the HA is poor - although a connection from the MN >home network would work just fine. (Tweaking the TCP MSS for initiated >connections so that it will work when initiated from the home network is >outside the MIP4 scope - there isn't necessarily even a registration >involved if the MN boots up at home.) But it's when MN is roaming which requires tunnels that introduces the need to reduce the MTU size. Here's where I see the differences. Given all things equal, an IP payload size of 1500 can reach MN/CN without fragmentation. a) Let's say MN is at home. MN has interface with MTU of 1500 and uses that to negotiate MSS with CN. There's no need for fragmentation. b) MN is roaming. MN has interface with MTU of 1500. But MIP introduces a tunnel in the path between MN and CN. Packets with 1500B must be fragmented. The draft specifies the maximum size of the encapsulated packets. But traffic between MN and CN will still suffer from the issue of "path MTU discovery relies on a number of assumptions regarding ICMP processing in the intervening routers, and is often problematic in the real world", right? My idea is to use this effective MTU to set the MN's IP MTU so MN/CN communications do not need to be fragmented. Currently, there are CNs which will automatically set DF bit. And there are ICMP filters. This results in the need to disable Tunnel MTU Discovery on the HA since no one knows who the MN will be contacting. >>5) If effective MTU is used for TCP MSS, then does it make sense to >> re-negotiate on each registration? Should this be accomplished >> only in the initial registration? How would active TCP session >> deal with changing IP MTU? > >If DF was set, the MIP code could simply manufacture an ICMP back to the >stack with packet too big (i.e. a local ICMP). There are other >possibilities, though. When DF bit set, ICMP to the source may be filtered. For the local case, won't be a problem. >>6) Let's say that MN has 2 interfaces, one that use IP-in-IP and the >> other use UDP. Initially, MN roams to a network that uses IP-in-IP. >> TCP sessions are started with CNs. Then MN roams to network >> that requires UDP. We would be back at not having optimum >> MSS. > >Yes, that's true. But if you do MSS tweaks (which are local matters >anyway), you may take the maximum packet size and subtract the maximum >overhead (UDP) when determining your offered MSS? Yes, I was pointing out that effective IP MTU may determined not just by the encapsulation method of the registration. >>7) Seems like the lowest common denominator is the effective MTU >> of the lowest MTU among UDP, IPinIP, GRE? And if one enables >> IPSec too, the optimal MTU shrinks more. Just wondering at the >> end of the day, it may be just easier to say regardless which >> tunneling method is used, go with MTU size 1400 for one size fits >> all? > >That's what we've done in our previous product version, but actually >1400 is too large, at least for some specific networks (it's precisely >the value we ran into problems with :-). Choosing a value that will >work for sure is black magic as the routers where this is a problem >are clearly broken in any event. Agree. 1300 instead? :) Finding the optimal IP MTU without the aid of ICMP is guesswork. But that is what we face today if DF bit is set in the packets. >>8) Is it expected that the HA which receives the effective MTU will >> set the tunnel mtu soft state accordingly for tunnel mtu discovery? >> So if tunnel mtu discovery is enabled on the tunnel between HA >> and CoA, then soft state is set. If tunnel mtu discovery is disabled, >> the effective mtu is not used for forwarding MN traffic toward CoA? >> General question is how is the effective MTU linked to tunnel MTU >> Discovery? > >The HA and the MN should do whatever they do with plain RFC 2003 / >RFC 3519. There is no difference, except that the tunnel MTU may >occasionally change. To overcome the IP-IP vs. IP-over-UDP >difference, the tunnel MTU can be taken to be the worst case, but >that's an implementation decision IMO. Other than that, the tunnel >MTU should change extremely rarely (e.g. HA is reconfigured). I see the "For instance" wording in determining effective MTU section. :) I had taken the examples too literally in my previous reading. >>9) Though this draft seems to say that the HA processes the effective MTU >> by ensuring that all encapsulated traffic (original packet is >> fragmented if >> too big) are within the size of effective MTU, when the DF bit is unset. >> In this case, when DF bit is set, HA will send ICMP unreachable to >> source. This message may be filtered. > >Yes, if we have a filter between HA and CN we're in trouble, unless >we stop honoring the DF bit (which is tempting after dealing with a >number of black hole problems..:). I don't think there is a way around >this problem. However, we don't have to rely on ICMP between the MN and >the HA, which is a larger problem, because the MN moves around in whatever >networks that are out there. Actually, I see that there's a generic ICMP filter issue regardless if it's between MN and HA or between MN and CN. Solving problem just for MN and HA still forces us to disable Tunnel MTU Discovery since there may be an ICMP filter in the HA/CN section. But if we can set the IP MTU for MN properly, then there is no problem for MN/HA or MN/CN cases? Kent -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Wed Mar 3 05:21:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16163 for ; Wed, 3 Mar 2004 05:21:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyTUn-0008Bj-7z for mip4-archive@odin.ietf.org; Wed, 03 Mar 2004 05:20:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i23AKvam031476 for mip4-archive@odin.ietf.org; Wed, 3 Mar 2004 05:20:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyTUc-0008BL-1J for mip4-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 05:20:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16093 for ; Wed, 3 Mar 2004 05:20:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyTUJ-0000Iu-00 for mip4-web-archive@ietf.org; Wed, 03 Mar 2004 05:20:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyTTO-00009S-00 for mip4-web-archive@ietf.org; Wed, 03 Mar 2004 05:19:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyTSt-0007nZ-00 for mip4-web-archive@ietf.org; Wed, 03 Mar 2004 05:18:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyTSv-00083w-9a; Wed, 03 Mar 2004 05:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyTSf-00083F-OT for mip4@optimus.ietf.org; Wed, 03 Mar 2004 05:18:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16059 for ; Wed, 3 Mar 2004 05:18:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyTSD-0007lh-00 for mip4@ietf.org; Wed, 03 Mar 2004 05:18:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyTRH-0007dY-00 for mip4@ietf.org; Wed, 03 Mar 2004 05:17:20 -0500 Received: from nuoli.com ([212.182.218.5]) by ietf-mx with smtp (Exim 4.12) id 1AyTQP-0007Mx-00 for mip4@ietf.org; Wed, 03 Mar 2004 05:16:25 -0500 Received: (qmail 74073 invoked by uid 89); 3 Mar 2004 10:15:15 -0000 Message-ID: <20040303101515.74072.qmail@nuoli.com> References: <4.3.2.7.2.20040301151757.02f79038@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040301151757.02f79038@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040302135940.02f7f2e0@mira-sjcm-2.cisco.com> In-Reply-To: <4.3.2.7.2.20040302135940.02f7f2e0@mira-sjcm-2.cisco.com> From: sami.vaarala@iki.fi To: Kent Leung Cc: sami.vaarala@iki.fi, mip4@ietf.org Date: Wed, 03 Mar 2004 12:15:15 +0200 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip4] Re: Negotiating maximum packet size (draft-vaarala-mip4-fragmtu-00) Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Kent, Comments below. > Generally, I like the idea, and like to extend it a bit further to deal > with the broader problem of avoiding fragmentations which is introduced > by the MIP tunnel for roaming MNs. Sounds good. The current "problem statement" in the draft is probably a bit too focused. Expanding the scope a bit and writing up a better rationale would be a good thing. >>> 2) Does it make sense for FA to advertise the Frag-MTU-Pref value so >>> the MN can send that info to the HA in a protected manner? >> I'm not sure what you mean here, can you elaborate? The preference >> [...] > In this case, MN is using an FA. > When MN learns about an FA, the FA advertises an effective MTU > to use to connect to any HA. MN adds that to the extension in the > RRQ. This way, the info is protected by the MN-HA AE. The current > method in draft specifies the extension is after MN-HA AE. Just a > thought if it makes sense to follow the same model as GRE tunnel > support using G bit. Ah, I understand. So even though the UDP encapsulation would in this case be between FA and HA, we could use the MN-HA authentication to set things up. Didn't think about that :) This leaves the case where the MN is unaware of MTU negotiation but FA is not. This could work out as follows: FA advertises, MN ignores the advert and sends a normal RRQ. The FA checks the RRQ for an MTU extension, and if none is found, adds one after the MN extension (i.e. falls back to less secure operation). The security implications are not straightforward; off the top of my head: - The HA must be required to ignore any MTU extensions after MN-HA authenticator if one is found within the authenticated extensions. Similar requirement for the MN. - The FA has no way of verifying the HA->MN MTU extension (even when it is within the MN-HA authenticated extensions) - the MN doesn't tell the FA if authentication fails. - For MN->HA direction the FA may be able to trust the MN as it's on the local link (more or less); if the MN sends a deliberately broken authenticator, that too will be detected (in most cases). But the end result is probably better than no authentication at all. > But it's when MN is roaming which requires tunnels that introduces > the need to reduce the MTU size. Here's where I see the differences. > > Given all things equal, an IP payload size of 1500 can reach MN/CN > without fragmentation. > > a) Let's say MN is at home. MN has interface with MTU of 1500 and > uses that to negotiate MSS with CN. There's no need for fragmentation. > b) MN is roaming. MN has interface with MTU of 1500. But MIP > introduces a tunnel in the path between MN and CN. Packets with > 1500B must be fragmented. The draft specifies the maximum size > of the encapsulated packets. But traffic between MN and CN will > still suffer from the issue of "path MTU discovery relies on a number > of assumptions regarding ICMP processing in the intervening routers, > and is often problematic in the real world", right? I see your point, and I agree. We have an ICMP black hole which is not exposed when using MTU of 1500. Any reduction in MTU, for whatever reason (such as MIP tunneling), exposes the problem? > My idea is to use this effective MTU to set the MN's IP MTU so > MN/CN communications do not need to be fragmented. Currently, > there are CNs which will automatically set DF bit. And there are > ICMP filters. This results in the need to disable Tunnel MTU Discovery > on the HA since no one knows who the MN will be contacting. Ok, I see what you mean. I guess the most difficult part of doing that is the CN; if we don't use ICMP, we have no way of telling the CN to lower its MTU - except transport specific mechanisms such as TCP MSS? Even so, getting the TCP MSS right from the MN's side would go a long way in improving practical robustness of the connection. > Yes, I was pointing out that effective IP MTU may determined not just by > the encapsulation method of the registration. I agree; as you point out below, it also depends on presence of IPsec and other things. > Agree. 1300 instead? :) Finding the optimal IP MTU without the > aid of ICMP is guesswork. But that is what we face today if DF bit > is set in the packets. 1300 seems to work, in this particular case :) If one were thinking primarily about getting packets through, the most optimal solution is probably to use a conservative MTU for the tunneled packets, use DF=0 in the encapsulated header, and ignore incoming DF-bit. If combined with TCP MSS and MN IP MTU tweaking this doesn't result in too many unoptimally fragmented packets. But this is rather ugly and affects path MTU discovery of upper layers. > Actually, I see that there's a generic ICMP filter issue regardless if > it's between MN and HA or between MN and CN. Solving problem just > for MN and HA still forces us to disable Tunnel MTU Discovery since there > may be an ICMP filter in the HA/CN section. But if we can set the IP MTU > for MN properly, then there is no problem for MN/HA or MN/CN cases? I can see how this solves the MN->CN case, but what about CN->MN? Were you primarily thinking of TCP? Best, -Sami -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Wed Mar 3 21:36:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18428 for ; Wed, 3 Mar 2004 21:36:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyiiY-0000Jq-9Y for mip4-archive@odin.ietf.org; Wed, 03 Mar 2004 21:36:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i242aACc001220 for mip4-archive@odin.ietf.org; Wed, 3 Mar 2004 21:36:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyiiY-0000Jb-4Z for mip4-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 21:36:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18342 for ; Wed, 3 Mar 2004 21:36:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyiiV-0004ox-00 for mip4-web-archive@ietf.org; Wed, 03 Mar 2004 21:36:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyihT-0004YL-00 for mip4-web-archive@ietf.org; Wed, 03 Mar 2004 21:35:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyigS-0004H5-00 for mip4-web-archive@ietf.org; Wed, 03 Mar 2004 21:34:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyigU-0008FA-P7; Wed, 03 Mar 2004 21:34:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayify-000877-20 for mip4@optimus.ietf.org; Wed, 03 Mar 2004 21:33:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18034 for ; Wed, 3 Mar 2004 21:33:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayifv-00044h-00 for mip4@ietf.org; Wed, 03 Mar 2004 21:33:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayiet-0003nJ-00 for mip4@ietf.org; Wed, 03 Mar 2004 21:32:23 -0500 Received: from [203.177.23.162] (helo=eazix-win2ks0.eazix.com) by ietf-mx with esmtp (Exim 4.12) id 1Ayidv-0003LT-00 for mip4@ietf.org; Wed, 03 Mar 2004 21:31:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 4 Mar 2004 10:47:32 +0800 Message-ID: Thread-Topic: QoS Documents Thread-Index: AcQBkwWjuYFA81ppQGqkEyyXJr3RQg== From: "Rodel Miguel" To: Content-Transfer-Encoding: quoted-printable Subject: [Mip4] QoS Documents Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, Could someone please point me to the latest QoS papers/drafts/rfc/wg for = MIPv4? I'm currently gathering resources for my research topic. =20 Thank you very much. Best Regards, Rodel -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Thu Mar 11 10:50:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07644 for ; Thu, 11 Mar 2004 10:50:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1SRR-0004qv-Tj for mip4-archive@odin.ietf.org; Thu, 11 Mar 2004 10:49:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2BFnnEn018648 for mip4-archive@odin.ietf.org; Thu, 11 Mar 2004 10:49:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1SRR-0004qh-8F for mip4-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 10:49:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07629 for ; Thu, 11 Mar 2004 10:49:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1SRO-0003Lm-00 for mip4-web-archive@ietf.org; Thu, 11 Mar 2004 10:49:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1SQS-0003DU-00 for mip4-web-archive@ietf.org; Thu, 11 Mar 2004 10:48:49 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1SPh-00034s-00 for mip4-web-archive@ietf.org; Thu, 11 Mar 2004 10:48:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1SPg-0004hk-QA; Thu, 11 Mar 2004 10:48:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0eyd-00020Z-3A for mip4@optimus.ietf.org; Tue, 09 Mar 2004 06:00:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20309 for ; Tue, 9 Mar 2004 06:00:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0eyZ-000781-00 for mip4@ietf.org; Tue, 09 Mar 2004 06:00:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0exd-0006wk-00 for mip4@ietf.org; Tue, 09 Mar 2004 05:59:46 -0500 Received: from myra.general.services.metu.edu.tr ([144.122.144.147]) by ietf-mx with esmtp (Exim 4.12) id 1B0ex5-0006kV-00; Tue, 09 Mar 2004 05:59:11 -0500 Received: from metu.edu.tr (ee-167-166.eee.metu.edu.tr [144.122.167.166]) by myra.general.services.metu.edu.tr (8.11.7/8.11.7) with ESMTP id i29AwS717213; Tue, 9 Mar 2004 12:58:29 +0200 (EET) Message-ID: <404DA29F.6080901@metu.edu.tr> Date: Tue, 09 Mar 2004 12:55:27 +0200 From: Buyurman Baykal User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: undisclosed-recipients:; Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip4] Last CFP for Med-Hoc-Net 2004 Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,LINES_OF_YELLING autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit We apologize if you receive multiple copies of this message ---------------------------------------------------------------------- ANNOUNCEMENTS: **Deadline Approaching** - PAPER SUBMISSION DEADLINE IS EXTENDED TO MARCH 12, 2004. - PAPERS WILL BE SUBMITTED THROUGH EDAS SYSTEM ---------------------------------------------------------------------- Med-Hoc-Net 2004 The Third Annual Mediterranean Ad Hoc Networking Workshop June 27-30, 2004, Bodrum, Turkey http://www.medhoc04.diit.unict.it Call for Papers ---------------------------------------------------------------------- Scope: Ad hoc network applications are emerging continuously imposing their own stringent constraints which cannot be fulfilled by generic approaches and thus spur new research efforts. Therefore, ad hoc networks attract growing attention from the research community. The aim of Med-Hoc-Net 2004 is to serve as a platform for researchers and visionaries from academia, research labs, and industry from all over the globe to share their ideas, views, results, and experiences in the field of ad-hoc networking and communications. Med-Hoc-Net 2004 will include presentations of theoretical and experimental achievements, innovative ad-hoc systems, prototyping efforts, case studies, and advancements in technology directly affecting ad-hoc networking and communications infrastructures. The papers solicited in Med-Hoc-Net 2004 cover a variety of topics including but not limited to: - Novel ad-hoc network architectures and applications, - Sensor network applications and protocols, - Implementations, testbeds, and prototypes, - Interfacing ad-hoc systems with different networks, - Resource discovery and management, - Power management and control, - Call admission and traffic shaping policies for ad-hoc networks, - Multimedia location services, - Self organization and network reconfiguration, - Protocols for QoS support in ad-hoc networks, - QoS support in Bluetooth, HIPERLAN, IEEE 802.11 etc., - MAC protocols, scheduling, and radio resource sharing in ad hoc networks, - Unicast and multicast routing algorithms and protocols, - Transport layer protocols for multi-hop networks, - Congestion control, - Performance evaluation of ad-hoc network protocols through simulations, analysis, and measurements, - Security in ad-hoc networks, - Fault tolerance and error recovery - Signal processing algorithms (coding, compression) for ad-hoc networks The program committee will referee all papers, and accepted papers will be published in the conference proceedings. Papers of particular merit will be published in the Elsevier Ad Hoc Networks Journal. Manuscripts must be formatted according to the IEEE double-column standard format, except the font size, which must be 11pt. Authors should use only standard fonts, i.e., Times Roman, Courier, Symbol, and Helvetica, or their equivalent. The maximum length of the manuscript is 12 pages. NEW: THE PAPER SUBMISSION DEADLINE IS EXTENDED TO MARCH 12, 2004 PAPERS WILL BE SUBMITTED THROUGH EDAS SYSTEM Papers should be submitted in pdf or ps format through EDAS system (http://edas.info) according to the following timetable: Important Dates: Full Paper Electronic Submission: March 12, 2004 Tutorial proposal submission: April 15, 2004 Notification of Acceptance/Rejection: May 3, 2004 Camera ready submission of full papers: May 17, 2004 Tutorial date: June 27, 2004 Conference dates: June 28-30, 2004 Organization Committee: General Chair: Ian F. Akyildiz, Georgia Institute of Technology, USA General Vice Chair: Erdal Cayirci, Istanbul Technical University, TURKEY Technical Program Chairs: Giacomo Morabito, University of Catania, ITALY Eylem Ekici, Ohio State University, USA Tutorial Chairs: Francesca Cuomo, University of Rome - La Sapienza, ITALY Christos Douligeris, University of Piraeus, GREECE Publicity Chairs: Buyurman Baykal, Middle East Technical University, TURKEY Jaudelice Cavalcante de Oliveira, Drexel University, USA Registration Chair: Sebnem Baydere, Yeditepe University, TURKEY Technical Program Committee: Khaldoun Al Agha, Laboratoire de Recherche en Informatique, FRANCE Hamid Aghvami, King's College London, UK Eitan Altman, INRIA, FRANCE Roberto Battiti, University of Trento, ITALY Raouf Boutaba, University of Waterloo, CANADA Walid Dabbous, INRIA, FRANCE Magda El Zarki, University of California at Irvine, USA Luigi Fratta, Politecnico di Milano, ITALY Mario Gerla, UCLA, USA Paul J. M. Havinga, University of Twente, NETHERLANDS Ahmed Helmy, University of Southern California, USA Farouk Kamoun, ENSI, TUNISIA Holger Karl, Technical University of Berlin, GERMANY Ulf Korner, Lund Institute of Technology, SWEDEN Bhaskar Krishnamachari, University of Southern California, USA Marwan Krunz, University of Arizona, USA Albert Levi, Sabanci University, TURKEY Janise McNair, University of Florida, USA Lazaros Merakos, University of Athens, GREECE Ioanis Nikolaidis, University of Alberta, CANADA Ariel Orda, Technion, ISRAEL Sergio Palazzo, University of Catania, ITALY Giovanni Pau, UCLA, USA Chiara Petrioli, University of Rome "La Sapienza", ITALY Andreas Pitsillides, University of Cyprus, CYPRUS Guy Pujolle, LIP6, FRANCE Paolo Santi, CNR, ITALY Adrian Segall, Technion, ISRAEL Ness Shroff, Purdue University, USA Moshe Sidi, Technion, ISRAEL Raghupathy Sivakumar, Georgia Institute of Technology, USA Ioannis Stavrakakis, University of Athens, GREECE Ivan Stojmenovic, University of Ottawa, CANADA Violet R. Syrotiuk, Arizona State University, USA Leandros Tassiulas, University of Thessaly, GREECE Damla Turgut, University of Central Florida, USA Bernhard H. Walke, Aachen University of Technology, GERMANY Wenye Wang, North Carolina State University, USA Michele Zorzi, University of Ferrara, ITALY -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Fri Mar 12 16:44:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20479 for ; Fri, 12 Mar 2004 16:44:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1uRl-0003fJ-VT for mip4-archive@odin.ietf.org; Fri, 12 Mar 2004 16:44:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CLi1Ef014075 for mip4-archive@odin.ietf.org; Fri, 12 Mar 2004 16:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1uRk-0003er-SX for mip4-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 16:44:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20352 for ; Fri, 12 Mar 2004 16:43:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1uRi-0001Fu-00 for mip4-web-archive@ietf.org; Fri, 12 Mar 2004 16:43:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1uQe-00015D-00 for mip4-web-archive@ietf.org; Fri, 12 Mar 2004 16:42:52 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B1uQ3-00013E-04 for mip4-web-archive@ietf.org; Fri, 12 Mar 2004 16:42:15 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B1uMw-00005X-4m for mip4-web-archive@ietf.org; Fri, 12 Mar 2004 16:39:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1uMv-0003K1-RE; Fri, 12 Mar 2004 16:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1uMf-0003Jd-Px for mip4@optimus.ietf.org; Fri, 12 Mar 2004 16:38:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20251 for ; Fri, 12 Mar 2004 16:38:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1uMd-0000y3-00 for mip4@ietf.org; Fri, 12 Mar 2004 16:38:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1uLl-0000x7-00 for mip4@ietf.org; Fri, 12 Mar 2004 16:37:50 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1B1uLa-0000vX-00 for mip4@ietf.org; Fri, 12 Mar 2004 16:37:38 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i2CLb7S17673; Fri, 12 Mar 2004 13:37:07 -0800 X-mProtect: <200403122137> Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdCWBoyI; Fri, 12 Mar 2004 13:37:06 PST Message-ID: <40522D78.30CB04@iprg.nokia.com> Date: Fri, 12 Mar 2004 13:36:56 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mip4@ietf.org CC: Henrik Levkowetz , Pete McCann Subject: Re: [Mip4] [Issue 17] Enhanced Registration Request processing at the Home Agent. References: <40185238.F883A5F2@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello folks, I propose that issue 17 be closed and marked as rejected. Regards, Charlie P. "Charles E. Perkins" wrote: > > Hello folks, > > Please refer to previous discussion at the following URL: > http://www.mip4.org/issues/tracker/mip4/issue17 > and: > http://www.ietf.org/proceedings/03nov/142.htm > as necessary. > > This issue has to deal with what the home agent might > do if it gets a Registration Request to an unknown > unicast address. Nobody presented sufficient reasons > for the home agent to take any useful action other than > rejecting the Request. I don't think that any changes > to the specification are yet warranted by discussion > up until now. > > Regards, > Charlie P. > > -- > Mip4 mailing list > Mip4@ietf.org > https://www.ietf.org/mailman/listinfo/mip4 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Fri Mar 12 16:54:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21061 for ; Fri, 12 Mar 2004 16:54:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1ubC-0004Yx-6x for mip4-archive@odin.ietf.org; Fri, 12 Mar 2004 16:53:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CLrkRp017539 for mip4-archive@odin.ietf.org; Fri, 12 Mar 2004 16:53:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1ubC-0004Yo-25 for mip4-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 16:53:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21034 for ; Fri, 12 Mar 2004 16:53:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1ubA-0001oD-00 for mip4-web-archive@ietf.org; Fri, 12 Mar 2004 16:53:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1uaE-0001lp-00 for mip4-web-archive@ietf.org; Fri, 12 Mar 2004 16:52:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1uZT-0001kY-00 for mip4-web-archive@ietf.org; Fri, 12 Mar 2004 16:51:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1uZV-0004Su-6s; Fri, 12 Mar 2004 16:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1uZG-0004Rc-H5 for mip4@optimus.ietf.org; Fri, 12 Mar 2004 16:51:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21009 for ; Fri, 12 Mar 2004 16:51:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1uZE-0001jZ-00 for mip4@ietf.org; Fri, 12 Mar 2004 16:51:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1uYM-0001iN-00 for mip4@ietf.org; Fri, 12 Mar 2004 16:50:50 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1B1uXk-0001ek-00 for mip4@ietf.org; Fri, 12 Mar 2004 16:50:12 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i2CLnf608438; Fri, 12 Mar 2004 13:49:41 -0800 X-mProtect: <200403122149> Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdfVPFjk; Fri, 12 Mar 2004 13:49:40 PST Message-ID: <40523069.AA2C0F54@iprg.nokia.com> Date: Fri, 12 Mar 2004 13:49:29 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mip4@ietf.org CC: Henrik Levkowetz , Pete McCann Subject: Re: [Mip4] [Issue 18] The FA is rejecting with Error Code 136 which is meant for the home agent References: <870397D7C140C84DB081B88396458DAF746CDD@zrc2c000.us.nortel.com> <401A8ED2.CAC5E6AA@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello folks, I have added text for a new status code for the Registration Reply, and made the repair suggested by Jayshree. I propose that this issue be marked as "accepted" and closed. Regards, Charlie P. "Charles E. Perkins" wrote: > > Hello Jayshree, > > Yes, you are quite correct. I have changed it within > the revised document now -- thanks! > > Regards, > Charlie P. > > Jayshree Bharatia wrote: > > > > Hello Charlie, > > > > I would think that this new code value you are defining will be for the > > Registration Reply message (and not for Registration Request). My suggestion > > is inline... > > > > Thanks, > > Jayshree > > > > > -----Original Message----- > > > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > > > Sent: Wednesday, January 28, 2004 6:15 PM > > > To: mip4@ietf.org > > > Subject: [Mip4] [Issue 18] The FA is rejecting with Error > > > Code 136 which is meant for the home agent > > > > > > > > > > > > Hello folks, > > > > > > Please refer to previous discussion at the following URL: > > > http://www.mip4.org/issues/tracker/mip4/issue18 > > > as necessary. > > > > > > The proposed solution: create a new error code. > > > > > > Existing text: > > > if the foreign agent does not serve the mobile node as a > > > home agent, > > > the foreign agent rejects the Registration Request with code 136 > > > (unknown home agent address). > > > > > > New text: > > > if the foreign agent does not serve the mobile node as a > > > home agent, > > > the foreign agent rejects the Registration Request with code > > > TBD-IANA (Invalid Home Agent Address). > > > > > > New text in IANA Considerations: > > > In this revised specification, a new Code value (for the > > > field in the > > > Registration Request message) is needed within the range typically > > > used for Foreign Agent messages. This error code is needed to > > > indicate the status "Invalid Home Agent Address". See > > > section 3.7.2 > > > for details. > > > > > [JB] New text in IANA Considerations: > > In this revised specification, a new Code value (for the field in the > > Registration Reply message) is needed within ... > > > > > > Regards, > > > Charlie P. > > > > > > -- > > > Mip4 mailing list > > > Mip4@ietf.org > > > https://www.ietf.org/mailman/listinfo/mip4 > > > > > -- > Mip4 mailing list > Mip4@ietf.org > https://www.ietf.org/mailman/listinfo/mip4 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Fri Mar 12 16:59:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21302 for ; Fri, 12 Mar 2004 16:59:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1ug0-00058Q-C3 for mip4-archive@odin.ietf.org; Fri, 12 Mar 2004 16:58:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CLwihU019732 for mip4-archive@odin.ietf.org; Fri, 12 Mar 2004 16:58:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1ug0-00058B-6q for mip4-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 16:58:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21259 for ; Fri, 12 Mar 2004 16:58:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1ufy-00021W-00 for mip4-web-archive@ietf.org; Fri, 12 Mar 2004 16:58:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1uf7-0001yj-00 for mip4-web-archive@ietf.org; Fri, 12 Mar 2004 16:57:50 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1ueJ-0001wn-00 for mip4-web-archive@ietf.org; Fri, 12 Mar 2004 16:56:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1ueL-0004ta-6G; Fri, 12 Mar 2004 16:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1ueA-0004pv-B3 for mip4@optimus.ietf.org; Fri, 12 Mar 2004 16:56:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21175 for ; Fri, 12 Mar 2004 16:56:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1ue8-0001vW-00 for mip4@ietf.org; Fri, 12 Mar 2004 16:56:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1udC-0001tk-00 for mip4@ietf.org; Fri, 12 Mar 2004 16:55:51 -0500 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 1B1ucd-0001qC-00 for mip4@ietf.org; Fri, 12 Mar 2004 16:55:15 -0500 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i2CLsbq24393; Fri, 12 Mar 2004 15:54:37 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 12 Mar 2004 15:54:38 -0600 Message-ID: <870397D7C140C84DB081B88396458DAF746D5D@zrc2c000.us.nortel.com> From: "Jayshree Bharatia" To: "'Charles E. Perkins'" , mip4@ietf.org Cc: Henrik Levkowetz , Pete McCann Subject: RE: [Mip4] [Issue 17] Enhanced Registration Request processing at the Home Agent. Date: Fri, 12 Mar 2004 15:54:31 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 Hello Charlie, The current proposal has two changes for section 3.8.3.2 of RFC3344: Change 1: "If the Home Agent cannot support the specified nonzero unicast address in the Home Address field of the Registration Request, then the Home Agent MUST reject the registration with an error code of 129. " If the MN registers a static Home Address (or registers with a previously assigned dynamic Home Address) on a Home Agent that can not support the presented Home Address, then the Home Agent fails the registration and return code 129 "admin prohibited" (or something equivalent). Change 2: "if the destination IP address of the Registration Request is the unicast IP address of this Home Agent, the Home Agent MAY accept the Registration Request. If the destination IP address of the Registration Request is not the unicast IP address of this Home Agent, the home agent MUST reject the Registration Request with a suitable code(e.g., Code 136) to prevent the mobile node from possibly being simultaneously registered with two or more Home Agents." This text is applicable for the Dynamic Home Agent mechanism. If the HA receives a Registration Request with a Home Agent field not its own, the HA "MAY" accept the registration. Please note that the current text requires the HA to reject the registration. I would think that both of these are reasonable suggestions. Thanks, Jayshree > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > Sent: Friday, March 12, 2004 3:37 PM > To: mip4@ietf.org > Cc: Henrik Levkowetz; Pete McCann > Subject: Re: [Mip4] [Issue 17] Enhanced Registration Request > processing at the Home Agent. > > > > Hello folks, > > I propose that issue 17 be closed and > marked as rejected. > > Regards, > Charlie P. > > > > "Charles E. Perkins" wrote: > > > > Hello folks, > > > > Please refer to previous discussion at the following URL: > > http://www.mip4.org/issues/tracker/mip4/issue17 > > and: > > http://www.ietf.org/proceedings/03nov/142.htm > > as necessary. > > > > This issue has to deal with what the home agent might > > do if it gets a Registration Request to an unknown > > unicast address. Nobody presented sufficient reasons > > for the home agent to take any useful action other than > rejecting the > > Request. I don't think that any changes to the > specification are yet > > warranted by discussion up until now. > > > > Regards, > > Charlie P. > > > > -- > > Mip4 mailing list > > Mip4@ietf.org > > https://www.ietf.org/mailman/listinfo/mip4 > > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Fri Mar 12 17:17:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22490 for ; Fri, 12 Mar 2004 17:17:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1uxX-0006T4-KR for mip4-archive@odin.ietf.org; Fri, 12 Mar 2004 17:16:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CMGprL024856 for mip4-archive@odin.ietf.org; Fri, 12 Mar 2004 17:16:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1uxX-0006Sp-Ex for mip4-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 17:16:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22475 for ; Fri, 12 Mar 2004 17:16:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1uxV-0003KM-00 for mip4-web-archive@ietf.org; Fri, 12 Mar 2004 17:16:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1uwZ-0003Hy-00 for mip4-web-archive@ietf.org; Fri, 12 Mar 2004 17:15:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1uvm-0003Fg-00 for mip4-web-archive@ietf.org; Fri, 12 Mar 2004 17:15:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1uvn-0006OP-2K; Fri, 12 Mar 2004 17:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1uut-0006Kz-J6 for mip4@optimus.ietf.org; Fri, 12 Mar 2004 17:14:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22347 for ; Fri, 12 Mar 2004 17:14:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1uur-0003CZ-00 for mip4@ietf.org; Fri, 12 Mar 2004 17:14:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1uuH-000378-00 for mip4@ietf.org; Fri, 12 Mar 2004 17:13:30 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1B1ut3-0002o2-00 for mip4@ietf.org; Fri, 12 Mar 2004 17:12:13 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i2CMBgK16405; Fri, 12 Mar 2004 14:11:42 -0800 X-mProtect: <200403122211> Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdr5RxoQ; Fri, 12 Mar 2004 14:11:40 PST Message-ID: <40523592.EB8650E2@iprg.nokia.com> Date: Fri, 12 Mar 2004 14:11:30 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mip4@ietf.org CC: Henrik Levkowetz , Pete McCann Subject: Re: [Mip4] [Issue 9] Why Allowing FA to reject RRQ with error code 136 References: <40185305.A8CE2E24@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello again folks, The text has been revised to create a new RREP status code named "Invalid Home Agent Address". A new item has been entered into the list of foreign agent codes, after the existing code 73 but still with TBD-IANA as its value. The following text is added to section 3.7.2 at the end of the second paragraph: > ........... Otherwise, > if the foreign agent does not serve the mobile node as a home agent, > the foreign agent rejects the Registration Request with code TBD-IANA > (Invalid Home Agent Address). The following text appears in the IANA Considerations: > In this revised specification, a new Code value (for the field in the > Registration Reply message) is needed within the range typically used > for Foreign Agent messages. This error code is needed to indicate > the status "Invalid Home Agent Address". See section 3.7.2 for > details. With this resolution of the problem, I propose that Issue 9 be marked as "accepted" and closed. By the way, the current revised specification is available at the following URL: http://people.nokia.net/~charliep/txt/mobileip/rfc3344bis.txt Regards, Charlie P. "Charles E. Perkins" wrote: > > Hello folks, > > Please refer to previous discussion at the following URL: > http://www.mip4.org/issues/tracker/mip4/issue9 > and: > http://www.ietf.org/proceedings/03nov/142.htm > as necessary. > > There was some problems with wording in the existing > specification, revolving around allowing the foreign > agent to use Code 136. This will be resolved, if the > proposed solution to issue 18 is adopted. > > Regards, > Charlie P. > > -- > Mip4 mailing list > Mip4@ietf.org > https://www.ietf.org/mailman/listinfo/mip4 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Fri Mar 12 17:37:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23433 for ; Fri, 12 Mar 2004 17:37:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1vGs-0008Gb-9c for mip4-archive@odin.ietf.org; Fri, 12 Mar 2004 17:36:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CMaoIS031777 for mip4-archive@odin.ietf.org; Fri, 12 Mar 2004 17:36:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1vGs-0008GS-50 for mip4-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 17:36:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23417 for ; Fri, 12 Mar 2004 17:36:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1vGp-0004GJ-00 for mip4-web-archive@ietf.org; Fri, 12 Mar 2004 17:36:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1vFv-0004E7-00 for mip4-web-archive@ietf.org; Fri, 12 Mar 2004 17:35:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1vF8-0004C6-00 for mip4-web-archive@ietf.org; Fri, 12 Mar 2004 17:35:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1vF9-0007zd-QK; Fri, 12 Mar 2004 17:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1vF0-0007yr-3O for mip4@optimus.ietf.org; Fri, 12 Mar 2004 17:34:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23325 for ; Fri, 12 Mar 2004 17:34:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1vEx-0004BM-00 for mip4@ietf.org; Fri, 12 Mar 2004 17:34:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1vDz-00049E-00 for mip4@ietf.org; Fri, 12 Mar 2004 17:33:52 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1B1vDb-00046d-00 for mip4@ietf.org; Fri, 12 Mar 2004 17:33:27 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i2CMWuj16439; Fri, 12 Mar 2004 14:32:56 -0800 X-mProtect: <200403122232> Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd4KsDjD; Fri, 12 Mar 2004 14:32:53 PST Message-ID: <40523A8B.5C41288F@iprg.nokia.com> Date: Fri, 12 Mar 2004 14:32:43 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mip4@ietf.org CC: Henrik Levkowetz , Pete McCann References: <4018268D.1E4B7D17@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip4] Re: [Issue 22] Section 3.4 para 1 is too simplified Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello folks, With the proposed wording changes as shown in previous e-mail, I proposed that Issue 22 be marked as "accepted" and closed. Regards, Charlie P. "Charles E. Perkins" wrote: > > Hello folks, > > Please refer to previous discussion at the following URL: > http://www.mip4.org/issues/tracker/mip4/issue22 > as necessary. > > Here is a proposed new paragraph, utilizing the word > "typically" along with some other minor improvement. > > A mobility agent typically returns a Registration Reply message to > a mobile node which has sent a Registration Request (Section 3.3) > message. If the mobile node is requesting service from a foreign > agent, that foreign agent will typically receive the Reply from the > home agent and subsequently relay it to the mobile node. Reply > messages contain the necessary codes to inform the mobile node about > the status of its Request, along with the lifetime granted by the > home agent, which MAY be smaller than the original Request. > > Regards, > Charlie P. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Fri Mar 12 18:06:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25556 for ; Fri, 12 Mar 2004 18:06:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1vjT-0004pp-7g for mip4-archive@odin.ietf.org; Fri, 12 Mar 2004 18:06:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CN6NYs018583 for mip4-archive@odin.ietf.org; Fri, 12 Mar 2004 18:06:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1vjT-0004pe-2g for mip4-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 18:06:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25422 for ; Fri, 12 Mar 2004 18:06:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1vjQ-0006V6-00 for mip4-web-archive@ietf.org; Fri, 12 Mar 2004 18:06:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1viF-0006L2-00 for mip4-web-archive@ietf.org; Fri, 12 Mar 2004 18:05:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1vhP-0006B2-00 for mip4-web-archive@ietf.org; Fri, 12 Mar 2004 18:04:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1vhH-0004AA-B1; Fri, 12 Mar 2004 18:04:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1vgm-0003sp-3h for mip4@optimus.ietf.org; Fri, 12 Mar 2004 18:03:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24858 for ; Fri, 12 Mar 2004 18:03:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1vgj-00064s-00 for mip4@ietf.org; Fri, 12 Mar 2004 18:03:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1veu-0005oI-00 for mip4@ietf.org; Fri, 12 Mar 2004 18:01:41 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1B1vdA-0005XF-00 for mip4@ietf.org; Fri, 12 Mar 2004 17:59:52 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i2CMxGw28329; Fri, 12 Mar 2004 14:59:16 -0800 X-mProtect: <200403122259> Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdTF763c; Fri, 12 Mar 2004 14:59:14 PST Message-ID: <405240B8.1D686FE9@iprg.nokia.com> Date: Fri, 12 Mar 2004 14:59:04 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Jayshree Bharatia CC: mip4@ietf.org Subject: Re: [Mip4] [Issue 17] Enhanced Registration Request processing atthe Home Agent. References: <870397D7C140C84DB081B88396458DAF746D5D@zrc2c000.us.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Jayshree, Thanks for reminding me about these points -- I missed them because I was looking on the issue tracker. Jayshree Bharatia wrote: > Change 1: "If the Home Agent cannot support the specified nonzero unicast > address in the Home Address field of the Registration Request, then the Home > Agent MUST reject the registration with an error code of 129. " I have put this addition into the text for section 3.8.3.2. I agree that error number 129 will serve the purpose. > If the MN registers a static Home Address (or registers with a previously > assigned dynamic Home Address) on a Home Agent that can not support the > presented Home Address, then the Home Agent fails the registration and > return code 129 "admin prohibited" (or something equivalent). This seems to me to duplicate the work of the previous paragraph, so I would hope that it does not have to be added also. I don't see why the home agent has to know whether the address was dynamically assigned or not. > Change 2: "if the destination IP address of the Registration Request is the > unicast IP address of this Home Agent, the Home Agent MAY accept the > Registration Request. The conditions for accepting registrations from the mobile node are sort-of the subject of a great deal of text, so I guess that the purpose of this sentence is to enable a new kind of operation for when a nonzero Home Agent address field does not match the unicast address in the IP header. This means, for instance, that the Registration Request didn't come from the foreign agent. Or else there is a new protocol in operation that is outside the scope of this document. In either case, I would expect that the details of operation are more appropriately described in another document. That other document would be also able to override the mandates within RFC 3344{,bis}, and so I am reluctant to make such partial changes within rfc3344bis-00.txt > If the destination IP address of the Registration > Request is not the unicast IP address of this Home Agent, the home agent > MUST reject the Registration Request with a suitable code(e.g., Code 136) to > prevent the mobile node from possibly being simultaneously registered with > two or more Home Agents." Here, it is not clear how the Home Agent was able to receive the packet in the first place. > This text is applicable for the Dynamic Home Agent mechanism. If the HA > receives a Registration Request with a Home Agent field not its own, the HA > "MAY" accept the registration. Please note that the current text requires > the HA to reject the registration. I hope that the Dynamic Home Agent document should be the place to make the changes. Regards, Charlie P. > > -----Original Message----- > > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > > Sent: Friday, March 12, 2004 3:37 PM > > To: mip4@ietf.org > > Cc: Henrik Levkowetz; Pete McCann > > Subject: Re: [Mip4] [Issue 17] Enhanced Registration Request > > processing at the Home Agent. > > > > > > > > Hello folks, > > > > I propose that issue 17 be closed and > > marked as rejected. > > > > Regards, > > Charlie P. > > > > > > > > "Charles E. Perkins" wrote: > > > > > > Hello folks, > > > > > > Please refer to previous discussion at the following URL: > > > http://www.mip4.org/issues/tracker/mip4/issue17 > > > and: > > > http://www.ietf.org/proceedings/03nov/142.htm > > > as necessary. > > > > > > This issue has to deal with what the home agent might > > > do if it gets a Registration Request to an unknown > > > unicast address. Nobody presented sufficient reasons > > > for the home agent to take any useful action other than > > rejecting the > > > Request. I don't think that any changes to the > > specification are yet > > > warranted by discussion up until now. > > > > > > Regards, > > > Charlie P. > > > > > > -- > > > Mip4 mailing list > > > Mip4@ietf.org > > > https://www.ietf.org/mailman/listinfo/mip4 > > > > -- > > Mip4 mailing list: Mip4@ietf.org > > Web interface: https://www.ietf.org/mailman/listinfo/mip4 > > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > > Supplemental site: http://www.mip4.org/ > > > > --DS9166993534658177240-- -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Fri Mar 12 18:11:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26154 for ; Fri, 12 Mar 2004 18:11:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1vno-0006LM-KM for mip4-archive@odin.ietf.org; Fri, 12 Mar 2004 18:10:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CNAqtq024378 for mip4-archive@odin.ietf.org; Fri, 12 Mar 2004 18:10:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1vno-0006L7-EU for mip4-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 18:10:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26081 for ; Fri, 12 Mar 2004 18:10:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1vnl-0006zx-00 for mip4-web-archive@ietf.org; Fri, 12 Mar 2004 18:10:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1vms-0006vG-00 for mip4-web-archive@ietf.org; Fri, 12 Mar 2004 18:09:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1vlz-0006oh-00 for mip4-web-archive@ietf.org; Fri, 12 Mar 2004 18:08:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1vm1-0005k8-At; Fri, 12 Mar 2004 18:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1vlC-0005TC-K7 for mip4@optimus.ietf.org; Fri, 12 Mar 2004 18:08:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25740 for ; Fri, 12 Mar 2004 18:08:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1vl9-0006jF-00 for mip4@ietf.org; Fri, 12 Mar 2004 18:08:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1vkM-0006dU-00 for mip4@ietf.org; Fri, 12 Mar 2004 18:07:18 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1B1vjK-0006Pl-00 for mip4@ietf.org; Fri, 12 Mar 2004 18:06:15 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i2CN55i06132; Fri, 12 Mar 2004 15:05:05 -0800 X-mProtect: <200403122305> Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdeDIUnm; Fri, 12 Mar 2004 15:05:04 PST Message-ID: <40524216.F7623117@iprg.nokia.com> Date: Fri, 12 Mar 2004 15:04:54 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Henrik Levkowetz CC: mip4@ietf.org Subject: Re: [Mip4] [Issue 21] MN-AAA extension not considered in FA to HAforwarding rules References: <401830D9.CED2FA09@iprg.nokia.com> <20040202190520.37822722.henrik@levkowetz.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Henrik, I have used your suggested wording: > It MUST process and remove any Extensions which are > not covered by any authorization-enabling extension. With this additional change, I propose that the issue be marked as "accepted" and closed. Regards, Charlie P. Henrik Levkowetz wrote: > > Hi, > > > ... On Wednesday, 28 Jan 2004, Charles E. Perkins wrote: > > > > The problem with this text results from the > > previous change to Mobile IP whereby registrations > > can be authorized by including alternative > > "authorization-enabling" extensions, for instance > > the "MN-AAA Authentication" extension. I fixed > > this by rewording the bullet item as suggested at > > the working group meeting. > > > > OLD: > > - It MUST process and remove any Extensions following the > > Mobile-Home Authentication Extension, > > NEW: > > - It MUST process and remove any Extensions which do not > > precede any authorization-enabling extension. > > > > I _think_ this also takes care of the case where a > > foreign agent doesn't recognize the authorization-enabling > > extension. Perhaps we should designate new Extension > > with subtypes that would take care of all future > > authentication-enabling extensions. That would be > > the clearest resolution of this problem. > > I think the proposed text actually also implies that the > last authorization-enabling extension should be processed > and removed, which isn't what we want, I guess. What about > > " - It MUST process and remove any Extensions following the > last authorization-enabling extension." > > or maybe > > " - It MUST process and remove any Extensions which are > not covered by any authorization-enabling extension." > > Regards, > Henrik > > -------------------------------------------------------------------------------- > Part 1.2Type: application/pgp-signature -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Fri Mar 12 18:15:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26615 for ; Fri, 12 Mar 2004 18:15:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1vrb-0007bS-Mf for mip4-archive@odin.ietf.org; Fri, 12 Mar 2004 18:14:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CNEllO029219 for mip4-archive@odin.ietf.org; Fri, 12 Mar 2004 18:14:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1vrb-0007az-8p for mip4-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 18:14:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26532 for ; Fri, 12 Mar 2004 18:14:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1vrY-0007Ca-00 for mip4-web-archive@ietf.org; Fri, 12 Mar 2004 18:14:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1vqg-0007A9-00 for mip4-web-archive@ietf.org; Fri, 12 Mar 2004 18:13:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1vpr-000782-00 for mip4-web-archive@ietf.org; Fri, 12 Mar 2004 18:12:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1vpt-00074Y-4s; Fri, 12 Mar 2004 18:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1vpk-00072V-KL for mip4@optimus.ietf.org; Fri, 12 Mar 2004 18:12:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26349 for ; Fri, 12 Mar 2004 18:12:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1vph-000773-00 for mip4@ietf.org; Fri, 12 Mar 2004 18:12:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1voq-00075F-00 for mip4@ietf.org; Fri, 12 Mar 2004 18:11:56 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1B1vob-00072i-00 for mip4@ietf.org; Fri, 12 Mar 2004 18:11:41 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i2CNAWi15553; Fri, 12 Mar 2004 15:10:32 -0800 X-mProtect: <200403122310> Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdW8gTAd; Fri, 12 Mar 2004 15:10:29 PST Message-ID: <4052435B.6B87938E@iprg.nokia.com> Date: Fri, 12 Mar 2004 15:10:19 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Henrik Levkowetz CC: mip4@ietf.org Subject: Re: [Mip4] [issue 19] Multiple authorization-enabling extensionsshould be permitted References: <40184B0F.F7199D88@iprg.nokia.com> <20040202193226.343e18b8.henrik@levkowetz.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Henrik, I have inserted the suggested cross reference to the Terminology section as requested. With this additional modification, I propose that Issue 19 be marked as "accepted" and closed. Regards, Charlie P. Henrik Levkowetz wrote: > > > - On Wednesday, 28 Jan 2004, Charles E. Perkins wrote: > > > > Section 3.6.1.3 > ... > > New text: > > > > This section describes the ordering of any mandatory and any optional > > Extensions that a mobile node appends to a Registration Request. > > This ordering is REQUIRED: > > > > a) The IP header, followed by the UDP header, followed by the > > fixed-length portion of the Registration Request, followed by > > > > b) If present, any non-authentication Extensions expected to be > > used by the home agent or other authorizing agent (which may > > or may not also be useful to the foreign agent), followed by > > > > c) All authorization-enabling extensions, followed by > > > > d) If present, any non-authentication Extensions used only by > > the foreign agent, followed by > > > > e) The Mobile-Foreign Authentication Extension, if present. > > > > Note that items (a) and (c) MUST appear in every Registration Request > > sent by the mobile node. Items (b), (d), and (e) are optional. > > However, item (e) MUST be included when the mobile node and the > > foreign agent share a mobility security association. > > With this new wording, it might be good (in order to avoid confusion) > to refer back to the definition in Section 1.6 of "Authorization- > enabling extension": > > ... > c) All authorization-enabling extensions, (see Section 1.6) > followed by > ... > > Regards, > Henrik > > -------------------------------------------------------------------------------- > Part 1.2Type: application/pgp-signature -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Fri Mar 12 18:58:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00067 for ; Fri, 12 Mar 2004 18:58:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1wXJ-0003on-BO for mip4-archive@odin.ietf.org; Fri, 12 Mar 2004 18:57:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CNvr18014671 for mip4-archive@odin.ietf.org; Fri, 12 Mar 2004 18:57:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1wXJ-0003oY-6A for mip4-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 18:57:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29991 for ; Fri, 12 Mar 2004 18:57:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1wXG-0002Wl-00 for mip4-web-archive@ietf.org; Fri, 12 Mar 2004 18:57:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1wWN-0002QO-00 for mip4-web-archive@ietf.org; Fri, 12 Mar 2004 18:56:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1wVU-0002K5-00 for mip4-web-archive@ietf.org; Fri, 12 Mar 2004 18:56:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1wVW-0003gk-7I; Fri, 12 Mar 2004 18:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1wUe-0003cr-Oe for mip4@optimus.ietf.org; Fri, 12 Mar 2004 18:55:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29741 for ; Fri, 12 Mar 2004 18:55:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1wUb-0002Dv-00 for mip4@ietf.org; Fri, 12 Mar 2004 18:55:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1wTc-000285-00 for mip4@ietf.org; Fri, 12 Mar 2004 18:54:05 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1B1wSk-0001vJ-00 for mip4@ietf.org; Fri, 12 Mar 2004 18:53:10 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i2CNqWk28269; Fri, 12 Mar 2004 15:52:32 -0800 X-mProtect: <200403122352> Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdXXdMmo; Fri, 12 Mar 2004 15:52:30 PST Message-ID: <40524D34.5E628689@iprg.nokia.com> Date: Fri, 12 Mar 2004 15:52:20 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: ext Sri Gundavelli CC: mip4@ietf.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip4] Re: [Issue 44] RFC 3344 - Source Address of the RRQ Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Sri, This is regarding the new Issue 44. It seems that we both tried to insert this issue at about the same time, so that your text appears twice. Or else, I don't understand just how the darned issue tracker works... Anyway. here is the text revision I propose to resolve this issue: Old text: The foreign agent's address on the interface from which the message will be sent. New text: The care-of address offered by the foreign agent for the mobile node sending the Registration Request. I believe it's possible for the foreign agent to offer a multiplicity of care-of addresses, and I tried to arrange it so that this text does not preclude that possibility. Regards, Charlie P. ext Sri Gundavelli wrote: > > RFC 3344: > Section 3.7.2.2. Forwarding a Valid Request to the Home Agent > > "Specific fields within the IP header and the UDP header of the > relayed Registration Request MUST be set as follows: > IP Source Address > The foreign agent's address on the interface from which > the message will be sent." > > Per the above the text, the foreign agent is required to send the RRQ > with the source address of the outgoing interface and this essentially > conflicts with RFC 3519 (NAT Traversal) requirement. Per 3519, the > foreign agent is required to set the source address of the RRQ to its > care-of address, so that the home agent does not detect NAT incorrectly. > The logic of NAT detection at the home agent is by comparing the source > address of the RRQ to the care-of address in the RRQ's MIP header. So, > we need to fix the text in 3344. There is no reason why the foreign agent > MUST set the source address of the RRQ to the IP address of its outgoing > interface. We should infact enforce the foreign agent to set the source > address of the RRQ to the FA care of address. > > Sri/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Fri Mar 12 19:46:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02436 for ; Fri, 12 Mar 2004 19:46:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1xHo-0006ma-IO for mip4-archive@odin.ietf.org; Fri, 12 Mar 2004 19:45:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2D0juLN026066 for mip4-archive@odin.ietf.org; Fri, 12 Mar 2004 19:45:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1xHo-0006mL-DT for mip4-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 19:45:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02390 for ; Fri, 12 Mar 2004 19:45:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1xHm-0005KC-00 for mip4-web-archive@ietf.org; Fri, 12 Mar 2004 19:45:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1xGs-0005Ga-00 for mip4-web-archive@ietf.org; Fri, 12 Mar 2004 19:44:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1xFx-0005DC-00 for mip4-web-archive@ietf.org; Fri, 12 Mar 2004 19:44:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1xFy-0006fq-DT; Fri, 12 Mar 2004 19:44:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1xFs-0006ek-UK for mip4@optimus.ietf.org; Fri, 12 Mar 2004 19:43:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02324 for ; Fri, 12 Mar 2004 19:43:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1xFr-0005C6-00 for mip4@ietf.org; Fri, 12 Mar 2004 19:43:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1xEw-00058N-00 for mip4@ietf.org; Fri, 12 Mar 2004 19:42:59 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1B1xE4-00050w-00 for mip4@ietf.org; Fri, 12 Mar 2004 19:42:04 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i2D0fQD01528; Fri, 12 Mar 2004 16:41:26 -0800 X-mProtect: <200403130041> Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdD5sYpf; Fri, 12 Mar 2004 16:41:24 PST Message-ID: <405258AA.10FC70EF@iprg.nokia.com> Date: Fri, 12 Mar 2004 16:41:14 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: ext Sri Gundavelli CC: Naveen Paulkandasamy , mip4@ietf.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip4] Re: [Issue 45] RFC 3344 - FHAE issue when using a different careof address Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello again Sri, Thanks for submitting this issue. I think it points to several revisions that are needed to rfc3344bis. For a good resolution, I think it helps if we specify that the source address of the RREQ is the care-of address offered by the foreign agent, so please assume that for my discussion below. > Issue: When the mobile node deregisters using the care-of address of > a different foreign agent than the foreign agent forwarding the dereg > request, the document is not consistent in its explanation as how the > HA and FA should handle such requests. Unfortunately true. > Also, if the foreign agent is allowed to forward such requests, there > is no explanation as how the home agent should locate the security > associations for that FA and validate the FHAE. Presumably, this depends on the address used by the foreign agent. Let's say it's the care-of address. Also, please note that the document doesn't have much to say about mobility security assocations except in the case of the mobile node. It is expected that the home agent knows how to apply whatever algorithm has been preconfigured between itself and the foreign agent, which is not hard to imagine. We might as well go one step further and assume that the mobility security association depends on the foreign agent's care-of address, and that home agent uses that address to index into its security database along with the SPI as presented by the foreign agent. In fact, I believe the SPI itself "should" be sufficient for the purpose, but we don't have to hold the Mobile IP document up while waiting to resolve _that_ point. > Section: 3.8.2.2. Accepting a Valid Request > > In all cases, the home agent MUST send a Registration Reply to the > source of the Registration Request, which might indeed be a different > foreign agent than that whose care-of address is being > (de)registered. If the home agent shares a mobility security > association with the foreign agent whose care-of address is being > deregistered, and that foreign agent is different from the one which > relayed the Registration Request, the home agent MAY additionally > send a Registration Reply to the foreign agent whose care-of address > is being deregistered. > > Section: 3.7.2.1. Validity Checks > > Requests with the 'D' bit set to 0, and specifying a care-of address > not offered by the foreign agent, MUST be rejected with code 77 > (invalid care-of address). This documents the inconsistency. > When the MN sends a dereg request to a foreign agent with the intention > of deregistering its earlier binding it had with a different foreign agent, > the behaviour of FA as documented in Section 3.7.2.1 is to reject such > requst with invalid care-of address error. However, the HA considerations > (Section 3.8.2.2) allows such requests. The scenario is not handled > consistently at both HA and FA ends. Suggested resolution: amend the paragraph in section 3.7.2.1 as follows: Requests with the 'D' bit set to 0, nonzero lifetime, and specifying a care-of address not offered by the foreign agent, MUST be rejected with code 77 (invalid care-of address). This just adds a "nonzero lifetime" conditional which is then needed to trigger a mandated rejection. > Also, if the foreign agent is allowed to forward such requests, there > should be some explanation as how the FA should function when it > receives a dereg message with "D" bit not set and care-of address > set to the MN's home address (Deregister all bindings) or when its > set to the care-of address of a different foreign agent. Assuming the > FA is allowed to forward such a request and when there is security > association configured between FA and the HA, the home agent will not > be able to validate the FHAE. With the above, the FA is allowed to forward the request. With the proposed resolution of Issue 44, the IP address in the IP header will be a care-of address offered by the sending foreign agent. Then, the home agent can verify the FHAE, with the above proviso that the foreign-home mobility security association is preconfigured just that way. > The home agent for validating the FHAE > first needs to use COA address from the RRQ and use the SPI to locate > the security associations. Given that the care-of address is set to > either the home address of the mobile node or the care-of address of > a different foreign agent, how should the HA validate the FHAE ? The > HA cannot use the source address of the RRQ to locate the security > associations as there could be NAT in the path. Well, I guess we are agreeing that the security association used to validate the Foreign-Home Authentication Extension is indexed by the source IP address. That information needs to be supplied in section 3.5.4. Here is some proposed text: In order to perform the authentication, the Home Agent and the Foreign Agent have to have configured a security association that is able to be indexed by use of the SPI and the care-of address assocated with the Foreign Agent. This care-of address MUST be used as the Source IP address of the Registration Request containing the Foreign-Home Authentication Extension. When the extension is used with a Registration Reply message, the foreign agent address MUST be used as the Destination IP address in the IP header. Please let me know if I have sufficiently understood the issue, and if my proposed revisions clear up the inconsistencies. Regards, Charlie P. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Sat Mar 13 20:30:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10148 for ; Sat, 13 Mar 2004 20:30:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2KRh-0002p3-GG for mip4-archive@odin.ietf.org; Sat, 13 Mar 2004 20:29:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2E1TfhG010843 for mip4-archive@odin.ietf.org; Sat, 13 Mar 2004 20:29:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2KRg-0002oo-Pj for mip4-web-archive@optimus.ietf.org; Sat, 13 Mar 2004 20:29:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10126 for ; Sat, 13 Mar 2004 20:29:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2KRe-0000hf-00 for mip4-web-archive@ietf.org; Sat, 13 Mar 2004 20:29:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2KQi-0000dF-00 for mip4-web-archive@ietf.org; Sat, 13 Mar 2004 20:28:41 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2KQ4-0000ZC-00 for mip4-web-archive@ietf.org; Sat, 13 Mar 2004 20:28:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2KQ5-0002gD-CM; Sat, 13 Mar 2004 20:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1wL4-0002sb-8m for mip4@optimus.ietf.org; Fri, 12 Mar 2004 18:45:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28902 for ; Fri, 12 Mar 2004 18:45:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1wL1-0001D0-00 for mip4@ietf.org; Fri, 12 Mar 2004 18:45:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1wKP-00018b-00 for mip4@ietf.org; Fri, 12 Mar 2004 18:44:34 -0500 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=shiraz.levkowetz.com) by ietf-mx with esmtp (Exim 4.12) id 1B1wJT-0000zP-00 for mip4@ietf.org; Fri, 12 Mar 2004 18:43:35 -0500 Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=h195n1fls311o871.telia.com) by shiraz.levkowetz.com with esmtp (Exim 3.35 #1 (Debian)) id 1B1wJT-0001pq-00 for ; Sat, 13 Mar 2004 00:43:35 +0100 Content-Type: text/plain; charset=utf-8 To: mip4@ietf.org From: Sri Gundavelli Reply-To: Mip4 issue tracker Date: Fri, 12 Mar 2004 23:43:30 +0000 MIME-Version: 1.0 Message-Id: <1079135010.65.0.354555160283.issue45@mip4.org> X-Roundup-Name: Mip4 issue tracker X-Roundup-Loop: hello Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [Mip4] [issue45] RFC 3344 - FHAE issue when using a different care-of address Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable This has been entered in the issue tracker as issue 45. owner: Sri Gundavelli : category: Technical draft: draft-ietf-mip4-rfc3344bis priority: Should fix status: No discussion title: RFC 3344 - FHAE issue when using a different care-of address Issue: When the mobile node deregisters using the care-of address of=20 a different foreign agent than the foreign agent forwarding the dereg=20 request, the document is not consistent in its explanation as how the=20 HA and FA should handle such requests. Also, if the foreign agent is allowed to forward such requests, there is no explanation as how the home agent should locate the security=20 associations for that FA and validate the FHAE. Section: 3.8.2.2. Accepting a Valid Request In all cases, the home agent MUST send a Registration Reply to the source of the Registration Request, which might indeed be a different foreign agent than that whose care-of address is being (de)registered. If the home agent shares a mobility security association with the foreign agent whose care-of address is being deregistered, and that foreign agent is different from the one which relayed the Registration Request, the home agent MAY additionally send a Registration Reply to the foreign agent whose care-of address is being deregistered.=20 Section: 3.7.2.1. Validity Checks Requests with the 'D' bit set to 0, and specifying a care-of address=20 not offered by the foreign agent, MUST be rejected with code 77=20 (invalid care-of address). Explanation: When the MN sends a dereg request to a foreign agent with the intention=20 of deregistering its earlier binding it had with a different foreign agent, the behaviour of FA as documented in Section 3.7.2.1 is to reject such=20 requst with invalid care-of address error. However, the HA considerations (Section 3.8.2.2) allows such requests. The scenario is not handled=20 consistently at both HA and FA ends.=20 Also, if the foreign agent is allowed to forward such requests, there should be some explanation as how the FA should function when it receives a dereg message with "D" bit not set and care-of address set to the MN's home address (Deregister all bindings) or when its set to the care-of address of a different foreign agent. Assuming the FA is allowed to forward such a request and when there is security association configured between FA and the HA, the home agent will not be able to validate the FHAE. The home agent for validating the FHAE first needs to use COA address from the RRQ and use the SPI to locate the security associations. Given that the care-of address is set to either the home address of the mobile node or the care-of address of a different foreign agent, how should the HA validate the FHAE ? The HA cannot use the source address of the RRQ to locate the security associations as there could be NAT in the path. _________________________________________________ Mip4 issue tracker _________________________________________________ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Sat Mar 13 21:16:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10154 for ; Sat, 13 Mar 2004 20:30:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2KRi-0002pL-8y for mip4-archive@odin.ietf.org; Sat, 13 Mar 2004 20:29:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2E1Tg9X010861 for mip4-archive@odin.ietf.org; Sat, 13 Mar 2004 20:29:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2KRi-0002p6-5T for mip4-web-archive@optimus.ietf.org; Sat, 13 Mar 2004 20:29:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10130 for ; Sat, 13 Mar 2004 20:29:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2KRg-0000hp-00 for mip4-web-archive@ietf.org; Sat, 13 Mar 2004 20:29:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2KQk-0000dV-00 for mip4-web-archive@ietf.org; Sat, 13 Mar 2004 20:28:43 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2KQ5-0000ZD-00 for mip4-web-archive@ietf.org; Sat, 13 Mar 2004 20:28:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2KQ5-0002g5-2m; Sat, 13 Mar 2004 20:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1wEt-00026a-QF for mip4@optimus.ietf.org; Fri, 12 Mar 2004 18:38:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27992 for ; Fri, 12 Mar 2004 18:38:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1wEq-0000U5-00 for mip4@ietf.org; Fri, 12 Mar 2004 18:38:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1wDn-0000RC-00 for mip4@ietf.org; Fri, 12 Mar 2004 18:37:44 -0500 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=shiraz.levkowetz.com) by ietf-mx with esmtp (Exim 4.12) id 1B1wCp-0000Ms-00 for mip4@ietf.org; Fri, 12 Mar 2004 18:36:43 -0500 Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=h195n1fls311o871.telia.com) by shiraz.levkowetz.com with esmtp (Exim 3.35 #1 (Debian)) id 1B1wCk-0001mM-00 for ; Sat, 13 Mar 2004 00:36:38 +0100 Content-Type: text/plain; charset=utf-8 To: mip4@ietf.org From: Sri Gundavelli Reply-To: Mip4 issue tracker Date: Fri, 12 Mar 2004 23:36:28 +0000 MIME-Version: 1.0 Message-Id: <1079134588.32.0.608856945572.issue44@mip4.org> X-Roundup-Name: Mip4 issue tracker X-Roundup-Loop: hello Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [Mip4] [issue44] RFC 3344 - Source Address of the RRQ [Issue] Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable This has been entered in the issue tracker as issue 44. owner: Sri Gundavelli : category: Technical draft: draft-ietf-mip4-rfc3344bis priority: Must fix status: No discussion title: RFC 3344 - Source Address of the RRQ [Issue] RFC 3344: Section 3.7.2.2. Forwarding a Valid Request to the Home Agent "Specific fields within the IP header and the UDP header of the relayed Registration Request MUST be set as follows: IP Source Address The foreign agent's address on the interface from which the message will be sent." Per the above the text, the foreign agent is required to send the RRQ with the source address of the outgoing interface and this essentially conflicts with RFC 3519 (NAT Traversal) requirement. Per 3519, the foreign agent is required to set the source address of the RRQ to its care-of address, so that the home agent does not detect NAT incorrectly. The logic of NAT detection at the home agent is by comparing the source address of the RRQ to the care-of address in the RRQ's MIP header. So, we need to fix the text in 3344. There is no reason why the foreign agent MUST set the source address of the RRQ to the IP address of its outgoing interface. We should infact enforce the foreign agent to set the source address of the RRQ to the FA care of address. _________________________________________________ Mip4 issue tracker _________________________________________________ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Sat Mar 13 21:50:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13103 for ; Sat, 13 Mar 2004 21:50:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2LhA-0007UM-SW for mip4-archive@odin.ietf.org; Sat, 13 Mar 2004 21:49:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2E2nifs028783 for mip4-archive@odin.ietf.org; Sat, 13 Mar 2004 21:49:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2LhA-0007UA-JC for mip4-web-archive@optimus.ietf.org; Sat, 13 Mar 2004 21:49:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13089 for ; Sat, 13 Mar 2004 21:49:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2Lh7-0007YN-00 for mip4-web-archive@ietf.org; Sat, 13 Mar 2004 21:49:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2LgE-0007Tw-00 for mip4-web-archive@ietf.org; Sat, 13 Mar 2004 21:48:46 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2LfV-0007PU-00 for mip4-web-archive@ietf.org; Sat, 13 Mar 2004 21:48:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2LfU-0007K3-PB; Sat, 13 Mar 2004 21:48:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2LfI-0007GK-8s for mip4@optimus.ietf.org; Sat, 13 Mar 2004 21:47:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13052 for ; Sat, 13 Mar 2004 21:47:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2LfF-0007Oy-00 for mip4@ietf.org; Sat, 13 Mar 2004 21:47:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2Lea-0007KJ-00 for mip4@ietf.org; Sat, 13 Mar 2004 21:47:05 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1B2Le3-00078S-00 for mip4@ietf.org; Sat, 13 Mar 2004 21:46:31 -0500 Received: from ajamwal-u60.cisco.com (ajamwal-u60.cisco.com [128.107.132.155]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i2E2jx8Q004361; Sat, 13 Mar 2004 18:45:59 -0800 (PST) Date: Sat, 13 Mar 2004 18:45:59 -0800 (PST) From: Sri Gundavelli To: "Charles E. Perkins" cc: mip4@ietf.org In-Reply-To: <40524D34.5E628689@iprg.nokia.com> Message-ID: References: <40524D34.5E628689@iprg.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Mip4] Re: [Issue 44] RFC 3344 - Source Address of the RRQ Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi Charlie, I agree with the proposed text. Thanks ! Sri. On Fri, 12 Mar 2004, Charles E. Perkins wrote: > > Hello Sri, > > This is regarding the new Issue 44. It seems that we both > tried to insert this issue at about the same time, so that > your text appears twice. Or else, I don't understand just > how the darned issue tracker works... > > Anyway. here is the text revision I propose to > resolve this issue: > > Old text: > The foreign agent's address on the interface from which > the message will be sent. > > New text: > The care-of address offered by the foreign agent for > the mobile node sending the Registration Request. > > I believe it's possible for the foreign agent to offer > a multiplicity of care-of addresses, and I tried to > arrange it so that this text does not preclude that > possibility. > > Regards, > Charlie P. > > > > > ext Sri Gundavelli wrote: > > > > RFC 3344: > > Section 3.7.2.2. Forwarding a Valid Request to the Home Agent > > > > "Specific fields within the IP header and the UDP header of the > > relayed Registration Request MUST be set as follows: > > IP Source Address > > The foreign agent's address on the interface from which > > the message will be sent." > > > > Per the above the text, the foreign agent is required to send the RRQ > > with the source address of the outgoing interface and this essentially > > conflicts with RFC 3519 (NAT Traversal) requirement. Per 3519, the > > foreign agent is required to set the source address of the RRQ to its > > care-of address, so that the home agent does not detect NAT incorrectly. > > The logic of NAT detection at the home agent is by comparing the source > > address of the RRQ to the care-of address in the RRQ's MIP header. So, > > we need to fix the text in 3344. There is no reason why the foreign agent > > MUST set the source address of the RRQ to the IP address of its outgoing > > interface. We should infact enforce the foreign agent to set the source > > address of the RRQ to the FA care of address. > > > > Sri/ > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Sat Mar 13 22:14:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14425 for ; Sat, 13 Mar 2004 22:14:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2M4P-0000I8-2o for mip4-archive@odin.ietf.org; Sat, 13 Mar 2004 22:13:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2E3DjAh001114 for mip4-archive@odin.ietf.org; Sat, 13 Mar 2004 22:13:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2M4O-0000Hp-SL for mip4-web-archive@optimus.ietf.org; Sat, 13 Mar 2004 22:13:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14411 for ; Sat, 13 Mar 2004 22:13:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2M4L-0002Fe-00 for mip4-web-archive@ietf.org; Sat, 13 Mar 2004 22:13:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2M3R-0002BH-00 for mip4-web-archive@ietf.org; Sat, 13 Mar 2004 22:12:46 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2M2g-000275-00 for mip4-web-archive@ietf.org; Sat, 13 Mar 2004 22:11:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2M2i-0000CJ-TP; Sat, 13 Mar 2004 22:12:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2M2P-0000BO-My for mip4@optimus.ietf.org; Sat, 13 Mar 2004 22:11:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14326 for ; Sat, 13 Mar 2004 22:11:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2M2M-00025A-00 for mip4@ietf.org; Sat, 13 Mar 2004 22:11:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2M1Q-000202-00 for mip4@ietf.org; Sat, 13 Mar 2004 22:10:41 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B2M0U-0001ry-00 for mip4@ietf.org; Sat, 13 Mar 2004 22:09:42 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 13 Mar 2004 19:13:22 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i2E39AaD006545; Sat, 13 Mar 2004 19:09:11 -0800 (PST) Received: from cisco.com (stealth-10-32-246-212.cisco.com [10.32.246.212]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id ANE98099; Sat, 13 Mar 2004 19:09:09 -0800 (PST) Message-ID: <4053CCD5.FE977E69@cisco.com> Date: Sat, 13 Mar 2004 19:09:09 -0800 From: Sri Gundavelli X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Charles E. Perkins" CC: Naveen Paulkandasamy , mip4@ietf.org Subject: Re: [Mip4] Re: [Issue 45] RFC 3344 - FHAE issue when using a different careofaddress References: <405258AA.10FC70EF@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Charlie, Please see my comments below ... Regards ! Sri. "Charles E. Perkins" wrote: > Hello again Sri, > > Thanks for submitting this issue. I think it points to > several revisions that are needed to rfc3344bis. > For a good resolution, I think it helps if we specify > that the source address of the RREQ is the care-of address > offered by the foreign agent, so please assume that for > my discussion below. > > > Issue: When the mobile node deregisters using the care-of address of > > a different foreign agent than the foreign agent forwarding the dereg > > request, the document is not consistent in its explanation as how the > > HA and FA should handle such requests. > > Unfortunately true. > > > Also, if the foreign agent is allowed to forward such requests, there > > is no explanation as how the home agent should locate the security > > associations for that FA and validate the FHAE. > > Presumably, this depends on the address used by the > foreign agent. Let's say it's the care-of address. > Also, please note that the document doesn't have much > to say about mobility security assocations except in > the case of the mobile node. It is expected that the > home agent knows how to apply whatever algorithm has > been preconfigured between itself and the foreign > agent, which is not hard to imagine. We might as > well go one step further and assume that the > mobility security association depends on the > foreign agent's care-of address, and that home > agent uses that address to index into its security > database along with the SPI as presented by the > foreign agent. In fact, I believe the SPI itself > "should" be sufficient for the purpose, but we > don't have to hold the Mobile IP document up while > waiting to resolve _that_ point. > I'm not sure if we should just assume the home agent will some how identify the security association for validating the FHAE. In this scenario, the home agent would have no means to identify the mobility entity that is forwarding the request. Home agent cannot use the care-of address for indexing the security association as it is a dereg request from a mobile node for a binding it obtained thru a different foreign agent. Home agent cannot also use the source address of the registration request for the security association lookup, as the address could potentially be a NAT gateway address, scenario supported by RFC 3519. SPI alone is not sufficient for any entity to identify the security association. It is always with in the context of two entities. If the home agent cannot always identify the peer using the source address or care-of address of the dereg request, then the home agent would not be able to locate the security association. I agree, it is a difficult problem to solve. But, we have to document this special case and provide some guidance as how to deal with it. > > > Section: 3.8.2.2. Accepting a Valid Request > > > > In all cases, the home agent MUST send a Registration Reply to the > > source of the Registration Request, which might indeed be a different > > foreign agent than that whose care-of address is being > > (de)registered. If the home agent shares a mobility security > > association with the foreign agent whose care-of address is being > > deregistered, and that foreign agent is different from the one which > > relayed the Registration Request, the home agent MAY additionally > > send a Registration Reply to the foreign agent whose care-of address > > is being deregistered. > > > > Section: 3.7.2.1. Validity Checks > > > > Requests with the 'D' bit set to 0, and specifying a care-of address > > not offered by the foreign agent, MUST be rejected with code 77 > > (invalid care-of address). > > This documents the inconsistency. > > > When the MN sends a dereg request to a foreign agent with the intention > > of deregistering its earlier binding it had with a different foreign agent, > > the behaviour of FA as documented in Section 3.7.2.1 is to reject such > > requst with invalid care-of address error. However, the HA considerations > > (Section 3.8.2.2) allows such requests. The scenario is not handled > > consistently at both HA and FA ends. > > Suggested resolution: amend the paragraph in section 3.7.2.1 > as follows: > > Requests with the 'D' bit set to 0, nonzero lifetime, and > specifying a care-of address not offered by the foreign agent, > MUST be rejected with code 77 (invalid care-of address). > > This just adds a "nonzero lifetime" conditional which is then > needed to trigger a mandated rejection. > Ok. This should fix the home agent and foreign agent behavior inconsistency with respect to the above problem. > > > Also, if the foreign agent is allowed to forward such requests, there > > should be some explanation as how the FA should function when it > > receives a dereg message with "D" bit not set and care-of address > > set to the MN's home address (Deregister all bindings) or when its > > set to the care-of address of a different foreign agent. Assuming the > > FA is allowed to forward such a request and when there is security > > association configured between FA and the HA, the home agent will not > > be able to validate the FHAE. > > With the above, the FA is allowed to forward the request. With > the proposed resolution of Issue 44, the IP address in the IP > header will be a care-of address offered by the sending foreign > agent. Then, the home agent can verify the FHAE, with the above > proviso that the foreign-home mobility security association is > preconfigured just that way. The proposed text above (with non-zero lifetime) fixes the inconsistency. But, now that the FA is allowed to forward the request, we still would have the problem of home agent not being able to verify the FHAE in all scenarios. > > > The home agent for validating the FHAE > > first needs to use COA address from the RRQ and use the SPI to locate > > the security associations. Given that the care-of address is set to > > either the home address of the mobile node or the care-of address of > > a different foreign agent, how should the HA validate the FHAE ? The > > HA cannot use the source address of the RRQ to locate the security > > associations as there could be NAT in the path. > > Well, I guess we are agreeing that the security association used > to validate the Foreign-Home Authentication Extension is indexed > by the source IP address. That information needs to be supplied > in section 3.5.4. Here is some proposed text: > Not sure. If the source address is used to index the security association, for validating the FHAE, it will fail in the NAT scenario. > > In order to perform the authentication, the Home Agent and the > Foreign Agent have to have configured a security association that > is able to be indexed by use of the SPI and the care-of address > assocated with the Foreign Agent. This care-of address MUST > be used as the Source IP address of the Registration Request > containing the Foreign-Home Authentication Extension. When > the extension is used with a Registration Reply message, the > foreign agent address MUST be used as the Destination IP > address in the IP header. > > Please let me know if I have sufficiently understood the issue, > and if my proposed revisions clear up the inconsistencies. > > Regards, > Charlie P. > > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Mon Mar 15 06:46:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21851 for ; Mon, 15 Mar 2004 06:46:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2qXU-0002S7-Bw for mip4-archive@odin.ietf.org; Mon, 15 Mar 2004 06:45:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2FBjmxV009423 for mip4-archive@odin.ietf.org; Mon, 15 Mar 2004 06:45:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2qXU-0002Ru-6x for mip4-web-archive@optimus.ietf.org; Mon, 15 Mar 2004 06:45:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21845 for ; Mon, 15 Mar 2004 06:45:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2qXQ-0000fO-00 for mip4-web-archive@ietf.org; Mon, 15 Mar 2004 06:45:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2qWW-0000ZQ-00 for mip4-web-archive@ietf.org; Mon, 15 Mar 2004 06:44:49 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2qVj-0000T4-00 for mip4-web-archive@ietf.org; Mon, 15 Mar 2004 06:43:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2qVl-0002L1-4M; Mon, 15 Mar 2004 06:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2qVX-0002Ka-86 for mip4@optimus.ietf.org; Mon, 15 Mar 2004 06:43:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21819 for ; Mon, 15 Mar 2004 06:43:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2qVT-0000RW-00 for mip4@ietf.org; Mon, 15 Mar 2004 06:43:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2qUZ-0000Lg-00 for mip4@ietf.org; Mon, 15 Mar 2004 06:42:49 -0500 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 1B2qTu-00008h-00 for mip4@ietf.org; Mon, 15 Mar 2004 06:42:06 -0500 Received: from pcfrej (rd4.ipunplugged.com [213.80.52.85]) by mailgw.local.ipunplugged.com (8.12.8/8.12.3) with SMTP id i2FBfJjw017867; Mon, 15 Mar 2004 12:41:21 +0100 From: "Fredrik Johansson" To: "Sri Gundavelli" , "Charles E. Perkins" Cc: "Naveen Paulkandasamy" , Subject: RE: [Mip4] Re: [Issue 45] RFC 3344 - FHAE issue when using a different careofaddress Date: Mon, 15 Mar 2004 12:41:29 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <4053CCD5.FE977E69@cisco.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.66', clamav-milter version '0.66m' Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sri, Just a small question. Why would the MN send a deregistration for a CoA that it previously had, instead it should send a registration for the new CoA which would automatically cause the tunnel to the previous CoA to be terminated. This means that the HA will terminate its side of the tunnel towards the old FA, the old FA must wait for a timeout or if it supports revocation the HA can send a revocation. This means that the HA can allways use the CoA when it does a lookup for the SA and then the SPI to find the Security Context within that SA. As you say, using the source address is not good since there might be a NAT inbetween. /Fredrik -----Original Message----- From: mip4-admin@ietf.org [mailto:mip4-admin@ietf.org]On Behalf Of Sri Gundavelli Sent: den 14 mars 2004 04:09 To: Charles E. Perkins Cc: Naveen Paulkandasamy; mip4@ietf.org Subject: Re: [Mip4] Re: [Issue 45] RFC 3344 - FHAE issue when using a different careofaddress Hi Charlie, Please see my comments below ... Regards ! Sri. "Charles E. Perkins" wrote: > Hello again Sri, > > Thanks for submitting this issue. I think it points to > several revisions that are needed to rfc3344bis. > For a good resolution, I think it helps if we specify > that the source address of the RREQ is the care-of address > offered by the foreign agent, so please assume that for > my discussion below. > > > Issue: When the mobile node deregisters using the care-of address of > > a different foreign agent than the foreign agent forwarding the dereg > > request, the document is not consistent in its explanation as how the > > HA and FA should handle such requests. > > Unfortunately true. > > > Also, if the foreign agent is allowed to forward such requests, there > > is no explanation as how the home agent should locate the security > > associations for that FA and validate the FHAE. > > Presumably, this depends on the address used by the > foreign agent. Let's say it's the care-of address. > Also, please note that the document doesn't have much > to say about mobility security assocations except in > the case of the mobile node. It is expected that the > home agent knows how to apply whatever algorithm has > been preconfigured between itself and the foreign > agent, which is not hard to imagine. We might as > well go one step further and assume that the > mobility security association depends on the > foreign agent's care-of address, and that home > agent uses that address to index into its security > database along with the SPI as presented by the > foreign agent. In fact, I believe the SPI itself > "should" be sufficient for the purpose, but we > don't have to hold the Mobile IP document up while > waiting to resolve _that_ point. > I'm not sure if we should just assume the home agent will some how identify the security association for validating the FHAE. In this scenario, the home agent would have no means to identify the mobility entity that is forwarding the request. Home agent cannot use the care-of address for indexing the security association as it is a dereg request from a mobile node for a binding it obtained thru a different foreign agent. Home agent cannot also use the source address of the registration request for the security association lookup, as the address could potentially be a NAT gateway address, scenario supported by RFC 3519. SPI alone is not sufficient for any entity to identify the security association. It is always with in the context of two entities. If the home agent cannot always identify the peer using the source address or care-of address of the dereg request, then the home agent would not be able to locate the security association. I agree, it is a difficult problem to solve. But, we have to document this special case and provide some guidance as how to deal with it. > > > Section: 3.8.2.2. Accepting a Valid Request > > > > In all cases, the home agent MUST send a Registration Reply to the > > source of the Registration Request, which might indeed be a different > > foreign agent than that whose care-of address is being > > (de)registered. If the home agent shares a mobility security > > association with the foreign agent whose care-of address is being > > deregistered, and that foreign agent is different from the one which > > relayed the Registration Request, the home agent MAY additionally > > send a Registration Reply to the foreign agent whose care-of address > > is being deregistered. > > > > Section: 3.7.2.1. Validity Checks > > > > Requests with the 'D' bit set to 0, and specifying a care-of address > > not offered by the foreign agent, MUST be rejected with code 77 > > (invalid care-of address). > > This documents the inconsistency. > > > When the MN sends a dereg request to a foreign agent with the intention > > of deregistering its earlier binding it had with a different foreign agent, > > the behaviour of FA as documented in Section 3.7.2.1 is to reject such > > requst with invalid care-of address error. However, the HA considerations > > (Section 3.8.2.2) allows such requests. The scenario is not handled > > consistently at both HA and FA ends. > > Suggested resolution: amend the paragraph in section 3.7.2.1 > as follows: > > Requests with the 'D' bit set to 0, nonzero lifetime, and > specifying a care-of address not offered by the foreign agent, > MUST be rejected with code 77 (invalid care-of address). > > This just adds a "nonzero lifetime" conditional which is then > needed to trigger a mandated rejection. > Ok. This should fix the home agent and foreign agent behavior inconsistency with respect to the above problem. > > > Also, if the foreign agent is allowed to forward such requests, there > > should be some explanation as how the FA should function when it > > receives a dereg message with "D" bit not set and care-of address > > set to the MN's home address (Deregister all bindings) or when its > > set to the care-of address of a different foreign agent. Assuming the > > FA is allowed to forward such a request and when there is security > > association configured between FA and the HA, the home agent will not > > be able to validate the FHAE. > > With the above, the FA is allowed to forward the request. With > the proposed resolution of Issue 44, the IP address in the IP > header will be a care-of address offered by the sending foreign > agent. Then, the home agent can verify the FHAE, with the above > proviso that the foreign-home mobility security association is > preconfigured just that way. The proposed text above (with non-zero lifetime) fixes the inconsistency. But, now that the FA is allowed to forward the request, we still would have the problem of home agent not being able to verify the FHAE in all scenarios. > > > The home agent for validating the FHAE > > first needs to use COA address from the RRQ and use the SPI to locate > > the security associations. Given that the care-of address is set to > > either the home address of the mobile node or the care-of address of > > a different foreign agent, how should the HA validate the FHAE ? The > > HA cannot use the source address of the RRQ to locate the security > > associations as there could be NAT in the path. > > Well, I guess we are agreeing that the security association used > to validate the Foreign-Home Authentication Extension is indexed > by the source IP address. That information needs to be supplied > in section 3.5.4. Here is some proposed text: > Not sure. If the source address is used to index the security association, for validating the FHAE, it will fail in the NAT scenario. > > In order to perform the authentication, the Home Agent and the > Foreign Agent have to have configured a security association that > is able to be indexed by use of the SPI and the care-of address > assocated with the Foreign Agent. This care-of address MUST > be used as the Source IP address of the Registration Request > containing the Foreign-Home Authentication Extension. When > the extension is used with a Registration Reply message, the > foreign agent address MUST be used as the Destination IP > address in the IP header. > > Please let me know if I have sufficiently understood the issue, > and if my proposed revisions clear up the inconsistencies. > > Regards, > Charlie P. > > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Mon Mar 15 09:02:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27942 for ; Mon, 15 Mar 2004 09:02:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2sfE-0005E0-Qw for mip4-archive@odin.ietf.org; Mon, 15 Mar 2004 09:01:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2FE1uB3020073 for mip4-archive@odin.ietf.org; Mon, 15 Mar 2004 09:01:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2sfD-0005Dg-V8 for mip4-web-archive@optimus.ietf.org; Mon, 15 Mar 2004 09:01:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27930 for ; Mon, 15 Mar 2004 09:01:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2sfC-00039j-00 for mip4-web-archive@ietf.org; Mon, 15 Mar 2004 09:01:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2seF-00032p-00 for mip4-web-archive@ietf.org; Mon, 15 Mar 2004 09:00:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2sdR-0002we-00 for mip4-web-archive@ietf.org; Mon, 15 Mar 2004 09:00:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2sdQ-000573-35; Mon, 15 Mar 2004 09:00:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2sdD-00056C-Vb for mip4@optimus.ietf.org; Mon, 15 Mar 2004 08:59:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27872 for ; Mon, 15 Mar 2004 08:59:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2sdC-0002vf-00 for mip4@ietf.org; Mon, 15 Mar 2004 08:59:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2scC-0002mZ-00 for mip4@ietf.org; Mon, 15 Mar 2004 08:58:49 -0500 Received: from ceiling.dave.sonera.fi ([131.177.130.26]) by ietf-mx with esmtp (Exim 4.12) id 1B2saV-0002fb-00 for mip4@ietf.org; Mon, 15 Mar 2004 08:57:03 -0500 Received: from ceiling.dave.sonera.fi (localhost [127.0.0.1]) by ceiling.dave.sonera.fi (Sendmail) with ESMTP id i2FDv1N8022429 for ; Mon, 15 Mar 2004 15:57:02 +0200 (EET) Received: from ASSI.eur.soneragroup.net (tellu.eur.soneragroup.net [131.177.121.206]) by ceiling.dave.sonera.fi (Sendmail) with ESMTP id i2FDuwsk022369 for ; Mon, 15 Mar 2004 15:57:01 +0200 (EET) x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] Re: [Issue 45] RFC 3344 - FHAE issue when using a different careofaddress Date: Mon, 15 Mar 2004 15:56:38 +0200 Message-ID: Thread-Topic: [Mip4] Re: [Issue 45] RFC 3344 - FHAE issue when using a different careofaddress Thread-Index: AcQKgt1GfkFC802DQLiMZZusIZjupwAEjRkA From: "Korhonen Jouni" To: Content-Transfer-Encoding: quoted-printable Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Is it just me who receives all MIP4 mailing list messages twice? It started to behave like this last week. br, Jouni --=20 Jouni Korhonen - Senior Researcher Emerging Technologies and Innovations TeliaSonera Finland =20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Mon Mar 15 10:24:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03038 for ; Mon, 15 Mar 2004 10:24:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2twg-00044j-3P for mip4-archive@odin.ietf.org; Mon, 15 Mar 2004 10:24:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2FFO2Hi015658 for mip4-archive@odin.ietf.org; Mon, 15 Mar 2004 10:24:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2twf-00044T-SC for mip4-web-archive@optimus.ietf.org; Mon, 15 Mar 2004 10:24:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02973 for ; Mon, 15 Mar 2004 10:23:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2twd-0006Ep-00 for mip4-web-archive@ietf.org; Mon, 15 Mar 2004 10:23:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2tvg-00067F-00 for mip4-web-archive@ietf.org; Mon, 15 Mar 2004 10:23:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2tui-00060c-00 for mip4-web-archive@ietf.org; Mon, 15 Mar 2004 10:22:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2tuj-0003Og-59; Mon, 15 Mar 2004 10:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2ttn-0003HD-HW for mip4@optimus.ietf.org; Mon, 15 Mar 2004 10:21:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02645 for ; Mon, 15 Mar 2004 10:20:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2ttl-0005tq-00 for mip4@ietf.org; Mon, 15 Mar 2004 10:21:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2tsw-0005nO-00 for mip4@ietf.org; Mon, 15 Mar 2004 10:20:11 -0500 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 1B2tsU-0005g2-00 for mip4@ietf.org; Mon, 15 Mar 2004 10:19:42 -0500 Received: from zinfandel.local.ipunplugged.com (chardonnay.local.ipunplugged.com [192.168.4.44]) by mailgw.local.ipunplugged.com (8.12.8/8.12.3) with SMTP id i2FFJBjv023154; Mon, 15 Mar 2004 16:19:11 +0100 Date: Mon, 15 Mar 2004 16:19:09 +0100 From: Henrik Levkowetz To: "Korhonen Jouni" Cc: Subject: Re: [Mip4] Re: [Issue 45] RFC 3344 - FHAE issue when using a different careofaddress Message-Id: <20040315161909.34d6dcc5.henrik@levkowetz.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.66', clamav-milter version '0.66m' Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Jouni, On Monday, 15 Mar 2004, Korhonen Jouni wrote: > Is it just me who receives all MIP4 mailing list messages twice? > It started to behave like this last week. I don't see this behaviour here, so the trouble might be at your end. Henrik -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Mon Mar 15 11:36:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08753 for ; Mon, 15 Mar 2004 11:36:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2v4I-0003ID-Pk for mip4-archive@odin.ietf.org; Mon, 15 Mar 2004 11:35:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2FGZw6L012656 for mip4-archive@odin.ietf.org; Mon, 15 Mar 2004 11:35:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2v4I-0003I3-GI for mip4-web-archive@optimus.ietf.org; Mon, 15 Mar 2004 11:35:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08704 for ; Mon, 15 Mar 2004 11:35:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2v4H-0001yp-00 for mip4-web-archive@ietf.org; Mon, 15 Mar 2004 11:35:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2v3J-0001pg-00 for mip4-web-archive@ietf.org; Mon, 15 Mar 2004 11:34:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2v2P-0001hw-00 for mip4-web-archive@ietf.org; Mon, 15 Mar 2004 11:34:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2v2P-0002sz-18; Mon, 15 Mar 2004 11:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2v1a-0002r4-CH for mip4@optimus.ietf.org; Mon, 15 Mar 2004 11:33:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08620 for ; Mon, 15 Mar 2004 11:33:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2v1Z-0001ar-00 for mip4@ietf.org; Mon, 15 Mar 2004 11:33:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2v0f-0001TN-00 for mip4@ietf.org; Mon, 15 Mar 2004 11:32:15 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1B2v0G-0001LN-00 for mip4@ietf.org; Mon, 15 Mar 2004 11:31:48 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 15 Mar 2004 08:31:43 -0800 Received: from mira-sjc5-f.cisco.com (IDENT:mirapoint@mira-sjc5-f.cisco.com [171.71.163.13]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i2FGV7WK023027; Mon, 15 Mar 2004 08:31:07 -0800 (PST) Received: from cisco.com (sjc-vpn3-649.cisco.com [10.21.66.137]) by mira-sjc5-f.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQC69492; Mon, 15 Mar 2004 08:31:05 -0800 (PST) Message-ID: <4055DA3C.8070003@cisco.com> Date: Mon, 15 Mar 2004 08:30:52 -0800 From: Naveen PaulKandasamy User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fredrik Johansson CC: Sri Gundavelli , "Charles E. Perkins" , mip4@ietf.org Subject: Re: [Mip4] Re: [Issue 45] RFC 3344 - FHAE issue when using a different careofaddress References: Content-Type: multipart/alternative; boundary="------------080403060405040607080400" Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=HTML_MESSAGE,HTML_TITLE_EMPTY autolearn=no version=2.60 --------------080403060405040607080400 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Fredrik, please see inline... Fredrik Johansson wrote: >Sri, > >Just a small question. Why would the MN send a deregistration for a CoA that >it previously had, instead it should send a registration for the new CoA >which would automatically cause the tunnel to the previous CoA to be >terminated. > I think, this is true only for the case where the MN is not requesting simultaneous bindings ? thanks, naveen. > >This means that the HA will terminate its side of the tunnel towards the old >FA, the old FA must wait for a timeout or if it supports revocation the HA >can send a revocation. This means that the HA can allways use the CoA when >it does a lookup for the SA and then the SPI to find the Security Context >within that SA. As you say, using the source address is not good since there >might be a NAT inbetween. > >/Fredrik > >-----Original Message----- >From: mip4-admin@ietf.org [mailto:mip4-admin@ietf.org]On Behalf Of Sri >Gundavelli >Sent: den 14 mars 2004 04:09 >To: Charles E. Perkins >Cc: Naveen Paulkandasamy; mip4@ietf.org >Subject: Re: [Mip4] Re: [Issue 45] RFC 3344 - FHAE issue when using a >different careofaddress > > >Hi Charlie, > Please see my comments below ... > >Regards ! >Sri. > >"Charles E. Perkins" wrote: > > > >>Hello again Sri, >> >>Thanks for submitting this issue. I think it points to >>several revisions that are needed to rfc3344bis. >>For a good resolution, I think it helps if we specify >>that the source address of the RREQ is the care-of address >>offered by the foreign agent, so please assume that for >>my discussion below. >> >> >> >>> Issue: When the mobile node deregisters using the care-of address of >>> a different foreign agent than the foreign agent forwarding the dereg >>> request, the document is not consistent in its explanation as how the >>> HA and FA should handle such requests. >>> >>> >>Unfortunately true. >> >> >> >>> Also, if the foreign agent is allowed to forward such requests, there >>> is no explanation as how the home agent should locate the security >>> associations for that FA and validate the FHAE. >>> >>> >>Presumably, this depends on the address used by the >>foreign agent. Let's say it's the care-of address. >>Also, please note that the document doesn't have much >>to say about mobility security assocations except in >>the case of the mobile node. It is expected that the >>home agent knows how to apply whatever algorithm has >>been preconfigured between itself and the foreign >>agent, which is not hard to imagine. We might as >>well go one step further and assume that the >>mobility security association depends on the >>foreign agent's care-of address, and that home >>agent uses that address to index into its security >>database along with the SPI as presented by the >>foreign agent. In fact, I believe the SPI itself >>"should" be sufficient for the purpose, but we >>don't have to hold the Mobile IP document up while >>waiting to resolve _that_ point. >> >> >> > >I'm not sure if we should just assume the home agent will some >how identify the security association for validating the FHAE. In >this scenario, the home agent would have no means to identify >the mobility entity that is forwarding the request. Home agent >cannot use the care-of address for indexing the security association >as it is a dereg request from a mobile node for a binding it obtained >thru a different foreign agent. Home agent cannot also use the >source address of the registration request for the security >association lookup, as the address could potentially be a NAT >gateway address, scenario supported by RFC 3519. > >SPI alone is not sufficient for any entity to identify the security >association. It is always with in the context of two entities. If the >home agent cannot always identify the peer using the source >address or care-of address of the dereg request, then the home >agent would not be able to locate the security association. > >I agree, it is a difficult problem to solve. But, we have to document >this special case and provide some guidance as how to deal with it. > > > > >>> Section: 3.8.2.2. Accepting a Valid Request >>> >>> In all cases, the home agent MUST send a Registration Reply to the >>> source of the Registration Request, which might indeed be a >>> >>> >different > > >>> foreign agent than that whose care-of address is being >>> (de)registered. If the home agent shares a mobility security >>> association with the foreign agent whose care-of address is being >>> deregistered, and that foreign agent is different from the one which >>> relayed the Registration Request, the home agent MAY additionally >>> send a Registration Reply to the foreign agent whose care-of address >>> is being deregistered. >>> >>> Section: 3.7.2.1. Validity Checks >>> >>> Requests with the 'D' bit set to 0, and specifying a care-of address >>> not offered by the foreign agent, MUST be rejected with code 77 >>> (invalid care-of address). >>> >>> >>This documents the inconsistency. >> >> >> >>> When the MN sends a dereg request to a foreign agent with the intention >>> of deregistering its earlier binding it had with a different foreign >>> >>> >agent, > > >>> the behaviour of FA as documented in Section 3.7.2.1 is to reject such >>> requst with invalid care-of address error. However, the HA >>> >>> >considerations > > >>> (Section 3.8.2.2) allows such requests. The scenario is not handled >>> consistently at both HA and FA ends. >>> >>> >>Suggested resolution: amend the paragraph in section 3.7.2.1 >>as follows: >> >> Requests with the 'D' bit set to 0, nonzero lifetime, and >> specifying a care-of address not offered by the foreign agent, >> MUST be rejected with code 77 (invalid care-of address). >> >>This just adds a "nonzero lifetime" conditional which is then >>needed to trigger a mandated rejection. >> >> >> > >Ok. This should fix the home agent and foreign agent behavior >inconsistency with respect to the above problem. > > > > > >>> Also, if the foreign agent is allowed to forward such requests, there >>> should be some explanation as how the FA should function when it >>> receives a dereg message with "D" bit not set and care-of address >>> set to the MN's home address (Deregister all bindings) or when its >>> set to the care-of address of a different foreign agent. Assuming the >>> FA is allowed to forward such a request and when there is security >>> association configured between FA and the HA, the home agent will not >>> be able to validate the FHAE. >>> >>> >>With the above, the FA is allowed to forward the request. With >>the proposed resolution of Issue 44, the IP address in the IP >>header will be a care-of address offered by the sending foreign >>agent. Then, the home agent can verify the FHAE, with the above >>proviso that the foreign-home mobility security association is >>preconfigured just that way. >> >> > >The proposed text above (with non-zero lifetime) fixes the inconsistency. >But, now that the FA is allowed to forward the request, we still would have >the problem of home agent not being able to verify the FHAE in all >scenarios. > > > > >>> The home agent for validating the FHAE >>> first needs to use COA address from the RRQ and use the SPI to locate >>> the security associations. Given that the care-of address is set to >>> either the home address of the mobile node or the care-of address of >>> a different foreign agent, how should the HA validate the FHAE ? The >>> HA cannot use the source address of the RRQ to locate the security >>> associations as there could be NAT in the path. >>> >>> >>Well, I guess we are agreeing that the security association used >>to validate the Foreign-Home Authentication Extension is indexed >>by the source IP address. That information needs to be supplied >>in section 3.5.4. Here is some proposed text: >> >> >> > >Not sure. If the source address is used to index the security association, >for validating the FHAE, it will fail in the NAT scenario. > > > > >> In order to perform the authentication, the Home Agent and the >> Foreign Agent have to have configured a security association that >> is able to be indexed by use of the SPI and the care-of address >> assocated with the Foreign Agent. This care-of address MUST >> be used as the Source IP address of the Registration Request >> containing the Foreign-Home Authentication Extension. When >> the extension is used with a Registration Reply message, the >> foreign agent address MUST be used as the Destination IP >> address in the IP header. >> >>Please let me know if I have sufficiently understood the issue, >>and if my proposed revisions clear up the inconsistencies. >> >>Regards, >>Charlie P. >> >>-- >>Mip4 mailing list: Mip4@ietf.org >> Web interface: https://www.ietf.org/mailman/listinfo/mip4 >> Charter page: http://www.ietf.org/html.charters/mip4-charter.html >>Supplemental site: http://www.mip4.org/ >> >> > > >-- >Mip4 mailing list: Mip4@ietf.org > Web interface: https://www.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html >Supplemental site: http://www.mip4.org/ > > > > > --------------080403060405040607080400 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Fredrik,

please see inline...

Fredrik Johansson wrote:
Sri,

Just a small question. Why would the MN send a deregistration for a CoA that
it previously had, instead it should send a registration for the new CoA
which would automatically cause the tunnel to the previous CoA to be
terminated.

I think, this is true only for the case where the MN is not requesting simultaneous bindings ?

thanks,
naveen.


This means that the HA will terminate its side of the tunnel towards the old
FA, the old FA must wait for a timeout or if it supports revocation the HA
can send a revocation. This means that the HA can allways use the CoA when
it does a lookup for the SA and then the SPI to find the Security Context
within that SA. As you say, using the source address is not good since there
might be a NAT inbetween.

/Fredrik

-----Original Message-----
From: mip4-admin@ietf.org [mailto:mip4-admin@ietf.org]On Behalf Of Sri
Gundavelli
Sent: den 14 mars 2004 04:09
To: Charles E. Perkins
Cc: Naveen Paulkandasamy; mip4@ietf.org
Subject: Re: [Mip4] Re: [Issue 45] RFC 3344 - FHAE issue when using a
different careofaddress


Hi Charlie,
                 Please see my comments below ...

Regards !
Sri.

"Charles E. Perkins" wrote:

  
Hello again Sri,

Thanks for submitting this issue.  I think it points to
several revisions that are needed to rfc3344bis.
For a good resolution, I think it helps if we specify
that the source address of the RREQ is the care-of address
offered by the foreign agent, so please assume that for
my discussion below.

    
 Issue: When the mobile node deregisters using the care-of address of
 a different foreign agent than the foreign agent forwarding the dereg
 request, the document is not consistent in its explanation as how the
 HA and FA should handle such requests.
      
Unfortunately true.

    
 Also, if the foreign agent is allowed to forward such requests, there
 is no explanation as how the home agent should locate the security
 associations for that FA and validate the FHAE.
      
Presumably, this depends on the address used by the
foreign agent.  Let's say it's the care-of address.
Also, please note that the document doesn't have much
to say about mobility security assocations except in
the case of the mobile node.  It is expected that the
home agent knows how to apply whatever algorithm has
been preconfigured between itself and the foreign
agent, which is not hard to imagine.  We might as
well go one step further and assume that the
mobility security association depends on the
foreign agent's care-of address, and that home
agent uses that address to index into its security
database along with the SPI as presented by the
foreign agent.  In fact, I believe the SPI itself
"should" be sufficient for the purpose, but we
don't have to hold the Mobile IP document up while
waiting to resolve _that_ point.

    

I'm not sure if we should just assume the home agent will some
how identify the security association for validating the FHAE. In
this scenario,  the home agent would have no means to identify
the mobility entity that is forwarding the request. Home agent
cannot use the care-of address for indexing the security association
as it is a dereg request from a mobile node for a binding it obtained
thru a different foreign agent. Home agent cannot also use the
source address of the registration request for the security
association lookup, as the address could potentially be a NAT
gateway address,  scenario supported by RFC 3519.

SPI alone is not sufficient for any entity to identify the security
association. It is always with in the context of two entities. If the
home agent cannot always identify the peer using the source
address or care-of address of the dereg request, then the home
agent would not be able to locate the security association.

I agree, it is a difficult problem to solve. But, we have to document
this special case and provide some guidance as how to deal with it.


  
 Section: 3.8.2.2. Accepting a Valid Request

    In all cases, the home agent MUST send a Registration Reply to the
    source of the Registration Request, which might indeed be a
      
different
  
    foreign agent than that whose care-of address is being
    (de)registered.  If the home agent shares a mobility security
    association with the foreign agent whose care-of address is being
    deregistered, and that foreign agent is different from the one which
    relayed the Registration Request, the home agent MAY additionally
    send a Registration Reply to the foreign agent whose care-of address
    is being deregistered.

 Section: 3.7.2.1. Validity Checks

    Requests with the 'D' bit set to 0, and specifying a care-of address
    not offered by the foreign agent, MUST be rejected with code 77
    (invalid care-of address).
      
This documents the inconsistency.

    
 When the MN sends a dereg request to a foreign agent with the intention
 of deregistering its earlier binding it had with a different foreign
      
agent,
  
 the behaviour of FA as documented in Section 3.7.2.1 is to reject such
 requst with invalid care-of address error. However, the HA
      
considerations
  
 (Section 3.8.2.2) allows such requests. The scenario is not handled
 consistently at both HA and FA ends.
      
Suggested resolution: amend the paragraph in section 3.7.2.1
as follows:

     Requests with the 'D' bit set to 0, nonzero lifetime, and
     specifying a care-of address not offered by the foreign agent,
     MUST be rejected with code 77 (invalid care-of address).

This just adds a "nonzero lifetime" conditional which is then
needed to trigger a mandated rejection.

    

Ok. This should fix the home agent and foreign agent behavior
inconsistency with respect to the above problem.



  
 Also, if the foreign agent is allowed to forward such requests, there
 should be some explanation as how the FA should function when it
 receives a dereg message with "D" bit not set and care-of address
 set to the MN's home address (Deregister all bindings) or when its
 set to the care-of address of a different foreign agent. Assuming the
 FA is allowed to forward such a request and when there is security
 association configured between FA and the HA, the home agent will not
 be able to validate the FHAE.
      
With the above, the FA is allowed to forward the request.  With
the proposed resolution of Issue 44, the IP address in the IP
header will be a care-of address offered by the sending foreign
agent.  Then, the home agent can verify the FHAE, with the above
proviso that the foreign-home mobility security association is
preconfigured just that way.
    

The proposed text above (with non-zero lifetime)  fixes the inconsistency.
But, now that the FA is allowed to forward the request, we still would have
the problem of home agent not being able to verify the FHAE in all
scenarios.


  
                                The home agent for validating the FHAE
 first needs to use COA address from the RRQ and use the SPI to locate
 the security associations. Given that the care-of address is set to
 either the home address of the mobile node or the care-of address of
 a different foreign agent, how should the HA validate the FHAE ? The
 HA cannot use the source address of the RRQ to locate the security
 associations as there could be NAT in the path.
      
Well, I guess we are agreeing that the security association used
to validate the Foreign-Home Authentication Extension is indexed
by the source IP address.  That information needs to be supplied
in section 3.5.4.  Here is some proposed text:

    

Not sure. If  the source address is used to index the security association,
for validating the FHAE, it will fail in the NAT scenario.


  
   In order to perform the authentication, the Home Agent and the
   Foreign Agent have to have configured a security association that
   is able to be indexed by use of the SPI and the care-of address
   assocated with the Foreign Agent.  This care-of address MUST
   be used as the Source IP address of the Registration Request
   containing the Foreign-Home Authentication Extension.  When
   the extension is used with a Registration Reply message, the
   foreign agent address MUST be used as the Destination IP
   address in the IP header.

Please let me know if I have sufficiently understood the issue,
and if my proposed revisions clear up the inconsistencies.

Regards,
Charlie P.

--
Mip4 mailing list: Mip4@ietf.org
    Web interface: https://www.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/
    


--
Mip4 mailing list: Mip4@ietf.org
    Web interface: https://www.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

--------------080403060405040607080400-- -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Mon Mar 15 12:08:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10416 for ; Mon, 15 Mar 2004 12:08:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2vZI-0007Sy-Id for mip4-archive@odin.ietf.org; Mon, 15 Mar 2004 12:08:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2FH80XO028686 for mip4-archive@odin.ietf.org; Mon, 15 Mar 2004 12:08:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2vZI-0007Sb-1t for mip4-web-archive@optimus.ietf.org; Mon, 15 Mar 2004 12:08:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10389 for ; Mon, 15 Mar 2004 12:07:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2vZG-00060Y-00 for mip4-web-archive@ietf.org; Mon, 15 Mar 2004 12:07:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2vYQ-0005xi-00 for mip4-web-archive@ietf.org; Mon, 15 Mar 2004 12:07:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2vXO-0005uf-00 for mip4-web-archive@ietf.org; Mon, 15 Mar 2004 12:06:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2vXN-0006tX-V6; Mon, 15 Mar 2004 12:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2vWR-0006rw-JO for mip4@optimus.ietf.org; Mon, 15 Mar 2004 12:05:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10220 for ; Mon, 15 Mar 2004 12:05:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2vWP-0005pj-00 for mip4@ietf.org; Mon, 15 Mar 2004 12:05:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2vVe-0005ly-00 for mip4@ietf.org; Mon, 15 Mar 2004 12:04:15 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B2vVC-0005dE-00 for mip4@ietf.org; Mon, 15 Mar 2004 12:03:46 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 15 Mar 2004 09:06:35 +0000 Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.70.65.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i2FH3DaE008618; Mon, 15 Mar 2004 09:03:14 -0800 (PST) Date: Mon, 15 Mar 2004 09:03:13 -0800 (PST) From: Sri Gundavelli To: Naveen PaulKandasamy cc: Fredrik Johansson , "Charles E. Perkins" , mip4@ietf.org Subject: Re: [Mip4] Re: [Issue 45] RFC 3344 - FHAE issue when using a different careofaddress In-Reply-To: <4055DA3C.8070003@cisco.com> Message-ID: References: <4055DA3C.8070003@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 > Fredrik Johansson wrote: > > >Sri, > > > >Just a small question. Why would the MN send a deregistration for a CoA that > >it previously had, instead it should send a registration for the new CoA > >which would automatically cause the tunnel to the previous CoA to be > >terminated. > > > > I think, this is true only for the case where the MN is not requesting > simultaneous bindings ? Hi Fredrik, Yes, when the MN has opted for simultaneous bindings and when it prefers to terminate a particular binding or all bindings from a foreign location. Thanks ! Sri. > > thanks, > naveen. > > > > >This means that the HA will terminate its side of the tunnel towards the old > >FA, the old FA must wait for a timeout or if it supports revocation the HA > >can send a revocation. This means that the HA can allways use the CoA when > >it does a lookup for the SA and then the SPI to find the Security Context > >within that SA. As you say, using the source address is not good since there > >might be a NAT inbetween. > > > >/Fredrik > > > >-----Original Message----- > >From: mip4-admin@ietf.org [mailto:mip4-admin@ietf.org]On Behalf Of Sri > >Gundavelli > >Sent: den 14 mars 2004 04:09 > >To: Charles E. Perkins > >Cc: Naveen Paulkandasamy; mip4@ietf.org > >Subject: Re: [Mip4] Re: [Issue 45] RFC 3344 - FHAE issue when using a > >different careofaddress > > > > > >Hi Charlie, > > Please see my comments below ... > > > >Regards ! > >Sri. > > > >"Charles E. Perkins" wrote: > > > > > > > >>Hello again Sri, > >> > >>Thanks for submitting this issue. I think it points to > >>several revisions that are needed to rfc3344bis. > >>For a good resolution, I think it helps if we specify > >>that the source address of the RREQ is the care-of address > >>offered by the foreign agent, so please assume that for > >>my discussion below. > >> > >> > >> > >>> Issue: When the mobile node deregisters using the care-of address of > >>> a different foreign agent than the foreign agent forwarding the dereg > >>> request, the document is not consistent in its explanation as how the > >>> HA and FA should handle such requests. > >>> > >>> > >>Unfortunately true. > >> > >> > >> > >>> Also, if the foreign agent is allowed to forward such requests, there > >>> is no explanation as how the home agent should locate the security > >>> associations for that FA and validate the FHAE. > >>> > >>> > >>Presumably, this depends on the address used by the > >>foreign agent. Let's say it's the care-of address. > >>Also, please note that the document doesn't have much > >>to say about mobility security assocations except in > >>the case of the mobile node. It is expected that the > >>home agent knows how to apply whatever algorithm has > >>been preconfigured between itself and the foreign > >>agent, which is not hard to imagine. We might as > >>well go one step further and assume that the > >>mobility security association depends on the > >>foreign agent's care-of address, and that home > >>agent uses that address to index into its security > >>database along with the SPI as presented by the > >>foreign agent. In fact, I believe the SPI itself > >>"should" be sufficient for the purpose, but we > >>don't have to hold the Mobile IP document up while > >>waiting to resolve _that_ point. > >> > >> > >> > > > >I'm not sure if we should just assume the home agent will some > >how identify the security association for validating the FHAE. In > >this scenario, the home agent would have no means to identify > >the mobility entity that is forwarding the request. Home agent > >cannot use the care-of address for indexing the security association > >as it is a dereg request from a mobile node for a binding it obtained > >thru a different foreign agent. Home agent cannot also use the > >source address of the registration request for the security > >association lookup, as the address could potentially be a NAT > >gateway address, scenario supported by RFC 3519. > > > >SPI alone is not sufficient for any entity to identify the security > >association. It is always with in the context of two entities. If the > >home agent cannot always identify the peer using the source > >address or care-of address of the dereg request, then the home > >agent would not be able to locate the security association. > > > >I agree, it is a difficult problem to solve. But, we have to document > >this special case and provide some guidance as how to deal with it. > > > > > > > > > >>> Section: 3.8.2.2. Accepting a Valid Request > >>> > >>> In all cases, the home agent MUST send a Registration Reply to the > >>> source of the Registration Request, which might indeed be a > >>> > >>> > >different > > > > > >>> foreign agent than that whose care-of address is being > >>> (de)registered. If the home agent shares a mobility security > >>> association with the foreign agent whose care-of address is being > >>> deregistered, and that foreign agent is different from the one which > >>> relayed the Registration Request, the home agent MAY additionally > >>> send a Registration Reply to the foreign agent whose care-of address > >>> is being deregistered. > >>> > >>> Section: 3.7.2.1. Validity Checks > >>> > >>> Requests with the 'D' bit set to 0, and specifying a care-of address > >>> not offered by the foreign agent, MUST be rejected with code 77 > >>> (invalid care-of address). > >>> > >>> > >>This documents the inconsistency. > >> > >> > >> > >>> When the MN sends a dereg request to a foreign agent with the intention > >>> of deregistering its earlier binding it had with a different foreign > >>> > >>> > >agent, > > > > > >>> the behaviour of FA as documented in Section 3.7.2.1 is to reject such > >>> requst with invalid care-of address error. However, the HA > >>> > >>> > >considerations > > > > > >>> (Section 3.8.2.2) allows such requests. The scenario is not handled > >>> consistently at both HA and FA ends. > >>> > >>> > >>Suggested resolution: amend the paragraph in section 3.7.2.1 > >>as follows: > >> > >> Requests with the 'D' bit set to 0, nonzero lifetime, and > >> specifying a care-of address not offered by the foreign agent, > >> MUST be rejected with code 77 (invalid care-of address). > >> > >>This just adds a "nonzero lifetime" conditional which is then > >>needed to trigger a mandated rejection. > >> > >> > >> > > > >Ok. This should fix the home agent and foreign agent behavior > >inconsistency with respect to the above problem. > > > > > > > > > > > >>> Also, if the foreign agent is allowed to forward such requests, there > >>> should be some explanation as how the FA should function when it > >>> receives a dereg message with "D" bit not set and care-of address > >>> set to the MN's home address (Deregister all bindings) or when its > >>> set to the care-of address of a different foreign agent. Assuming the > >>> FA is allowed to forward such a request and when there is security > >>> association configured between FA and the HA, the home agent will not > >>> be able to validate the FHAE. > >>> > >>> > >>With the above, the FA is allowed to forward the request. With > >>the proposed resolution of Issue 44, the IP address in the IP > >>header will be a care-of address offered by the sending foreign > >>agent. Then, the home agent can verify the FHAE, with the above > >>proviso that the foreign-home mobility security association is > >>preconfigured just that way. > >> > >> > > > >The proposed text above (with non-zero lifetime) fixes the inconsistency. > >But, now that the FA is allowed to forward the request, we still would have > >the problem of home agent not being able to verify the FHAE in all > >scenarios. > > > > > > > > > >>> The home agent for validating the FHAE > >>> first needs to use COA address from the RRQ and use the SPI to locate > >>> the security associations. Given that the care-of address is set to > >>> either the home address of the mobile node or the care-of address of > >>> a different foreign agent, how should the HA validate the FHAE ? The > >>> HA cannot use the source address of the RRQ to locate the security > >>> associations as there could be NAT in the path. > >>> > >>> > >>Well, I guess we are agreeing that the security association used > >>to validate the Foreign-Home Authentication Extension is indexed > >>by the source IP address. That information needs to be supplied > >>in section 3.5.4. Here is some proposed text: > >> > >> > >> > > > >Not sure. If the source address is used to index the security association, > >for validating the FHAE, it will fail in the NAT scenario. > > > > > > > > > >> In order to perform the authentication, the Home Agent and the > >> Foreign Agent have to have configured a security association that > >> is able to be indexed by use of the SPI and the care-of address > >> assocated with the Foreign Agent. This care-of address MUST > >> be used as the Source IP address of the Registration Request > >> containing the Foreign-Home Authentication Extension. When > >> the extension is used with a Registration Reply message, the > >> foreign agent address MUST be used as the Destination IP > >> address in the IP header. > >> > >>Please let me know if I have sufficiently understood the issue, > >>and if my proposed revisions clear up the inconsistencies. > >> > >>Regards, > >>Charlie P. > >> > >>-- > >>Mip4 mailing list: Mip4@ietf.org > >> Web interface: https://www.ietf.org/mailman/listinfo/mip4 > >> Charter page: http://www.ietf.org/html.charters/mip4-charter.html > >>Supplemental site: http://www.mip4.org/ > >> > >> > > > > > >-- > >Mip4 mailing list: Mip4@ietf.org > > Web interface: https://www.ietf.org/mailman/listinfo/mip4 > > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > >Supplemental site: http://www.mip4.org/ > > > > > > > > > > > > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Mon Mar 15 14:43:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18910 for ; Mon, 15 Mar 2004 14:43:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2xzN-0005j7-5Y for mip4-archive@odin.ietf.org; Mon, 15 Mar 2004 14:43:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2FJh5t4022006 for mip4-archive@odin.ietf.org; Mon, 15 Mar 2004 14:43:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2xzN-0005iq-0u for mip4-web-archive@optimus.ietf.org; Mon, 15 Mar 2004 14:43:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18889 for ; Mon, 15 Mar 2004 14:43:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2xzK-0007Z8-00 for mip4-web-archive@ietf.org; Mon, 15 Mar 2004 14:43:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2xyK-0007SP-00 for mip4-web-archive@ietf.org; Mon, 15 Mar 2004 14:42:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2xxN-0007OH-00 for mip4-web-archive@ietf.org; Mon, 15 Mar 2004 14:41:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2xxO-0005OE-Pb; Mon, 15 Mar 2004 14:41:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2xwO-0005BV-Ee for mip4@optimus.ietf.org; Mon, 15 Mar 2004 14:40:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18714 for ; Mon, 15 Mar 2004 14:39:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2xwL-0007Jb-00 for mip4@ietf.org; Mon, 15 Mar 2004 14:39:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2xvN-0007Ej-00 for mip4@ietf.org; Mon, 15 Mar 2004 14:38:57 -0500 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1B2xuO-0007AR-00 for mip4@ietf.org; Mon, 15 Mar 2004 14:37:56 -0500 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2FJbKf21947; Mon, 15 Mar 2004 13:37:21 -0600 (CST) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id i2FJbHE21325; Mon, 15 Mar 2004 13:37:18 -0600 (CST) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HUMUHW-0000L4-00; Mon, 15 Mar 2004 14:37:08 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16470.1509.831811.947677@gargle.gargle.HOWL> Date: Mon, 15 Mar 2004 13:37:09 -0600 From: Pete McCann To: "Charles E. Perkins" Cc: mip4@ietf.org Subject: Re: [Mip4] [Issue 20] Missing description - FA rejection code whenMN-HA auth.ext.invalid In-Reply-To: <405226EE.BB7EB769@iprg.nokia.com> References: <401834B5.B0438217@iprg.nokia.com> <16414.57643.587441.82950@gargle.gargle.HOWL> <401EE6DA.4030103@iprg.nokia.com> <16414.59273.36441.23322@gargle.gargle.HOWL> <405226EE.BB7EB769@iprg.nokia.com> X-Mailer: VM 7.14 under 21.5 (beta14) "cassava" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Charlie, My personal opinion is that we should go ahead and insert the normative reference. I also support adopting the faerr draft as a working group document. -Pete Charles E. Perkins writes: > > Hello folks, > > I am in the process of attending to all remaining > comments for the rfc3344bis document, so that I > can go ahead and send in the new draft. > > With the submission of the "faerr" document, > draft-perkins-mip4-faerr-00.txt > I propose that this issue be marked as > "closed". > > The only remaining point is whether or not > the "faerr" document should be mentioned > within rfc3344bis. Overall, it seems to me > that it should be as a normative reference, > but then that introduces a dependency which > may be unwanted. > > Regards, > Charlie P. > > > > Pete McCann wrote: > > > > Hi, Charlie, > > > > Charles E. Perkins writes: > > > > > > Hello Pete, > > > > > > There are two separate issues that could be discussed: > > > > > > - What happens if the FA _knows_ that the Registration Request > > > is guaranteed to be rejected because there isn't any MN-HA > > > extension? > > > > I agree this aspect should be rejected. We should not have the FA > > checking extensions for which it is not responsible. > > > > > - What happens when the FA wants to insert an error code into > > > a Registration Reply? > > > > > > The latter question should be answered by the FA error extension > > > draft which is, I think, basically about done and ready to be > > > disseminated as a new Internet Draft. > > > > Yup. > > > > -Pete > > > > > Regards, > > > Charlie P. > > > > > > > > > Pete McCann wrote: > > > > > > >I re-read the issue and I don't understand what it is saying. I think > > > >it may have been mistakenly attributed to me or incorrectly > > > >transcribed. > > > > > > > >I think it is fine to reject this, barring a more cogent statement of > > > >the issue. Maybe it had something to do with the FA modifying > > > >rejection codes, interfering with the MN-HA authentication extension, > > > >which is the topic of the new draft you are working on. > > > > > > > >-Pete > > > > > > > > > > > >Charles E. Perkins writes: > > > > > > > > > > Hello folks, > > > > > > > > > > Please refer to previous discussion at the following URL: > > > > > http://www.mip4.org/issues/tracker/mip4/issue20 > > > > > as necessary. > > > > > > > > > > The suggestion was to mandate some action on the part of > > > > > a foreign agent if no MN-HA authentication extension is > > > > > present. Presumably, this really means, to reject in case > > > > > there is no authorization-enabling extension. But this > > > > > should anyway be a rare case, and there is little danger > > > > > since the home agent or other authorizing agent will > > > > > reject the Request. > > > > > > > > > > I propose that no action be taken, and that the > > > > > suggestion to change the specification be rejected. > > > > > > > > > > Comments? > > > > > > > > > > Regards, > > > > > Charlie P. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Mon Mar 15 15:31:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22419 for ; Mon, 15 Mar 2004 15:31:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2yjm-0001up-NI for mip4-archive@odin.ietf.org; Mon, 15 Mar 2004 15:31:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2FKV2Rw007363 for mip4-archive@odin.ietf.org; Mon, 15 Mar 2004 15:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2yjm-0001ug-Go for mip4-web-archive@optimus.ietf.org; Mon, 15 Mar 2004 15:31:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22388 for ; Mon, 15 Mar 2004 15:31:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2yjl-0002nP-00 for mip4-web-archive@ietf.org; Mon, 15 Mar 2004 15:31:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2yim-0002iY-00 for mip4-web-archive@ietf.org; Mon, 15 Mar 2004 15:30:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2yhp-0002dj-00 for mip4-web-archive@ietf.org; Mon, 15 Mar 2004 15:29:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2yhp-0001iv-7Z; Mon, 15 Mar 2004 15:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2yh1-0001ev-Gf for mip4@optimus.ietf.org; Mon, 15 Mar 2004 15:28:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22198 for ; Mon, 15 Mar 2004 15:28:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2ygz-0002c9-00 for mip4@ietf.org; Mon, 15 Mar 2004 15:28:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2ygK-0002ZU-00 for mip4@ietf.org; Mon, 15 Mar 2004 15:27:29 -0500 Received: from [47.81.138.65] (helo=zsc3s004.nortelnetworks.com) by ietf-mx with esmtp (Exim 4.12) id 1B2yfU-0002QZ-00 for mip4@ietf.org; Mon, 15 Mar 2004 15:26:36 -0500 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i2FKP1305169; Mon, 15 Mar 2004 12:25:01 -0800 (PST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Mar 2004 14:25:01 -0600 Message-ID: <870397D7C140C84DB081B88396458DAF746D63@zrc2c000.us.nortel.com> From: "Jayshree Bharatia" To: "'Charles E. Perkins'" , Henrik Levkowetz , Pete McCann Cc: mip4@ietf.org Subject: RE: [Mip4] Request to onsider "faerr" specification as a working group document Date: Mon, 15 Mar 2004 14:24:59 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.6 required=5.0 tests=AWL,NEW_DOMAIN_EXTENSIONS, SECTION_301 autolearn=no version=2.60 Hello Charlie, As discussed in the WG meeting of IETF-59, I will include draft-perkins-mip4-faerr-00.txt in the reference section of RFC3012bis. I will also update section 3.2 for the new extension usage for missing-challenge error. I believe we need to extend this extension to support a new subtype for RFC3012bis and hence update the IANA section of RFC3012bis as well. Can you please confirm this? Thanks, Jayshree > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > Sent: Friday, March 12, 2004 2:58 PM > To: Henrik Levkowetz; Pete McCann > Cc: mip4@ietf.org > Subject: [Mip4] Request to onsider "faerr" specification as a > working group document > > > > Hello folks, > > I have submitted the following document, > "Foreign Agent Error Extension for Mobile IPv4", > draft-perkins-mip4-faerr-00.txt, previous to the last IETF as > a proposal for solving some problems raised in issues 9, 18, > and 20 (see http://www.mip4.org/issues/tracker/mip4/). > > I would like to request that this document be considered > as a working group document. > > Regards, > Charlie P. > > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Mon Mar 15 17:15:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01534 for ; Mon, 15 Mar 2004 17:15:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B30Mi-0000qz-Kd for mip4-archive@odin.ietf.org; Mon, 15 Mar 2004 17:15:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2FMFKmm003277 for mip4-archive@odin.ietf.org; Mon, 15 Mar 2004 17:15:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B30Mi-0000qm-Fl for mip4-web-archive@optimus.ietf.org; Mon, 15 Mar 2004 17:15:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01513 for ; Mon, 15 Mar 2004 17:15:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B30Mg-0004T2-00 for mip4-web-archive@ietf.org; Mon, 15 Mar 2004 17:15:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B30Ll-0004Pw-00 for mip4-web-archive@ietf.org; Mon, 15 Mar 2004 17:14:21 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B30LP-0004MJ-00 for mip4-web-archive@ietf.org; Mon, 15 Mar 2004 17:13:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B30LR-0000lS-4O; Mon, 15 Mar 2004 17:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B30Kd-0000iG-8P for mip4@optimus.ietf.org; Mon, 15 Mar 2004 17:13:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01396 for ; Mon, 15 Mar 2004 17:13:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B30Kb-0004KW-00 for mip4@ietf.org; Mon, 15 Mar 2004 17:13:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B30Jr-0004Ii-00 for mip4@ietf.org; Mon, 15 Mar 2004 17:12:24 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1B30JE-0004Ce-00 for mip4@ietf.org; Mon, 15 Mar 2004 17:11:44 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i2FMB2S14512; Mon, 15 Mar 2004 14:11:02 -0800 X-mProtect: <200403152211> Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdbrxJqZ; Mon, 15 Mar 2004 14:10:59 PST Message-ID: <405629E9.4C1B25EC@iprg.nokia.com> Date: Mon, 15 Mar 2004 14:10:49 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Sri Gundavelli CC: mip4@ietf.org Subject: Re: [Mip4] Re: [Issue 45] RFC 3344 - FHAE issue when using a different careofaddress References: <405258AA.10FC70EF@iprg.nokia.com> <4053CCD5.FE977E69@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Sri, > I'm not sure if we should just assume the home agent will some > how identify the security association for validating the FHAE. In > this scenario, the home agent would have no means to identify > the mobility entity that is forwarding the request. I think you mean that, the home agent would, in _some_ circumstances, be unable to validate based on the source IP address in the Registration Request, as you detail below. In other circumstances, of course the home agent would have the means. > Home agent > cannot use the care-of address for indexing the security association > as it is a dereg request from a mobile node for a binding it obtained > thru a different foreign agent. Home agent cannot also use the > source address of the registration request for the security > association lookup, as the address could potentially be a NAT > gateway address, scenario supported by RFC 3519. If I understand it, this is the only objection to using the IP source address. > SPI alone is not sufficient for any entity to identify the security > association. It is always with in the context of two entities. Well, there's 4 billion of them, and that ought to be enough to guarantee uniqueness. But as I mentioned before, I don't propose that we need to haggle about this just yet unless no other way suffices. > If the home agent cannot always identify the peer using the source > address or care-of address of the dereg request, then the home > agent would not be able to locate the security association. Here is a proposal for further comment. It might work. We can specify the following: - The home agent has to follow special rules in order to identify the foreign agent which created the data in the Foreign-Home authentication extension. - This method is only valid for Registration Requests with the 'D' bit zero. - The foreign agent is identified by using the "Care-of Address" field in the Registration Request If this is acceptable (i.e., I didn't miss the point), I will make the appropriate changes to the text. Regards, Charlie P. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Mon Mar 15 17:25:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02432 for ; Mon, 15 Mar 2004 17:25:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B30W1-0001XJ-S4 for mip4-archive@odin.ietf.org; Mon, 15 Mar 2004 17:24:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2FMOvV1005898 for mip4-archive@odin.ietf.org; Mon, 15 Mar 2004 17:24:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B30W1-0001X3-NP for mip4-web-archive@optimus.ietf.org; Mon, 15 Mar 2004 17:24:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02356 for ; Mon, 15 Mar 2004 17:24:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B30Vz-0005VB-00 for mip4-web-archive@ietf.org; Mon, 15 Mar 2004 17:24:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B30V3-0005O7-00 for mip4-web-archive@ietf.org; Mon, 15 Mar 2004 17:23:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B30U7-0005Fo-00 for mip4-web-archive@ietf.org; Mon, 15 Mar 2004 17:22:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B30U8-0001Nj-M0; Mon, 15 Mar 2004 17:23:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B30TT-0001LV-CI for mip4@optimus.ietf.org; Mon, 15 Mar 2004 17:22:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02156 for ; Mon, 15 Mar 2004 17:22:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B30TR-00059w-00 for mip4@ietf.org; Mon, 15 Mar 2004 17:22:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B30SN-0004zD-00 for mip4@ietf.org; Mon, 15 Mar 2004 17:21:13 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1B30R0-0004gp-00 for mip4@ietf.org; Mon, 15 Mar 2004 17:19:47 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i2FMJ3u28015; Mon, 15 Mar 2004 14:19:03 -0800 X-mProtect: <200403152219> Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdgWMACr; Mon, 15 Mar 2004 14:19:02 PST Message-ID: <40562BCC.1ED068@iprg.nokia.com> Date: Mon, 15 Mar 2004 14:18:52 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Pete McCann CC: mip4@ietf.org Subject: Re: [Mip4] [Issue 20] Missing description - FA rejection code whenMN-HA auth.ext.invalid References: <401834B5.B0438217@iprg.nokia.com> <16414.57643.587441.82950@gargle.gargle.HOWL> <401EE6DA.4030103@iprg.nokia.com> <16414.59273.36441.23322@gargle.gargle.HOWL> <405226EE.BB7EB769@iprg.nokia.com> <16470.1509.831811.947677@gargle.gargle.HOWL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Pete, If this is done, then a reasonable associated action would be to remove certain error codes from consideration for use within the Registration Request. Also, I am wondering about rfc3344bis going to Draft Status when it contains a normative reference to something that isn't yet a working group document. When it gets to be a working group document, it will take a while before it is standardized. After is Proposed Standard, it will take a "_long time_" before it is Draft. Is that "O.K."? Regards, Charlie P. Pete McCann wrote: > > --DS-7754947213702225121 > > Hi, Charlie, > > My personal opinion is that we should go ahead and insert the > normative reference. I also support adopting the faerr draft as a > working group document. > > -Pete > > Charles E. Perkins writes: > > > > Hello folks, > > > > I am in the process of attending to all remaining > > comments for the rfc3344bis document, so that I > > can go ahead and send in the new draft. > > > > With the submission of the "faerr" document, > > draft-perkins-mip4-faerr-00.txt > > I propose that this issue be marked as > > "closed". > > > > The only remaining point is whether or not > > the "faerr" document should be mentioned > > within rfc3344bis. Overall, it seems to me > > that it should be as a normative reference, > > but then that introduces a dependency which > > may be unwanted. > > > > Regards, > > Charlie P. > > > > > > > > Pete McCann wrote: > > > > > > Hi, Charlie, > > > > > > Charles E. Perkins writes: > > > > > > > > Hello Pete, > > > > > > > > There are two separate issues that could be discussed: > > > > > > > > - What happens if the FA _knows_ that the Registration Request > > > > is guaranteed to be rejected because there isn't any MN-HA > > > > extension? > > > > > > I agree this aspect should be rejected. We should not have the FA > > > checking extensions for which it is not responsible. > > > > > > > - What happens when the FA wants to insert an error code into > > > > a Registration Reply? > > > > > > > > The latter question should be answered by the FA error extension > > > > draft which is, I think, basically about done and ready to be > > > > disseminated as a new Internet Draft. > > > > > > Yup. > > > > > > -Pete > > > > > > > Regards, > > > > Charlie P. > > > > > > > > > > > > Pete McCann wrote: > > > > > > > > >I re-read the issue and I don't understand what it is saying. I think > > > > >it may have been mistakenly attributed to me or incorrectly > > > > >transcribed. > > > > > > > > > >I think it is fine to reject this, barring a more cogent statement of > > > > >the issue. Maybe it had something to do with the FA modifying > > > > >rejection codes, interfering with the MN-HA authentication extension, > > > > >which is the topic of the new draft you are working on. > > > > > > > > > >-Pete > > > > > > > > > > > > > > >Charles E. Perkins writes: > > > > > > > > > > > > Hello folks, > > > > > > > > > > > > Please refer to previous discussion at the following URL: > > > > > > http://www.mip4.org/issues/tracker/mip4/issue20 > > > > > > as necessary. > > > > > > > > > > > > The suggestion was to mandate some action on the part of > > > > > > a foreign agent if no MN-HA authentication extension is > > > > > > present. Presumably, this really means, to reject in case > > > > > > there is no authorization-enabling extension. But this > > > > > > should anyway be a rare case, and there is little danger > > > > > > since the home agent or other authorizing agent will > > > > > > reject the Request. > > > > > > > > > > > > I propose that no action be taken, and that the > > > > > > suggestion to change the specification be rejected. > > > > > > > > > > > > Comments? > > > > > > > > > > > > Regards, > > > > > > Charlie P. > > --DS-7754947213702225121-- -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Mon Mar 15 17:38:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03651 for ; Mon, 15 Mar 2004 17:38:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B30iG-0002pb-8N for mip4-archive@odin.ietf.org; Mon, 15 Mar 2004 17:37:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2FMbaXN010881 for mip4-archive@odin.ietf.org; Mon, 15 Mar 2004 17:37:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B30iF-0002pI-SK for mip4-web-archive@optimus.ietf.org; Mon, 15 Mar 2004 17:37:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03602 for ; Mon, 15 Mar 2004 17:37:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B30iD-0006zt-00 for mip4-web-archive@ietf.org; Mon, 15 Mar 2004 17:37:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B30h3-0006ov-00 for mip4-web-archive@ietf.org; Mon, 15 Mar 2004 17:36:21 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B30g4-0006bF-00 for mip4-web-archive@ietf.org; Mon, 15 Mar 2004 17:35:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B30fu-0002N8-Lq; Mon, 15 Mar 2004 17:35:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B30fR-0002GK-EW for mip4@optimus.ietf.org; Mon, 15 Mar 2004 17:34:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03092 for ; Mon, 15 Mar 2004 17:34:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B30fO-0006UB-00 for mip4@ietf.org; Mon, 15 Mar 2004 17:34:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B30cw-00067t-00 for mip4@ietf.org; Mon, 15 Mar 2004 17:32:08 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1B30as-0005pC-00 for mip4@ietf.org; Mon, 15 Mar 2004 17:29:58 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i2FMSeD10226; Mon, 15 Mar 2004 14:28:40 -0800 X-mProtect: <200403152228> Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd2o83Y0; Mon, 15 Mar 2004 14:28:38 PST Message-ID: <40562E0C.2F6D1B2A@iprg.nokia.com> Date: Mon, 15 Mar 2004 14:28:28 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Henrik Levkowetz , Pete McCann CC: Mobile IPv4 Mailing List Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip4] Intermediate status of rfc3344bis Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Pete and Henrik, I have applied all of the changes as indicated in recent e-mails, in response to the discussion of the various issues. Issue #17 is still open, depending on the resolution of the request by Jayshree to change the operation of the home agent by allowing certain operations related to dynamic Home Agent assignment. There is a question about whether or not New issue #44 seems to be resolved. New issue #45 could be nearing resolution, if I have gotten sufficient technical grasp of the situation. There is a matter about whether or not to insert a normative reference to the "Foreign Agent Error Extension for Mobile IPv4" document. Does this match your understanding of the current situation? Also, do you agree that I should wait until all of the issues are resolved before submitting the revised document? Regards, Charlie P. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Mon Mar 15 18:31:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07041 for ; Mon, 15 Mar 2004 18:31:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B31YJ-0004p3-2a for mip4-archive@odin.ietf.org; Mon, 15 Mar 2004 18:31:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2FNVNqM018537 for mip4-archive@odin.ietf.org; Mon, 15 Mar 2004 18:31:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B31YI-0004ou-SE for mip4-web-archive@optimus.ietf.org; Mon, 15 Mar 2004 18:31:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07038 for ; Mon, 15 Mar 2004 18:31:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B31YF-0002Tn-00 for mip4-web-archive@ietf.org; Mon, 15 Mar 2004 18:31:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B31XG-0002R9-00 for mip4-web-archive@ietf.org; Mon, 15 Mar 2004 18:30:19 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B31Wy-0002Ob-00 for mip4-web-archive@ietf.org; Mon, 15 Mar 2004 18:30:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B31X0-0004j9-Jh; Mon, 15 Mar 2004 18:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B31WO-0004iF-3T for mip4@optimus.ietf.org; Mon, 15 Mar 2004 18:29:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06979 for ; Mon, 15 Mar 2004 18:29:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B31WL-0002NN-00 for mip4@ietf.org; Mon, 15 Mar 2004 18:29:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B31VW-0002K3-00 for mip4@ietf.org; Mon, 15 Mar 2004 18:28:31 -0500 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 1B31Ur-0002BP-00 for mip4@ietf.org; Mon, 15 Mar 2004 18:27:49 -0500 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i2FNR7812793; Mon, 15 Mar 2004 17:27:07 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Mar 2004 17:27:07 -0600 Message-ID: <870397D7C140C84DB081B88396458DAF746D65@zrc2c000.us.nortel.com> From: "Jayshree Bharatia" To: "'Charles E. Perkins'" Cc: mip4@ietf.org Subject: RE: [Mip4] [Issue 17] Enhanced Registration Request processing at the Home Agent. Date: Mon, 15 Mar 2004 17:26:58 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL autolearn=no version=2.60 Hello Charlie, I have included my comments inline. Regards, Jayshree > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > Sent: Friday, March 12, 2004 4:59 PM > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > Cc: mip4@ietf.org > Subject: Re: [Mip4] [Issue 17] Enhanced Registration Request > processing atthe Home Agent. > > > > Hello Jayshree, > > Thanks for reminding me about these points -- I missed them > because I was looking on the issue tracker. > > Jayshree Bharatia wrote: > > > Change 1: "If the Home Agent cannot support the specified nonzero > > unicast address in the Home Address field of the > Registration Request, > > then the Home Agent MUST reject the registration with an > error code of > > 129. " > > I have put this addition into the text for section 3.8.3.2. > I agree that error number 129 will serve the purpose. > JB] ok > > If the MN registers a static Home Address (or registers with a > > previously assigned dynamic Home Address) on a Home Agent > that can not > > support the presented Home Address, then the Home Agent fails the > > registration and return code 129 "admin prohibited" (or something > > equivalent). > > This seems to me to duplicate the work of the previous > paragraph, so I would hope that it does not have to be added > also. I don't see why the home agent has to know whether the > address was dynamically assigned or not. > [JB] This is just a description of change 1 (above) which you have already taken care of. Hence, there is no action needed for this part. > > Change 2: "if the destination IP address of the > Registration Request > > is the unicast IP address of this Home Agent, the Home Agent MAY > > accept the Registration Request. > > The conditions for accepting registrations from the mobile > node are sort-of the subject of a great deal of text, so I > guess that the purpose of this sentence is to enable a new > kind of operation for when a nonzero Home Agent address field > does not match the unicast address in the IP header. This > means, for instance, that the Registration Request didn't > come from the foreign agent. Or else there is a new protocol > in operation that is outside the scope of this document. > > In either case, I would expect that the details of operation > are more appropriately described in another document. That > other document would be also able to override the mandates > within RFC 3344{,bis}, and so I am reluctant to make such > partial changes within rfc3344bis-00.txt > > > If the destination IP address of the > > Registration Request is not the unicast IP address of this > Home Agent, > > the home agent MUST reject the Registration Request with a suitable > > code(e.g., Code 136) to prevent the mobile node from possibly being > > simultaneously registered with two or more Home Agents." > > Here, it is not clear how the Home Agent was able to > receive the packet in the first place. [JB] I should have copied the full proposal earlier for clarity. This specific change is the extension of the condition where the home agent field in the Registration Request does not contain a unicast address of this home agent. In this case, the current text is suggesting to reject the Registration Request. But the new proposal is to accept the Registration Request if destination IP address of the Registration Request is same as the unicast IP address of this Home Agent. As indicated earlier, this is applicable for dynamic HA scenario. > > > This text is applicable for the Dynamic Home Agent > mechanism. If the > > HA receives a Registration Request with a Home Agent field not its > > own, the HA "MAY" accept the registration. Please note that the > > current text requires the HA to reject the registration. > > I hope that the Dynamic Home Agent document should be the > place to make the changes. > [JB] I am ok with this decision if this is acceptable to all. > Regards, > Charlie P. > > > > > > -----Original Message----- > > > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > > > Sent: Friday, March 12, 2004 3:37 PM > > > To: mip4@ietf.org > > > Cc: Henrik Levkowetz; Pete McCann > > > Subject: Re: [Mip4] [Issue 17] Enhanced Registration Request > > > processing at the Home Agent. > > > > > > > > > > > > Hello folks, > > > > > > I propose that issue 17 be closed and > > > marked as rejected. > > > > > > Regards, > > > Charlie P. > > > > > > > > > > > > "Charles E. Perkins" wrote: > > > > > > > > Hello folks, > > > > > > > > Please refer to previous discussion at the following URL: > > > > http://www.mip4.org/issues/tracker/mip4/issue17 > > > > and: > > > > http://www.ietf.org/proceedings/03nov/142.htm > > > > as necessary. > > > > > > > > This issue has to deal with what the home agent might > > > > do if it gets a Registration Request to an unknown unicast > > > > address. Nobody presented sufficient reasons for the > home agent > > > > to take any useful action other than > > > rejecting the > > > > Request. I don't think that any changes to the > > > specification are yet > > > > warranted by discussion up until now. > > > > > > > > Regards, > > > > Charlie P. > > > > > > > > -- > > > > Mip4 mailing list > > > > Mip4@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mip4 > > > > > > -- > > > Mip4 mailing list: Mip4@ietf.org > > > Web interface: https://www.ietf.org/mailman/listinfo/mip4 > > > Charter page: > > > http://www.ietf.org/html.charters/mip4-charter.html > > > Supplemental site: http://www.mip4.org/ > > > > > > > --DS9166993534658177240-- > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Mon Mar 15 18:56:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08416 for ; Mon, 15 Mar 2004 18:56:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B31vx-0006bZ-9e for mip4-archive@odin.ietf.org; Mon, 15 Mar 2004 18:55:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2FNtn0S025383 for mip4-archive@odin.ietf.org; Mon, 15 Mar 2004 18:55:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B31vx-0006bJ-54 for mip4-web-archive@optimus.ietf.org; Mon, 15 Mar 2004 18:55:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08347 for ; Mon, 15 Mar 2004 18:55:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B31vu-00047D-00 for mip4-web-archive@ietf.org; Mon, 15 Mar 2004 18:55:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B31vA-00040W-00 for mip4-web-archive@ietf.org; Mon, 15 Mar 2004 18:55:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B31uB-0003ra-00 for mip4-web-archive@ietf.org; Mon, 15 Mar 2004 18:53:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B31uC-0006VF-Qq; Mon, 15 Mar 2004 18:54:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B31tz-0006Uf-CV for mip4@optimus.ietf.org; Mon, 15 Mar 2004 18:53:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08063 for ; Mon, 15 Mar 2004 18:53:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B31tw-0003pH-00 for mip4@ietf.org; Mon, 15 Mar 2004 18:53:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B31sl-0003hT-00 for mip4@ietf.org; Mon, 15 Mar 2004 18:52:32 -0500 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=chardonnay.levkowetz.com) by ietf-mx with esmtp (Exim 4.12) id 1B31s3-0003cN-00 for mip4@ietf.org; Mon, 15 Mar 2004 18:51:48 -0500 Received: from chardonnay ([127.0.0.1]) by chardonnay.levkowetz.com with smtp (Exim 3.36 #1 (Debian)) id 1B31rh-00034o-00; Tue, 16 Mar 2004 00:51:25 +0100 Date: Tue, 16 Mar 2004 00:51:20 +0100 From: Henrik Levkowetz To: "Charles E. Perkins" Cc: Pete McCann , Mobile IPv4 Mailing List Subject: Re: [Mip4] Intermediate status of rfc3344bis Message-Id: <20040316005120.496962a3.henrik@levkowetz.com> In-Reply-To: <40562E0C.2F6D1B2A@iprg.nokia.com> References: <40562E0C.2F6D1B2A@iprg.nokia.com> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Signature=_Tue__16_Mar_2004_00_51_20_+0100_Y9mY01XuNQ35EaSz" Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 --Signature=_Tue__16_Mar_2004_00_51_20_+0100_Y9mY01XuNQ35EaSz Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Hi Charlie, Monday 15 March 2004, Charles E. Perkins wrote: > I have applied all of the changes as indicated in > recent e-mails, in response to the discussion of > the various issues. Issue #17 is still open, > depending on the resolution of the request by > Jayshree to change the operation of the home > agent by allowing certain operations related to > dynamic Home Agent assignment. There is a > question about whether or not (missing some conclusion here?) > New issue #44 seems to be resolved. Right. > New issue #45 could be nearing resolution, > if I have gotten sufficient technical grasp > of the situation. There is a matter about > whether or not to insert a normative reference > to the "Foreign Agent Error Extension for > Mobile IPv4" document. Yes. I think this is the right thing to do, even if it may complicate things process wise for taking 3344bis to Draft Standard. > Does this match your understanding of the > current situation? Also, do you agree that > I should wait until all of the issues are > resolved before submitting the revised document? It does. And yes, since it looks like we are getting close to resolving them now, I think it would be fine to hold off for a short time and see if we can't get them all. Henrik --Signature=_Tue__16_Mar_2004_00_51_20_+0100_Y9mY01XuNQ35EaSz Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAVkF5eVhrtTJkXCMRAvl6AKCxl6utuWpNMBL3wLv2MR1ERiK6YQCglW6i l4rDh7xDNyPPd2MJ+NYqqU0= =/SCL -----END PGP SIGNATURE----- --Signature=_Tue__16_Mar_2004_00_51_20_+0100_Y9mY01XuNQ35EaSz-- -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Mon Mar 15 23:46:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23522 for ; Mon, 15 Mar 2004 23:46:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B36Su-0001ea-0T for mip4-archive@odin.ietf.org; Mon, 15 Mar 2004 23:46:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2G4k7oR006352 for mip4-archive@odin.ietf.org; Mon, 15 Mar 2004 23:46:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B36St-0001eK-Rl for mip4-web-archive@optimus.ietf.org; Mon, 15 Mar 2004 23:46:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23501 for ; Mon, 15 Mar 2004 23:46:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B36Sr-0004v6-00 for mip4-web-archive@ietf.org; Mon, 15 Mar 2004 23:46:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B36Rb-0004m7-00 for mip4-web-archive@ietf.org; Mon, 15 Mar 2004 23:44:48 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B36Qv-0004fX-00 for mip4-web-archive@ietf.org; Mon, 15 Mar 2004 23:44:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B36Qt-0001Na-0T; Mon, 15 Mar 2004 23:44:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B36QX-0001MH-OI for mip4@optimus.ietf.org; Mon, 15 Mar 2004 23:43:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23323 for ; Mon, 15 Mar 2004 23:43:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B36QV-0004dz-00 for mip4@ietf.org; Mon, 15 Mar 2004 23:43:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B36Pi-0004Y8-00 for mip4@ietf.org; Mon, 15 Mar 2004 23:42:51 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B36Op-0004Ns-00 for mip4@ietf.org; Mon, 15 Mar 2004 23:41:55 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 15 Mar 2004 20:44:51 +0000 Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.70.65.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i2G4fOK3016611; Mon, 15 Mar 2004 20:41:24 -0800 (PST) Date: Mon, 15 Mar 2004 20:41:24 -0800 (PST) From: Sri Gundavelli To: "Charles E. Perkins" cc: mip4@ietf.org Subject: Re: [Mip4] Re: [Issue 45] RFC 3344 - FHAE issue when using a different careofaddress In-Reply-To: <405629E9.4C1B25EC@iprg.nokia.com> Message-ID: References: <405258AA.10FC70EF@iprg.nokia.com> <4053CCD5.FE977E69@cisco.com> <405629E9.4C1B25EC@iprg.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi Charlie, Thanks for your response. Please see my comments below ... Regards ! Sri. On Mon, 15 Mar 2004, Charles E. Perkins wrote: > > Hello Sri, > > > I'm not sure if we should just assume the home agent will some > > how identify the security association for validating the FHAE. In > > this scenario, the home agent would have no means to identify > > the mobility entity that is forwarding the request. > > I think you mean that, the home agent would, in _some_ > circumstances, be unable to validate based on the source > IP address in the Registration Request, as you detail > below. In other circumstances, of course the home agent > would have the means. > Yes. In some scenarios ... > > Home agent > > cannot use the care-of address for indexing the security association > > as it is a dereg request from a mobile node for a binding it obtained > > thru a different foreign agent. Home agent cannot also use the > > source address of the registration request for the security > > association lookup, as the address could potentially be a NAT > > gateway address, scenario supported by RFC 3519. > > If I understand it, this is the only objection to using the > IP source address. > Yes > > SPI alone is not sufficient for any entity to identify the security > > association. It is always with in the context of two entities. > > Well, there's 4 billion of them, and that ought to be enough > to guarantee uniqueness. But as I mentioned before, I don't > propose that we need to haggle about this just yet unless no > other way suffices. Sure. It is a big number, but per IP Security Architecture doc, it is always tied to a peer. I agree, we don't have to delay the process of 3344bis from becoming a standard, while trying to fix this Simultaneous binding issue. I'm ok with your text below. We can always address the FA Identity problem outside the current draft. FA can always hint the HA by adding certain Identity extensions along the lines of FA Error extensions. > > > If the home agent cannot always identify the peer using the source > > address or care-of address of the dereg request, then the home > > agent would not be able to locate the security association. > > Here is a proposal for further comment. It might work. > > We can specify the following: > > - The home agent has to follow special rules in order > to identify the foreign agent which created the > data in the Foreign-Home authentication extension. > > - This method is only valid for Registration Requests > with the 'D' bit zero. > > - The foreign agent is identified by using the > "Care-of Address" field in the Registration Request > > If this is acceptable (i.e., I didn't miss the point), > I will make the appropriate changes to the text. > Ok ! This works. Thanks for your comments. > Regards, > Charlie P. > > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Tue Mar 16 12:02:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10946 for ; Tue, 16 Mar 2004 12:02:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Hws-0000m2-Kq for mip4-archive@odin.ietf.org; Tue, 16 Mar 2004 12:01:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2GH1ono002973 for mip4-archive@odin.ietf.org; Tue, 16 Mar 2004 12:01:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Hws-0000ls-FC for mip4-web-archive@optimus.ietf.org; Tue, 16 Mar 2004 12:01:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10930 for ; Tue, 16 Mar 2004 12:01:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3Hwr-0006tz-00 for mip4-web-archive@ietf.org; Tue, 16 Mar 2004 12:01:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3Hw0-0006p1-00 for mip4-web-archive@ietf.org; Tue, 16 Mar 2004 12:00:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3HvB-0006k4-00 for mip4-web-archive@ietf.org; Tue, 16 Mar 2004 12:00:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Hv8-0000Mz-7D; Tue, 16 Mar 2004 12:00:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Huz-0000Le-2k for mip4@optimus.ietf.org; Tue, 16 Mar 2004 11:59:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10842 for ; Tue, 16 Mar 2004 11:59:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3Hux-0006iN-00 for mip4@ietf.org; Tue, 16 Mar 2004 11:59:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3Hu7-0006dI-00 for mip4@ietf.org; Tue, 16 Mar 2004 11:58:59 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B3HtX-0006X6-00 for mip4@ietf.org; Tue, 16 Mar 2004 11:58:23 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 16 Mar 2004 09:01:21 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2GGvmM7026951; Tue, 16 Mar 2004 08:57:48 -0800 (PST) Received: from kleung-w2k01.cisco.com (sjc-vpn3-280.cisco.com [10.21.65.24]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ARF12317; Tue, 16 Mar 2004 08:57:44 -0800 (PST) Message-Id: <4.3.2.7.2.20040315150256.02f87b38@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 16 Mar 2004 08:57:44 -0800 To: "Charles E. Perkins" From: Kent Leung Subject: Re: [Mip4] Re: [Issue 45] RFC 3344 - FHAE issue when using a different careofaddress Cc: Sri Gundavelli , mip4@ietf.org In-Reply-To: <405629E9.4C1B25EC@iprg.nokia.com> References: <405258AA.10FC70EF@iprg.nokia.com> <4053CCD5.FE977E69@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Do we need a solution for the case of MN sending deregistration for a particular CoA? For registrations, the CoA should be set as CCoA or FA CoA. But for deregistratations, maybe we should have an extension that contains the CoA to be deregistered? This could be either the selected CoA (in case of simultaneous bindings), previous CoA, or HoA for all bindings. This scheme would clearly identify the FA for FHAE authentication and which CoA(s) the MN wish to deregister. Basically, this problem existed from Day One (since RFC 2002) and maybe this is a good time to resolve it? Kent At 02:10 PM 3/15/2004 -0800, Charles E. Perkins wrote: >Hello Sri, > > > I'm not sure if we should just assume the home agent will some > > how identify the security association for validating the FHAE. In > > this scenario, the home agent would have no means to identify > > the mobility entity that is forwarding the request. > >I think you mean that, the home agent would, in _some_ >circumstances, be unable to validate based on the source >IP address in the Registration Request, as you detail >below. In other circumstances, of course the home agent >would have the means. > > > Home agent > > cannot use the care-of address for indexing the security association > > as it is a dereg request from a mobile node for a binding it obtained > > thru a different foreign agent. Home agent cannot also use the > > source address of the registration request for the security > > association lookup, as the address could potentially be a NAT > > gateway address, scenario supported by RFC 3519. > >If I understand it, this is the only objection to using the >IP source address. > > > SPI alone is not sufficient for any entity to identify the security > > association. It is always with in the context of two entities. > >Well, there's 4 billion of them, and that ought to be enough >to guarantee uniqueness. But as I mentioned before, I don't >propose that we need to haggle about this just yet unless no >other way suffices. > > > If the home agent cannot always identify the peer using the source > > address or care-of address of the dereg request, then the home > > agent would not be able to locate the security association. > >Here is a proposal for further comment. It might work. > >We can specify the following: > >- The home agent has to follow special rules in order > to identify the foreign agent which created the > data in the Foreign-Home authentication extension. > >- This method is only valid for Registration Requests > with the 'D' bit zero. > >- The foreign agent is identified by using the > "Care-of Address" field in the Registration Request > >If this is acceptable (i.e., I didn't miss the point), >I will make the appropriate changes to the text. > >Regards, >Charlie P. > >-- >Mip4 mailing list: Mip4@ietf.org > Web interface: https://www.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html >Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Tue Mar 16 12:19:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11830 for ; Tue, 16 Mar 2004 12:19:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3IDV-0002Lz-8L for mip4-archive@odin.ietf.org; Tue, 16 Mar 2004 12:19:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2GHJ1od009046 for mip4-archive@odin.ietf.org; Tue, 16 Mar 2004 12:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3IDU-0002Lp-Vu for mip4-web-archive@optimus.ietf.org; Tue, 16 Mar 2004 12:19:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11820 for ; Tue, 16 Mar 2004 12:18:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3IDT-0000xm-00 for mip4-web-archive@ietf.org; Tue, 16 Mar 2004 12:18:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3ICP-0000tE-00 for mip4-web-archive@ietf.org; Tue, 16 Mar 2004 12:17:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3IBZ-0000oW-00 for mip4-web-archive@ietf.org; Tue, 16 Mar 2004 12:17:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3IBZ-0002H8-CZ; Tue, 16 Mar 2004 12:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3IBQ-0002GW-Ol for mip4@optimus.ietf.org; Tue, 16 Mar 2004 12:16:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11747 for ; Tue, 16 Mar 2004 12:16:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3IBP-0000nL-00 for mip4@ietf.org; Tue, 16 Mar 2004 12:16:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3IAf-0000ik-00 for mip4@ietf.org; Tue, 16 Mar 2004 12:16:06 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1B3I9x-0000c0-00 for mip4@ietf.org; Tue, 16 Mar 2004 12:15:21 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i2GHEde07751; Tue, 16 Mar 2004 09:14:39 -0800 X-mProtect: <200403161714> Nokia Silicon Valley Messaging Protection Received: from danira-pool049210.americas.nokia.com (10.241.49.210, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdar9TK0; Tue, 16 Mar 2004 09:14:36 PST Message-ID: <405735F6.2050707@iprg.nokia.com> Date: Tue, 16 Mar 2004 09:14:30 -0800 From: "Charles E. Perkins" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kent Leung CC: Sri Gundavelli , mip4@ietf.org Subject: Re: [Mip4] Re: [Issue 45] RFC 3344 - FHAE issue when using a different careofaddress References: <405258AA.10FC70EF@iprg.nokia.com> <4053CCD5.FE977E69@cisco.com> <4.3.2.7.2.20040315150256.02f87b38@mira-sjcm-2.cisco.com> In-Reply-To: <4.3.2.7.2.20040315150256.02f87b38@mira-sjcm-2.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Kent, I didn't see exactly what remained to be done. I'd rather not make new extensions unnecessarily. Kent Leung wrote: > Do we need a solution for the case of MN sending deregistration for a > particular CoA? It could be that we already have a solution, yes? > For registrations, the CoA should be set as CCoA or FA CoA. But > for deregistratations, maybe we should have an extension that contains > the CoA to be deregistered? This could be either the selected CoA > (in case of simultaneous bindings), previous CoA, or HoA for all > bindings. But these cases are already covered, I think. > This scheme would clearly identify the FA for FHAE authentication > and which CoA(s) the MN wish to deregister. Whether or not the FHAE is applied should be invisible to the mobile node. > Basically, this problem existed from Day One (since RFC 2002) and maybe > this is a good time to resolve it? I thought the problem didn't exist until RFC 3519. Regards, Charlie P. =================================================== >> > I'm not sure if we should just assume the home agent will some >> > how identify the security association for validating the FHAE. In >> > this scenario, the home agent would have no means to identify >> > the mobility entity that is forwarding the request. >> >> I think you mean that, the home agent would, in _some_ >> circumstances, be unable to validate based on the source >> IP address in the Registration Request, as you detail >> below. In other circumstances, of course the home agent >> would have the means. >> >> > Home agent >> > cannot use the care-of address for indexing the security association >> > as it is a dereg request from a mobile node for a binding it obtained >> > thru a different foreign agent. Home agent cannot also use the >> > source address of the registration request for the security >> > association lookup, as the address could potentially be a NAT >> > gateway address, scenario supported by RFC 3519. >> >> If I understand it, this is the only objection to using the >> IP source address. >> >> > SPI alone is not sufficient for any entity to identify the security >> > association. It is always with in the context of two entities. >> >> Well, there's 4 billion of them, and that ought to be enough >> to guarantee uniqueness. But as I mentioned before, I don't >> propose that we need to haggle about this just yet unless no >> other way suffices. >> >> > If the home agent cannot always identify the peer using the source >> > address or care-of address of the dereg request, then the home >> > agent would not be able to locate the security association. >> >> Here is a proposal for further comment. It might work. >> >> We can specify the following: >> >> - The home agent has to follow special rules in order >> to identify the foreign agent which created the >> data in the Foreign-Home authentication extension. >> >> - This method is only valid for Registration Requests >> with the 'D' bit zero. >> >> - The foreign agent is identified by using the >> "Care-of Address" field in the Registration Request >> >> If this is acceptable (i.e., I didn't miss the point), >> I will make the appropriate changes to the text. >> >> Regards, >> Charlie P. >> >> -- >> Mip4 mailing list: Mip4@ietf.org >> Web interface: https://www.ietf.org/mailman/listinfo/mip4 >> Charter page: http://www.ietf.org/html.charters/mip4-charter.html >> Supplemental site: http://www.mip4.org/ > > > > --DS8073626969754241571-- > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Tue Mar 16 15:16:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21865 for ; Tue, 16 Mar 2004 15:16:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Kyh-0006tK-O4 for mip4-archive@odin.ietf.org; Tue, 16 Mar 2004 15:15:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2GKFtDk026484 for mip4-archive@odin.ietf.org; Tue, 16 Mar 2004 15:15:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Kyh-0006t3-EH for mip4-web-archive@optimus.ietf.org; Tue, 16 Mar 2004 15:15:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21826 for ; Tue, 16 Mar 2004 15:15:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3Kyg-0003rK-00 for mip4-web-archive@ietf.org; Tue, 16 Mar 2004 15:15:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3Kxo-0003n1-00 for mip4-web-archive@ietf.org; Tue, 16 Mar 2004 15:15:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3Kwr-0003hx-00 for mip4-web-archive@ietf.org; Tue, 16 Mar 2004 15:14:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Kwq-0006TJ-OA; Tue, 16 Mar 2004 15:14:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Kwi-0006RI-Se for mip4@optimus.ietf.org; Tue, 16 Mar 2004 15:13:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21648 for ; Tue, 16 Mar 2004 15:13:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3Kwh-0003gT-00 for mip4@ietf.org; Tue, 16 Mar 2004 15:13:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3Kvs-0003cW-00 for mip4@ietf.org; Tue, 16 Mar 2004 15:13:01 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B3KvQ-0003Xm-00 for mip4@ietf.org; Tue, 16 Mar 2004 15:12:32 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 16 Mar 2004 12:16:43 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i2GKC0K2016376; Tue, 16 Mar 2004 12:12:00 -0800 (PST) Received: from kleung-w2k01.cisco.com (sjc-vpn3-280.cisco.com [10.21.65.24]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ARF32431; Tue, 16 Mar 2004 12:11:58 -0800 (PST) Message-Id: <4.3.2.7.2.20040316112450.02bfb150@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 16 Mar 2004 12:11:58 -0800 To: "Charles E. Perkins" From: Kent Leung Subject: Re: [Mip4] Re: [Issue 45] RFC 3344 - FHAE issue when using a different careofaddress Cc: Sri Gundavelli , mip4@ietf.org In-Reply-To: <405735F6.2050707@iprg.nokia.com> References: <4.3.2.7.2.20040315150256.02f87b38@mira-sjcm-2.cisco.com> <405258AA.10FC70EF@iprg.nokia.com> <4053CCD5.FE977E69@cisco.com> <4.3.2.7.2.20040315150256.02f87b38@mira-sjcm-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.2 required=5.0 tests=AWL,NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 Hi Charlie. I think the issue is how does HA authenticate the FHAE when MN sends a deregistration message? HA needs a security association with the FA, which is typically identified by the CoA (assuming FA providing service to MN). The source IP address RRQ from FA is the transmitting interface's IP address (until RFC 3519). So an FA with multiple interfaces would likely use CoA to identify itself for the SA with HA. But MN has to set the CoA field to the address used as index to remove the right mobility binding on HA. What I meant by Day One problem is when FA is identified by the CoA field only, which seems practical. Maybe I missed the solution that covered this case? The statement, "The home agent has to follow special rules in order to identify the foreign agent which created the data in the Foreign-Home authentication extension.", doesn't provide information on exactly how the FA is actually identified in the registration request message. There are 2 fields, source IP address and CoA, but neither is sufficient given that source IP address may be NAT'ed and CoA is what MN wants to deregister. That was the reason behind proposing some extension to identify the FA clearly for HA to look up the SA. I agree that we don't want to have any unnecessary extensions. :) Kent At 09:14 AM 3/16/2004 -0800, Charles E. Perkins wrote: >Hello Kent, > >I didn't see exactly what remained to be done. I'd rather not >make new extensions unnecessarily. > >Kent Leung wrote: > >>Do we need a solution for the case of MN sending deregistration for a >>particular CoA? > >It could be that we already have a solution, yes? > >>For registrations, the CoA should be set as CCoA or FA CoA. But >>for deregistratations, maybe we should have an extension that contains >>the CoA to be deregistered? This could be either the selected CoA >>(in case of simultaneous bindings), previous CoA, or HoA for all bindings. > >But these cases are already covered, I think. > >>This scheme would clearly identify the FA for FHAE authentication >>and which CoA(s) the MN wish to deregister. > >Whether or not the FHAE is applied should be invisible to the >mobile node. > >>Basically, this problem existed from Day One (since RFC 2002) and maybe >>this is a good time to resolve it? > >I thought the problem didn't exist until RFC 3519. > >Regards, >Charlie P. > >=================================================== > >>> > I'm not sure if we should just assume the home agent will some >>> > how identify the security association for validating the FHAE. In >>> > this scenario, the home agent would have no means to identify >>> > the mobility entity that is forwarding the request. >>> >>>I think you mean that, the home agent would, in _some_ >>>circumstances, be unable to validate based on the source >>>IP address in the Registration Request, as you detail >>>below. In other circumstances, of course the home agent >>>would have the means. >>> >>> > Home agent >>> > cannot use the care-of address for indexing the security association >>> > as it is a dereg request from a mobile node for a binding it obtained >>> > thru a different foreign agent. Home agent cannot also use the >>> > source address of the registration request for the security >>> > association lookup, as the address could potentially be a NAT >>> > gateway address, scenario supported by RFC 3519. >>> >>>If I understand it, this is the only objection to using the >>>IP source address. >>> >>> > SPI alone is not sufficient for any entity to identify the security >>> > association. It is always with in the context of two entities. >>> >>>Well, there's 4 billion of them, and that ought to be enough >>>to guarantee uniqueness. But as I mentioned before, I don't >>>propose that we need to haggle about this just yet unless no >>>other way suffices. >>> >>> > If the home agent cannot always identify the peer using the source >>> > address or care-of address of the dereg request, then the home >>> > agent would not be able to locate the security association. >>> >>>Here is a proposal for further comment. It might work. >>> >>>We can specify the following: >>> >>>- The home agent has to follow special rules in order >>> to identify the foreign agent which created the >>> data in the Foreign-Home authentication extension. >>> >>>- This method is only valid for Registration Requests >>> with the 'D' bit zero. >>> >>>- The foreign agent is identified by using the >>> "Care-of Address" field in the Registration Request >>> >>>If this is acceptable (i.e., I didn't miss the point), >>>I will make the appropriate changes to the text. >>> >>>Regards, >>>Charlie P. >>> >>>-- >>>Mip4 mailing list: Mip4@ietf.org >>> Web interface: https://www.ietf.org/mailman/listinfo/mip4 >>> Charter page: http://www.ietf.org/html.charters/mip4-charter.html >>>Supplemental site: http://www.mip4.org/ >> >> >> >>--DS8073626969754241571-- > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Tue Mar 16 15:38:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22943 for ; Tue, 16 Mar 2004 15:38:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3LJx-0001FD-Lc for mip4-archive@odin.ietf.org; Tue, 16 Mar 2004 15:37:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2GKbrBu004765 for mip4-archive@odin.ietf.org; Tue, 16 Mar 2004 15:37:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3LJw-0001EY-0g for mip4-web-archive@optimus.ietf.org; Tue, 16 Mar 2004 15:37:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22932 for ; Tue, 16 Mar 2004 15:37:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3LJu-0005ZO-00 for mip4-web-archive@ietf.org; Tue, 16 Mar 2004 15:37:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3LJ1-0005V3-00 for mip4-web-archive@ietf.org; Tue, 16 Mar 2004 15:36:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3LIB-0005Qn-00 for mip4-web-archive@ietf.org; Tue, 16 Mar 2004 15:36:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3LI9-0000tU-Mo; Tue, 16 Mar 2004 15:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3LI0-0000sw-RJ for mip4@optimus.ietf.org; Tue, 16 Mar 2004 15:35:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22866 for ; Tue, 16 Mar 2004 15:35:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3LHz-0005P3-00 for mip4@ietf.org; Tue, 16 Mar 2004 15:35:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3LH6-0005KS-00 for mip4@ietf.org; Tue, 16 Mar 2004 15:34:57 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B3LGC-0005BY-00 for mip4@ietf.org; Tue, 16 Mar 2004 15:34:00 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 16 Mar 2004 12:37:00 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2GKXOM7001436; Tue, 16 Mar 2004 12:33:24 -0800 (PST) Received: from kleung-w2k01.cisco.com (sjc-vpn3-280.cisco.com [10.21.65.24]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ARF34554; Tue, 16 Mar 2004 12:33:23 -0800 (PST) Message-Id: <4.3.2.7.2.20040316121552.02ce1920@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 16 Mar 2004 12:33:23 -0800 To: "Charles E. Perkins" From: Kent Leung Subject: Re: [Mip4] Request to onsider "faerr" specification as a working group document Cc: Henrik Levkowetz , Pete McCann , mip4@ietf.org In-Reply-To: <40522457.A2FEA127@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Hi Charlie. Just some thoughts on the draft .. 1) In section 4, should the allowable code be just generically in the range of 64-127 (Error Codes from the Foreign Agent)? This avoids having to selectively choose which defined error code is admissible in this extension? Does it make sense for any code that exists today or will be added in the future to not be carried in the extension? What happens when event happens with error code that is not allowed, should FA not add the extension or map to some allowable code? 2) Should there be a MN Considerations section to specify that MN should deregister an accepted registration (status code 0 or 1 from HA) which contains this FA error extension? This would clean up such condition when HA thinks everything is OK but FA disagree. Silence by MN provides implicit acknowledgement to HA that FA and MN are OK with the accepted registration reply. Else MN would notify the HA that FA had problem with the reply. Should the specifics of the FA error code be conveyed to HA by MN? This would allow MN, FA, and HA to log the same error condition. Kent At 12:57 PM 3/12/2004 -0800, Charles E. Perkins wrote: >Hello folks, > >I have submitted the following document, > "Foreign Agent Error Extension for Mobile IPv4", >draft-perkins-mip4-faerr-00.txt, >previous to the last IETF as a proposal for >solving some problems raised in issues 9, >18, and 20 (see http://www.mip4.org/issues/tracker/mip4/). > >I would like to request that this document be considered >as a working group document. > >Regards, >Charlie P. > >-- >Mip4 mailing list: Mip4@ietf.org > Web interface: https://www.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html >Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Tue Mar 16 15:50:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23394 for ; Tue, 16 Mar 2004 15:50:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3LSf-0001jN-6E for mip4-archive@odin.ietf.org; Tue, 16 Mar 2004 15:46:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2GKkrKi006647 for mip4-archive@odin.ietf.org; Tue, 16 Mar 2004 15:46:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3LSf-0001j8-1w for mip4-web-archive@optimus.ietf.org; Tue, 16 Mar 2004 15:46:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23219 for ; Tue, 16 Mar 2004 15:46:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3LSd-0006HT-00 for mip4-web-archive@ietf.org; Tue, 16 Mar 2004 15:46:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3LRi-0006Cx-00 for mip4-web-archive@ietf.org; Tue, 16 Mar 2004 15:45:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3LQr-00068m-00 for mip4-web-archive@ietf.org; Tue, 16 Mar 2004 15:45:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3LQr-0001dc-PG; Tue, 16 Mar 2004 15:45:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3LQk-0001d5-RV for mip4@optimus.ietf.org; Tue, 16 Mar 2004 15:44:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23166 for ; Tue, 16 Mar 2004 15:44:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3LQj-000689-00 for mip4@ietf.org; Tue, 16 Mar 2004 15:44:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3LPo-00064G-00 for mip4@ietf.org; Tue, 16 Mar 2004 15:43:57 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1B3LPf-000604-00 for mip4@ietf.org; Tue, 16 Mar 2004 15:43:47 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i2GKh5u02484; Tue, 16 Mar 2004 12:43:05 -0800 X-mProtect: <200403162043> Nokia Silicon Valley Messaging Protection Received: from mvdhcp141142.americas.nokia.com (172.18.141.142, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdjHNOsc; Tue, 16 Mar 2004 12:43:02 PST Message-ID: <405766CB.4040205@iprg.nokia.com> Date: Tue, 16 Mar 2004 12:42:51 -0800 From: "Charles E. Perkins" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kent Leung CC: Sri Gundavelli , mip4@ietf.org Subject: Re: [Mip4] Re: [Issue 45] RFC 3344 - FHAE issue when using a different careofaddress References: <4.3.2.7.2.20040315150256.02f87b38@mira-sjcm-2.cisco.com> <405258AA.10FC70EF@iprg.nokia.com> <4053CCD5.FE977E69@cisco.com> <4.3.2 In-Reply-To: <4.3.2.7.2.20040316112450.02bfb150@mira-sjcm-2.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Kent, Now, I see the problem that you were referring to. Briefly, if the following conditions are met: - MN is deregistering - MN is not located at the care-of address in the deregistration message, and - NAT, there isn't any logical way for the home agent to figure out what foreign agent is presenting the FHAE. For this purpose, we could: 1. use the SPI 2. specify that FHAE is invalid with deregistrations from other foreign agents 3. use the FA-NAI extension as specified in the Mobile IPv4 Regional Registrations draft which seems to be completely done except that it has not yet been published ...?? 4. make a new extension 5. fuggedaboudit (just kidding) Is this really a case of interest in practice? If not, then I would be just as happy with (2) Regards, Charlie P. Kent Leung wrote: > Hi Charlie. > > I think the issue is how does HA authenticate the FHAE when > MN sends a deregistration message? HA needs a security association > with the FA, which is typically identified by the CoA (assuming FA > providing service to MN). The source IP address RRQ from FA is the > transmitting interface's IP address (until RFC 3519). So an FA with > multiple interfaces would likely use CoA to identify itself for the SA > with HA. But MN has to set the CoA field to the address used as index > to remove the right mobility binding on HA. What I meant by Day One > problem is when FA is identified by the CoA field only, which seems > practical. > > Maybe I missed the solution that covered this case? > > The statement, "The home agent has to follow special rules in order > to identify the foreign agent which created the data in the > Foreign-Home authentication extension.", doesn't provide information > on exactly how the FA is actually identified in the registration > request message. There are 2 fields, source IP address and CoA, > but neither is sufficient given that source IP address may be NAT'ed > and CoA is what MN wants to deregister. > > That was the reason behind proposing some extension to identify > the FA clearly for HA to look up the SA. I agree that we don't want > to have any unnecessary extensions. :) > > Kent > > At 09:14 AM 3/16/2004 -0800, Charles E. Perkins wrote: > >> Hello Kent, >> >> I didn't see exactly what remained to be done. I'd rather not >> make new extensions unnecessarily. >> >> Kent Leung wrote: >> >>> Do we need a solution for the case of MN sending deregistration for a >>> particular CoA? >> >> >> It could be that we already have a solution, yes? >> >>> For registrations, the CoA should be set as CCoA or FA CoA. But >>> for deregistratations, maybe we should have an extension that contains >>> the CoA to be deregistered? This could be either the selected CoA >>> (in case of simultaneous bindings), previous CoA, or HoA for all >>> bindings. >> >> >> But these cases are already covered, I think. >> >>> This scheme would clearly identify the FA for FHAE authentication >>> and which CoA(s) the MN wish to deregister. >> >> >> Whether or not the FHAE is applied should be invisible to the >> mobile node. >> >>> Basically, this problem existed from Day One (since RFC 2002) and maybe >>> this is a good time to resolve it? >> >> >> I thought the problem didn't exist until RFC 3519. >> >> Regards, >> Charlie P. >> >> =================================================== >> >>>> > I'm not sure if we should just assume the home agent will some >>>> > how identify the security association for validating the FHAE. In >>>> > this scenario, the home agent would have no means to identify >>>> > the mobility entity that is forwarding the request. >>>> >>>> I think you mean that, the home agent would, in _some_ >>>> circumstances, be unable to validate based on the source >>>> IP address in the Registration Request, as you detail >>>> below. In other circumstances, of course the home agent >>>> would have the means. >>>> >>>> > Home agent >>>> > cannot use the care-of address for indexing the security association >>>> > as it is a dereg request from a mobile node for a binding it >>>> obtained >>>> > thru a different foreign agent. Home agent cannot also use the >>>> > source address of the registration request for the security >>>> > association lookup, as the address could potentially be a NAT >>>> > gateway address, scenario supported by RFC 3519. >>>> >>>> If I understand it, this is the only objection to using the >>>> IP source address. >>>> >>>> > SPI alone is not sufficient for any entity to identify the security >>>> > association. It is always with in the context of two entities. >>>> >>>> Well, there's 4 billion of them, and that ought to be enough >>>> to guarantee uniqueness. But as I mentioned before, I don't >>>> propose that we need to haggle about this just yet unless no >>>> other way suffices. >>>> >>>> > If the home agent cannot always identify the peer using the source >>>> > address or care-of address of the dereg request, then the home >>>> > agent would not be able to locate the security association. >>>> >>>> Here is a proposal for further comment. It might work. >>>> >>>> We can specify the following: >>>> >>>> - The home agent has to follow special rules in order >>>> to identify the foreign agent which created the >>>> data in the Foreign-Home authentication extension. >>>> >>>> - This method is only valid for Registration Requests >>>> with the 'D' bit zero. >>>> >>>> - The foreign agent is identified by using the >>>> "Care-of Address" field in the Registration Request >>>> >>>> If this is acceptable (i.e., I didn't miss the point), >>>> I will make the appropriate changes to the text. >>>> >>>> Regards, >>>> Charlie P. >>>> >>>> -- >>>> Mip4 mailing list: Mip4@ietf.org >>>> Web interface: https://www.ietf.org/mailman/listinfo/mip4 >>>> Charter page: http://www.ietf.org/html.charters/mip4-charter.html >>>> Supplemental site: http://www.mip4.org/ >>> >>> >>> >>> >>> --DS8073626969754241571-- >> >> > > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Tue Mar 16 16:08:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24678 for ; Tue, 16 Mar 2004 16:08:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Ln1-00031Q-5O for mip4-archive@odin.ietf.org; Tue, 16 Mar 2004 16:07:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2GL7tew011615 for mip4-archive@odin.ietf.org; Tue, 16 Mar 2004 16:07:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Ln0-000318-QG for mip4-web-archive@optimus.ietf.org; Tue, 16 Mar 2004 16:07:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24664 for ; Tue, 16 Mar 2004 16:07:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3Lmz-0000ml-00 for mip4-web-archive@ietf.org; Tue, 16 Mar 2004 16:07:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3Lm3-0000hv-00 for mip4-web-archive@ietf.org; Tue, 16 Mar 2004 16:06:56 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B3LlC-0000dp-00 for mip4-web-archive@ietf.org; Tue, 16 Mar 2004 16:06:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B3LlC-0008J9-LX for mip4-web-archive@ietf.org; Tue, 16 Mar 2004 16:06:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3LlC-0002iZ-3q; Tue, 16 Mar 2004 16:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Ll3-0002i0-3a for mip4@optimus.ietf.org; Tue, 16 Mar 2004 16:05:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24639 for ; Tue, 16 Mar 2004 16:05:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3Ll1-0000cn-00 for mip4@ietf.org; Tue, 16 Mar 2004 16:05:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3Lk8-0000Yn-00 for mip4@ietf.org; Tue, 16 Mar 2004 16:04:57 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B3LjJ-0000PY-00 for mip4@ietf.org; Tue, 16 Mar 2004 16:04:05 -0500 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i2GL3WaD004097; Tue, 16 Mar 2004 13:03:33 -0800 (PST) Received: from kleung-w2k01.cisco.com (sjc-vpn3-280.cisco.com [10.21.65.24]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ARF37320; Tue, 16 Mar 2004 13:03:32 -0800 (PST) Message-Id: <4.3.2.7.2.20040316125154.027bc878@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 16 Mar 2004 13:03:31 -0800 To: "Charles E. Perkins" From: Kent Leung Subject: Re: [Mip4] Re: [Issue 45] RFC 3344 - FHAE issue when using a different careofaddress Cc: Sri Gundavelli , mip4@ietf.org In-Reply-To: <405766CB.4040205@iprg.nokia.com> References: <4.3.2.7.2.20040316112450.02bfb150@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040315150256.02f87b38@mira-sjcm-2.cisco.com> <405258AA.10FC70EF@iprg.nokia.com> <4053CCD5.FE977E69@cisco.com> <4.3.2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.3 required=5.0 tests=AWL,NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 I thought you were going to be happy with #5. :) Going with #2 means that MN would not be able to successfully deregister any previous CoA. And because FHAE fails, MN would not know if the deregistration request got lost instead and have to retry. We do have cases in practice when a previous mobility binding needs to be cleaned up. Deleting a specific binding is supported by base protocol. We shouldn't lose this capability as we add new features such as RFC 3519. Use of FA NAI sounds reasonable and generic FA identifier will come in handy for future features. I would go for #3, though only need FA NAI extension. Kent At 12:42 PM 3/16/2004 -0800, Charles E. Perkins wrote: >Hello Kent, > >Now, I see the problem that you were referring to. > >Briefly, if the following conditions are met: >- MN is deregistering >- MN is not located at the care-of address > in the deregistration message, and >- NAT, >there isn't any logical way for the home agent >to figure out what foreign agent is presenting >the FHAE. For this purpose, we could: >1. use the SPI >2. specify that FHAE is invalid with deregistrations > from other foreign agents >3. use the FA-NAI extension as specified in the > Mobile IPv4 Regional Registrations draft which > seems to be completely done except that it has > not yet been published ...?? >4. make a new extension >5. fuggedaboudit (just kidding) > >Is this really a case of interest in practice? >If not, then I would be just as happy with (2) > >Regards, >Charlie P. > > >Kent Leung wrote: > >>Hi Charlie. >> >>I think the issue is how does HA authenticate the FHAE when >>MN sends a deregistration message? HA needs a security association >>with the FA, which is typically identified by the CoA (assuming FA >>providing service to MN). The source IP address RRQ from FA is the >>transmitting interface's IP address (until RFC 3519). So an FA with >>multiple interfaces would likely use CoA to identify itself for the SA >>with HA. But MN has to set the CoA field to the address used as index >>to remove the right mobility binding on HA. What I meant by Day One >>problem is when FA is identified by the CoA field only, which seems >>practical. >> >>Maybe I missed the solution that covered this case? >> >>The statement, "The home agent has to follow special rules in order >>to identify the foreign agent which created the data in the >>Foreign-Home authentication extension.", doesn't provide information >>on exactly how the FA is actually identified in the registration >>request message. There are 2 fields, source IP address and CoA, >>but neither is sufficient given that source IP address may be NAT'ed >>and CoA is what MN wants to deregister. >> >>That was the reason behind proposing some extension to identify >>the FA clearly for HA to look up the SA. I agree that we don't want >>to have any unnecessary extensions. :) >> >>Kent >> >>At 09:14 AM 3/16/2004 -0800, Charles E. Perkins wrote: >> >>>Hello Kent, >>> >>>I didn't see exactly what remained to be done. I'd rather not >>>make new extensions unnecessarily. >>> >>>Kent Leung wrote: >>> >>>>Do we need a solution for the case of MN sending deregistration for a >>>>particular CoA? >>> >>> >>>It could be that we already have a solution, yes? >>> >>>>For registrations, the CoA should be set as CCoA or FA CoA. But >>>>for deregistratations, maybe we should have an extension that contains >>>>the CoA to be deregistered? This could be either the selected CoA >>>>(in case of simultaneous bindings), previous CoA, or HoA for all bindings. >>> >>> >>>But these cases are already covered, I think. >>> >>>>This scheme would clearly identify the FA for FHAE authentication >>>>and which CoA(s) the MN wish to deregister. >>> >>> >>>Whether or not the FHAE is applied should be invisible to the >>>mobile node. >>> >>>>Basically, this problem existed from Day One (since RFC 2002) and maybe >>>>this is a good time to resolve it? >>> >>> >>>I thought the problem didn't exist until RFC 3519. >>> >>>Regards, >>>Charlie P. >>> >>>=================================================== >>> >>>>> > I'm not sure if we should just assume the home agent will some >>>>> > how identify the security association for validating the FHAE. In >>>>> > this scenario, the home agent would have no means to identify >>>>> > the mobility entity that is forwarding the request. >>>>> >>>>>I think you mean that, the home agent would, in _some_ >>>>>circumstances, be unable to validate based on the source >>>>>IP address in the Registration Request, as you detail >>>>>below. In other circumstances, of course the home agent >>>>>would have the means. >>>>> >>>>> > Home agent >>>>> > cannot use the care-of address for indexing the security association >>>>> > as it is a dereg request from a mobile node for a binding it obtained >>>>> > thru a different foreign agent. Home agent cannot also use the >>>>> > source address of the registration request for the security >>>>> > association lookup, as the address could potentially be a NAT >>>>> > gateway address, scenario supported by RFC 3519. >>>>> >>>>>If I understand it, this is the only objection to using the >>>>>IP source address. >>>>> >>>>> > SPI alone is not sufficient for any entity to identify the security >>>>> > association. It is always with in the context of two entities. >>>>> >>>>>Well, there's 4 billion of them, and that ought to be enough >>>>>to guarantee uniqueness. But as I mentioned before, I don't >>>>>propose that we need to haggle about this just yet unless no >>>>>other way suffices. >>>>> >>>>> > If the home agent cannot always identify the peer using the source >>>>> > address or care-of address of the dereg request, then the home >>>>> > agent would not be able to locate the security association. >>>>> >>>>>Here is a proposal for further comment. It might work. >>>>> >>>>>We can specify the following: >>>>> >>>>>- The home agent has to follow special rules in order >>>>> to identify the foreign agent which created the >>>>> data in the Foreign-Home authentication extension. >>>>> >>>>>- This method is only valid for Registration Requests >>>>> with the 'D' bit zero. >>>>> >>>>>- The foreign agent is identified by using the >>>>> "Care-of Address" field in the Registration Request >>>>> >>>>>If this is acceptable (i.e., I didn't miss the point), >>>>>I will make the appropriate changes to the text. >>>>> >>>>>Regards, >>>>>Charlie P. >>>>> >>>>>-- >>>>>Mip4 mailing list: Mip4@ietf.org >>>>> Web interface: https://www.ietf.org/mailman/listinfo/mip4 >>>>> Charter page: http://www.ietf.org/html.charters/mip4-charter.html >>>>>Supplemental site: http://www.mip4.org/ >>>> >>>> >>>> >>>> >>>>--DS8073626969754241571-- >>> >> > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Tue Mar 16 16:21:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25308 for ; Tue, 16 Mar 2004 16:21:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Lzb-00043T-JP for mip4-archive@odin.ietf.org; Tue, 16 Mar 2004 16:20:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2GLKsPM015583 for mip4-archive@odin.ietf.org; Tue, 16 Mar 2004 16:20:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3LzZ-00043G-Gw for mip4-web-archive@optimus.ietf.org; Tue, 16 Mar 2004 16:20:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25285 for ; Tue, 16 Mar 2004 16:20:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3LzX-0002Ft-00 for mip4-web-archive@ietf.org; Tue, 16 Mar 2004 16:20:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3Lyb-00026V-00 for mip4-web-archive@ietf.org; Tue, 16 Mar 2004 16:19:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3Lxj-00020m-00 for mip4-web-archive@ietf.org; Tue, 16 Mar 2004 16:19:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Lxk-0003vc-Kc; Tue, 16 Mar 2004 16:19:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Lxf-0003uy-3P for mip4@optimus.ietf.org; Tue, 16 Mar 2004 16:18:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25142 for ; Tue, 16 Mar 2004 16:18:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3Lxd-0001ze-00 for mip4@ietf.org; Tue, 16 Mar 2004 16:18:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3Lwh-0001ut-00 for mip4@ietf.org; Tue, 16 Mar 2004 16:17:56 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1B3Lvq-0001kn-00 for mip4@ietf.org; Tue, 16 Mar 2004 16:17:02 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i2GLGN803346; Tue, 16 Mar 2004 13:16:23 -0800 X-mProtect: <200403162116> Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd4aJzEh; Tue, 16 Mar 2004 13:16:19 PST Message-ID: <40576E9A.10330721@iprg.nokia.com> Date: Tue, 16 Mar 2004 13:16:10 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Kent Leung CC: mip4@ietf.org Subject: Re: [Mip4] Re: [Issue 45] RFC 3344 - FHAE issue when using a different careofaddress References: <4.3.2.7.2.20040316112450.02bfb150@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040315150256.02f87b38@mira-sjcm-2.cisco.com> <405258AA.10F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Kent, I'd like to discuss just this one point before going forward: Kent Leung wrote: > Going with #2 means that MN would not be able to successfully > deregister any previous CoA. And because FHAE fails, MN > would not know if the deregistration request got lost instead > and have to retry. This isn't necessarily true. We could specify the following, given that the treatment of FHAE is completely under control of the Mobile IPv4 document. For instance, it isn't normatively dependent on IPsec documents. Here's a proposal: - If there is a mobility security association between the home agent and the foreign agent, then FHAE is required on all registrations with lifetime > 0. - If the FHAE is present on a deregistration message, the home agent has to check it. - If the FHAE is not present, but the Mobile-Home authentication extension checks, then the home agent MUST (?SHOULD?) expunge the indicated care-of address from its list of care-of addresses registered for that mobile node. Note that the FHAE doesn't seem to be related to the content of such a deregistration message in the same way as it might be for a registration message. If the mobile node wants to discontinue service, I don't see why a foreign agent in this scenario should have anything to say about it. In fact, maybe we should mandate that the foreign agent MUST NOT include the FHAE, even if it does have a security association. It could be a way to keep the mobile node paying for service it does not want. Regards, Charlie P. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Tue Mar 16 17:55:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02095 for ; Tue, 16 Mar 2004 17:55:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3NSc-0002NC-KT for mip4-archive@odin.ietf.org; Tue, 16 Mar 2004 17:54:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2GMswm7009119 for mip4-archive@odin.ietf.org; Tue, 16 Mar 2004 17:54:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3NSc-0002N0-Dr for mip4-web-archive@optimus.ietf.org; Tue, 16 Mar 2004 17:54:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02051 for ; Tue, 16 Mar 2004 17:54:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3NSZ-00071O-00 for mip4-web-archive@ietf.org; Tue, 16 Mar 2004 17:54:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3NRe-0006tU-00 for mip4-web-archive@ietf.org; Tue, 16 Mar 2004 17:53:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3NQi-0006lR-00 for mip4-web-archive@ietf.org; Tue, 16 Mar 2004 17:53:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3NQi-0002Bd-PC; Tue, 16 Mar 2004 17:53:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3NPw-00029t-Fe for mip4@optimus.ietf.org; Tue, 16 Mar 2004 17:52:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01907 for ; Tue, 16 Mar 2004 17:52:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3NPt-0006eM-00 for mip4@ietf.org; Tue, 16 Mar 2004 17:52:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3NOs-0006VE-00 for mip4@ietf.org; Tue, 16 Mar 2004 17:51:06 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B3NNq-0006GB-00 for mip4@ietf.org; Tue, 16 Mar 2004 17:50:02 -0500 Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.70.65.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2GMnUM8029688; Tue, 16 Mar 2004 14:49:31 -0800 (PST) Date: Tue, 16 Mar 2004 14:49:30 -0800 (PST) From: Sri Gundavelli To: "Charles E. Perkins" cc: Kent Leung , mip4@ietf.org Subject: Re: [Mip4] Re: [Issue 45] RFC 3344 - FHAE issue when using a different careofaddress In-Reply-To: <40576E9A.10330721@iprg.nokia.com> Message-ID: References: <4.3.2.7.2.20040316112450.02bfb150@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040315150256.02f87b38@mira-sjcm-2.cisco.com> <405258AA.10F <40576E9A.10330721@iprg.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Tue, 16 Mar 2004, Charles E. Perkins wrote: > > Hello Kent, > > I'd like to discuss just this one point before going > forward: > > Kent Leung wrote: > > > Going with #2 means that MN would not be able to successfully > > deregister any previous CoA. And because FHAE fails, MN > > would not know if the deregistration request got lost instead > > and have to retry. > > This isn't necessarily true. We could specify the > following, given that the treatment of FHAE is > completely under control of the Mobile IPv4 > document. For instance, it isn't normatively > dependent on IPsec documents. > > Here's a proposal: > > - If there is a mobility security association between > the home agent and the foreign agent, then FHAE is > required on all registrations with lifetime > 0. > - If the FHAE is present on a deregistration message, > the home agent has to check it. > - If the FHAE is not present, but the Mobile-Home > authentication extension checks, then the home agent > MUST (?SHOULD?) expunge the indicated care-of address > from its list of care-of addresses registered for that > mobile node. > > Note that the FHAE doesn't seem to be related to the > content of such a deregistration message in the same > way as it might be for a registration message. > If the mobile node wants to discontinue service, > I don't see why a foreign agent in this scenario > should have anything to say about it. In fact, > maybe we should mandate that the foreign agent > MUST NOT include the FHAE, even if it does have > a security association. It could be a way to > keep the mobile node paying for service it does > not want. Hi Charlie, Should we not be consistent w.r.t adding FHAE extensions for all registration requests irrespective of the lifetime ? With the above reasoning, we may not need FHAE at all. There will always be a need for the FA to protect the extensions it adds to the registration requests and so skipping FHAE for dereg messages in one scenario may not be such a good idea, IMHO. Sri. > > Regards, > Charlie P. > > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Tue Mar 16 18:17:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04462 for ; Tue, 16 Mar 2004 18:17:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3No0-0000hO-Dj for mip4-archive@odin.ietf.org; Tue, 16 Mar 2004 18:17:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2GNH4I0002677 for mip4-archive@odin.ietf.org; Tue, 16 Mar 2004 18:17:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3No0-0000h6-7c for mip4-web-archive@optimus.ietf.org; Tue, 16 Mar 2004 18:17:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04407 for ; Tue, 16 Mar 2004 18:16:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3Nnx-0001wr-00 for mip4-web-archive@ietf.org; Tue, 16 Mar 2004 18:17:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3Nmy-0001pQ-00 for mip4-web-archive@ietf.org; Tue, 16 Mar 2004 18:16:00 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B3Nm3-0001iv-00 for mip4-web-archive@ietf.org; Tue, 16 Mar 2004 18:15:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B3Nm3-00025V-Sj for mip4-web-archive@ietf.org; Tue, 16 Mar 2004 18:15:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Nm3-00009d-PV; Tue, 16 Mar 2004 18:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3NlQ-0008Rn-R6 for mip4@optimus.ietf.org; Tue, 16 Mar 2004 18:14:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04157 for ; Tue, 16 Mar 2004 18:14:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3NlN-0001d5-00 for mip4@ietf.org; Tue, 16 Mar 2004 18:14:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3NkY-0001VC-00 for mip4@ietf.org; Tue, 16 Mar 2004 18:13:31 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1B3Njn-0001Hg-00 for mip4@ietf.org; Tue, 16 Mar 2004 18:12:43 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i2GNC4M06634; Tue, 16 Mar 2004 15:12:04 -0800 X-mProtect: <200403162312> Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdju5Hfl; Tue, 16 Mar 2004 15:12:03 PST Message-ID: <405789B8.E089FBEC@iprg.nokia.com> Date: Tue, 16 Mar 2004 15:11:52 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Sri Gundavelli CC: Kent Leung , mip4@ietf.org Subject: Re: [Mip4] Re: [Issue 45] RFC 3344 - FHAE issue when using a different careofaddress References: <4.3.2.7.2.20040316112450.02bfb150@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040315150256.02f87b38@mira-sjcm-2.cisco.com> <405258AA.10F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,SUBJ_HAS_SPACES autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Sri, Sri Gundavelli wrote: >> Note that the FHAE doesn't seem to be related to the >> content of such a deregistration message in the same >> way as it might be for a registration message. >> If the mobile node wants to discontinue service, >> I don't see why a foreign agent in this scenario >> should have anything to say about it. In fact, >> maybe we should mandate that the foreign agent >> MUST NOT include the FHAE, even if it does have >> a security association. It could be a way to >> keep the mobile node paying for service it does >> not want. > Should we not be consistent w.r.t adding FHAE extensions > for all registration requests irrespective of the lifetime ? > With the above reasoning, we may not need FHAE at all. There > will always be a need for the FA to protect the extensions > it adds to the registration requests and so skipping FHAE > for dereg messages in one scenario may not be such a good > idea, IMHO. My reasoning was that in this scenario, the foreign agent does not necessarily have any authority over the treatment of the care-of address. Thus, the home agent has much less reason to authenticate the foreign agent. When the foreign agent purports to own the care-of address, I can see why the home agent would want to be more careful about the registration process. Don't you agree there is a difference? Regards, Charlie P. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Tue Mar 16 20:58:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12697 for ; Tue, 16 Mar 2004 20:58:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3QJm-0003vj-EN for mip4-archive@odin.ietf.org; Tue, 16 Mar 2004 20:58:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2H1w2G2015107 for mip4-archive@odin.ietf.org; Tue, 16 Mar 2004 20:58:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3QJm-0003va-7U for mip4-web-archive@optimus.ietf.org; Tue, 16 Mar 2004 20:58:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12682 for ; Tue, 16 Mar 2004 20:57:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3QJj-0004Xs-00 for mip4-web-archive@ietf.org; Tue, 16 Mar 2004 20:57:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3QIm-0004Sc-00 for mip4-web-archive@ietf.org; Tue, 16 Mar 2004 20:57:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3QHo-0004Mh-00 for mip4-web-archive@ietf.org; Tue, 16 Mar 2004 20:56:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3QHp-0003ny-Bo; Tue, 16 Mar 2004 20:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3QHP-0003n7-Bh for mip4@optimus.ietf.org; Tue, 16 Mar 2004 20:55:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12614 for ; Tue, 16 Mar 2004 20:55:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3QHM-0004IU-00 for mip4@ietf.org; Tue, 16 Mar 2004 20:55:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3QGZ-0004Bn-00 for mip4@ietf.org; Tue, 16 Mar 2004 20:54:44 -0500 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1B3QFQ-00040T-00 for mip4@ietf.org; Tue, 16 Mar 2004 20:53:32 -0500 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by hoemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2H1qnc29945; Tue, 16 Mar 2004 19:52:49 -0600 (CST) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id i2H1qlE01676; Tue, 16 Mar 2004 19:52:47 -0600 (CST) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HUP6JL-0000X0-00; Tue, 16 Mar 2004 20:52:33 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16471.44904.331811.334369@gargle.gargle.HOWL> Date: Tue, 16 Mar 2004 19:52:40 -0600 From: Pete McCann To: Kent Leung Cc: "Charles E. Perkins" , Sri Gundavelli , mip4@ietf.org Subject: Re: [Mip4] Re: [Issue 45] RFC 3344 - FHAE issue when using a different careofaddress In-Reply-To: <4.3.2.7.2.20040316112450.02bfb150@mira-sjcm-2.cisco.com> References: <4.3.2.7.2.20040315150256.02f87b38@mira-sjcm-2.cisco.com> <405258AA.10FC70EF@iprg.nokia.com> <4053CCD5.FE977E69@cisco.com> <4.3.2.7.2.20040316112450.02bfb150@mira-sjcm-2.cisco.com> X-Mailer: VM 7.14 under 21.5 (beta14) "cassava" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I think we are going down a rat-hole here for the sake of a corner case. I would rather not make extensive changes to our core Mobile IP protocol simply for the sake of NAT traversal. It seems that de-registration is a special case where the FHAE is of less importance. That is, the FA should not prevent a de-registration from taking place. Note that the "D" bit only determines whether the MN is doing de-capsulation, not whether the registration request traversed a foreign agent (you can register with an FA even in co-located CoA). I am not sure if this point is getting glossed over in the discussion below. Perhaps the right approach is to specify the FA MUST NOT append FHAE when the lifetime=0, as Charlie suggested earlier in the thread. Also, the HA MAY/MUST ignore any such FHAE, assuming it can independently verify the MHAE in the same message. Alternatively, maybe we should encourage de-registrations to go directly from the MN to the HA, ignoring the 'R' bit from agent advertisements. -Pete Kent Leung writes: > Hi Charlie. > > I think the issue is how does HA authenticate the FHAE when > MN sends a deregistration message? HA needs a security association > with the FA, which is typically identified by the CoA (assuming FA > providing service to MN). The source IP address RRQ from FA is the > transmitting interface's IP address (until RFC 3519). So an FA with > multiple interfaces would likely use CoA to identify itself for the SA > with HA. But MN has to set the CoA field to the address used as index > to remove the right mobility binding on HA. What I meant by Day One > problem is when FA is identified by the CoA field only, which seems > practical. > > Maybe I missed the solution that covered this case? > > The statement, "The home agent has to follow special rules in order > to identify the foreign agent which created the data in the > Foreign-Home authentication extension.", doesn't provide information > on exactly how the FA is actually identified in the registration > request message. There are 2 fields, source IP address and CoA, > but neither is sufficient given that source IP address may be NAT'ed > and CoA is what MN wants to deregister. > > That was the reason behind proposing some extension to identify > the FA clearly for HA to look up the SA. I agree that we don't want > to have any unnecessary extensions. :) > > Kent > > At 09:14 AM 3/16/2004 -0800, Charles E. Perkins wrote: > > >Hello Kent, > > > >I didn't see exactly what remained to be done. I'd rather not > >make new extensions unnecessarily. > > > >Kent Leung wrote: > > > >>Do we need a solution for the case of MN sending deregistration for a > >>particular CoA? > > > >It could be that we already have a solution, yes? > > > >>For registrations, the CoA should be set as CCoA or FA CoA. But > >>for deregistratations, maybe we should have an extension that contains > >>the CoA to be deregistered? This could be either the selected CoA > >>(in case of simultaneous bindings), previous CoA, or HoA for all bindings. > > > >But these cases are already covered, I think. > > > >>This scheme would clearly identify the FA for FHAE authentication > >>and which CoA(s) the MN wish to deregister. > > > >Whether or not the FHAE is applied should be invisible to the > >mobile node. > > > >>Basically, this problem existed from Day One (since RFC 2002) and maybe > >>this is a good time to resolve it? > > > >I thought the problem didn't exist until RFC 3519. > > > >Regards, > >Charlie P. > > > >=================================================== > > > >>> > I'm not sure if we should just assume the home agent will some > >>> > how identify the security association for validating the FHAE. In > >>> > this scenario, the home agent would have no means to identify > >>> > the mobility entity that is forwarding the request. > >>> > >>>I think you mean that, the home agent would, in _some_ > >>>circumstances, be unable to validate based on the source > >>>IP address in the Registration Request, as you detail > >>>below. In other circumstances, of course the home agent > >>>would have the means. > >>> > >>> > Home agent > >>> > cannot use the care-of address for indexing the security association > >>> > as it is a dereg request from a mobile node for a binding it obtained > >>> > thru a different foreign agent. Home agent cannot also use the > >>> > source address of the registration request for the security > >>> > association lookup, as the address could potentially be a NAT > >>> > gateway address, scenario supported by RFC 3519. > >>> > >>>If I understand it, this is the only objection to using the > >>>IP source address. > >>> > >>> > SPI alone is not sufficient for any entity to identify the security > >>> > association. It is always with in the context of two entities. > >>> > >>>Well, there's 4 billion of them, and that ought to be enough > >>>to guarantee uniqueness. But as I mentioned before, I don't > >>>propose that we need to haggle about this just yet unless no > >>>other way suffices. > >>> > >>> > If the home agent cannot always identify the peer using the source > >>> > address or care-of address of the dereg request, then the home > >>> > agent would not be able to locate the security association. > >>> > >>>Here is a proposal for further comment. It might work. > >>> > >>>We can specify the following: > >>> > >>>- The home agent has to follow special rules in order > >>> to identify the foreign agent which created the > >>> data in the Foreign-Home authentication extension. > >>> > >>>- This method is only valid for Registration Requests > >>> with the 'D' bit zero. > >>> > >>>- The foreign agent is identified by using the > >>> "Care-of Address" field in the Registration Request > >>> > >>>If this is acceptable (i.e., I didn't miss the point), > >>>I will make the appropriate changes to the text. > >>> > >>>Regards, > >>>Charlie P. > >>> > >>>-- > >>>Mip4 mailing list: Mip4@ietf.org > >>> Web interface: https://www.ietf.org/mailman/listinfo/mip4 > >>> Charter page: http://www.ietf.org/html.charters/mip4-charter.html > >>>Supplemental site: http://www.mip4.org/ > >> > >> > >> > >>--DS8073626969754241571-- > > > > > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Tue Mar 16 22:32:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16423 for ; Tue, 16 Mar 2004 22:32:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Rmp-0001S9-NP for mip4-archive@odin.ietf.org; Tue, 16 Mar 2004 22:32:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2H3W7eA005579 for mip4-archive@odin.ietf.org; Tue, 16 Mar 2004 22:32:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Rmp-0001Rj-98 for mip4-web-archive@optimus.ietf.org; Tue, 16 Mar 2004 22:32:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16411 for ; Tue, 16 Mar 2004 22:32:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3Rml-0006fb-00 for mip4-web-archive@ietf.org; Tue, 16 Mar 2004 22:32:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3Rlm-0006ZW-00 for mip4-web-archive@ietf.org; Tue, 16 Mar 2004 22:31:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3Rko-0006U8-00 for mip4-web-archive@ietf.org; Tue, 16 Mar 2004 22:30:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Rkn-0001LV-HX; Tue, 16 Mar 2004 22:30:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Rjy-0001ES-0u for mip4@optimus.ietf.org; Tue, 16 Mar 2004 22:29:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16364 for ; Tue, 16 Mar 2004 22:29:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3Rju-0006PO-00 for mip4@ietf.org; Tue, 16 Mar 2004 22:29:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3Riz-0006KJ-00 for mip4@ietf.org; Tue, 16 Mar 2004 22:28:11 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B3RiN-0006Bk-00 for mip4@ietf.org; Tue, 16 Mar 2004 22:27:31 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 16 Mar 2004 19:31:47 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i2H3R0aD018211; Tue, 16 Mar 2004 19:27:00 -0800 (PST) Received: from kleung-w2k01.cisco.com (sjc-vpn3-280.cisco.com [10.21.65.24]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ARF70131; Tue, 16 Mar 2004 19:26:58 -0800 (PST) Message-Id: <4.3.2.7.2.20040316184554.0286ccf0@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 16 Mar 2004 19:26:57 -0800 To: Pete McCann From: Kent Leung Subject: Re: [Mip4] Re: [Issue 45] RFC 3344 - FHAE issue when using a different careofaddress Cc: "Charles E. Perkins" , Sri Gundavelli , mip4@ietf.org In-Reply-To: <16471.44904.331811.334369@gargle.gargle.HOWL> References: <4.3.2.7.2.20040316112450.02bfb150@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040315150256.02f87b38@mira-sjcm-2.cisco.com> <405258AA.10FC70EF@iprg.nokia.com> <4053CCD5.FE977E69@cisco.com> <4.3.2.7.2.20040316112450.02bfb150@mira-sjcm-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.3 required=5.0 tests=AWL,NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 Not to be nit-picky... NAT traversal is a common scenario. Base protocol supports deregistration using FHAE assuming FA is identified by source IP address instead of CoA. Deregistration of previous binding is needed for simultaneous bindings or load balanced bindings. IMHO, using an FA NAI extension doesn't seem to be extensive change, and generally useful to identify the FA clearly for FHAE and MFAE authentications. The CoA field is not sufficient since Day One to identify the FA. FA would not be preventing deregistration if it can identify itself in the registration message. :) In general, it seems that FA uses FHAE to protect the communication channel between FA and HA regardless what is exactly in the details of the message. Does having a special case to bypass the security association between FA and HA create new security holes? Is there a guarantee that all deregistrations today and in the future will not require authentication check? BTW, we have also thought of FA not adding FHAE for deregistrations and/or HA not processing FHAE too. But seems like there is some reason that administrator set up the SA between HA and FA, and bypassing that doesn't make us comfortable. And this special case would have to be considered for each enhancement we make to Mobile IP to access any security implications. It saves us some time now, but may cause more cumulative cycles afterwards in future ideas and drafts. Not to gloss over the R-bit issue. Another reason to clearly identify the FA so HA can authenticate FHAE using the right SA, IMHO. As for the idea of MN deregistering directly to HA by ignoring the R bit, I think the R bit would need to be enforced by the FA if it is advertising mandatory registration via the FA. If it's purely voluntary, MN can always bypass and the R bit has no effect. But if there is filter to prevent direct registration by MN, then encouragement to bypass the FA for deregistration won't work as such filters don't check on the content of the message. Sorry, not meaning to continue the rat-hole, but wanted to provide some reasons why eliminating FHAE may work against the wishes of the administrator who created the SA between the HA and FA. Might also create a loophole for oversight in future FA-HA extensions as well. Anyways, looking for a good solution to this issue so we can resolve and move on.. Kent At 07:52 PM 3/16/2004 -0600, Pete McCann wrote: >I think we are going down a rat-hole here for the sake of a corner >case. > >I would rather not make extensive changes to our core Mobile IP >protocol simply for the sake of NAT traversal. > >It seems that de-registration is a special case where the FHAE is of >less importance. That is, the FA should not prevent a de-registration >from taking place. > >Note that the "D" bit only determines whether the MN is doing >de-capsulation, not whether the registration request traversed a >foreign agent (you can register with an FA even in co-located CoA). I >am not sure if this point is getting glossed over in the discussion >below. > >Perhaps the right approach is to specify the FA MUST NOT append FHAE >when the lifetime=0, as Charlie suggested earlier in the thread. >Also, the HA MAY/MUST ignore any such FHAE, assuming it can >independently verify the MHAE in the same message. > >Alternatively, maybe we should encourage de-registrations to go >directly from the MN to the HA, ignoring the 'R' bit from agent >advertisements. > >-Pete > > >Kent Leung writes: > > Hi Charlie. > > > > I think the issue is how does HA authenticate the FHAE when > > MN sends a deregistration message? HA needs a security association > > with the FA, which is typically identified by the CoA (assuming FA > > providing service to MN). The source IP address RRQ from FA is the > > transmitting interface's IP address (until RFC 3519). So an FA with > > multiple interfaces would likely use CoA to identify itself for the SA > > with HA. But MN has to set the CoA field to the address used as index > > to remove the right mobility binding on HA. What I meant by Day One > > problem is when FA is identified by the CoA field only, which seems > > practical. > > > > Maybe I missed the solution that covered this case? > > > > The statement, "The home agent has to follow special rules in order > > to identify the foreign agent which created the data in the > > Foreign-Home authentication extension.", doesn't provide information > > on exactly how the FA is actually identified in the registration > > request message. There are 2 fields, source IP address and CoA, > > but neither is sufficient given that source IP address may be NAT'ed > > and CoA is what MN wants to deregister. > > > > That was the reason behind proposing some extension to identify > > the FA clearly for HA to look up the SA. I agree that we don't want > > to have any unnecessary extensions. :) > > > > Kent > > > > At 09:14 AM 3/16/2004 -0800, Charles E. Perkins wrote: > > > > >Hello Kent, > > > > > >I didn't see exactly what remained to be done. I'd rather not > > >make new extensions unnecessarily. > > > > > >Kent Leung wrote: > > > > > >>Do we need a solution for the case of MN sending deregistration for a > > >>particular CoA? > > > > > >It could be that we already have a solution, yes? > > > > > >>For registrations, the CoA should be set as CCoA or FA CoA. But > > >>for deregistratations, maybe we should have an extension that contains > > >>the CoA to be deregistered? This could be either the selected CoA > > >>(in case of simultaneous bindings), previous CoA, or HoA for all > bindings. > > > > > >But these cases are already covered, I think. > > > > > >>This scheme would clearly identify the FA for FHAE authentication > > >>and which CoA(s) the MN wish to deregister. > > > > > >Whether or not the FHAE is applied should be invisible to the > > >mobile node. > > > > > >>Basically, this problem existed from Day One (since RFC 2002) and maybe > > >>this is a good time to resolve it? > > > > > >I thought the problem didn't exist until RFC 3519. > > > > > >Regards, > > >Charlie P. > > > > > >=================================================== > > > > > >>> > I'm not sure if we should just assume the home agent will some > > >>> > how identify the security association for validating the FHAE. In > > >>> > this scenario, the home agent would have no means to identify > > >>> > the mobility entity that is forwarding the request. > > >>> > > >>>I think you mean that, the home agent would, in _some_ > > >>>circumstances, be unable to validate based on the source > > >>>IP address in the Registration Request, as you detail > > >>>below. In other circumstances, of course the home agent > > >>>would have the means. > > >>> > > >>> > Home agent > > >>> > cannot use the care-of address for indexing the security association > > >>> > as it is a dereg request from a mobile node for a binding it > obtained > > >>> > thru a different foreign agent. Home agent cannot also use the > > >>> > source address of the registration request for the security > > >>> > association lookup, as the address could potentially be a NAT > > >>> > gateway address, scenario supported by RFC 3519. > > >>> > > >>>If I understand it, this is the only objection to using the > > >>>IP source address. > > >>> > > >>> > SPI alone is not sufficient for any entity to identify the security > > >>> > association. It is always with in the context of two entities. > > >>> > > >>>Well, there's 4 billion of them, and that ought to be enough > > >>>to guarantee uniqueness. But as I mentioned before, I don't > > >>>propose that we need to haggle about this just yet unless no > > >>>other way suffices. > > >>> > > >>> > If the home agent cannot always identify the peer using the source > > >>> > address or care-of address of the dereg request, then the home > > >>> > agent would not be able to locate the security association. > > >>> > > >>>Here is a proposal for further comment. It might work. > > >>> > > >>>We can specify the following: > > >>> > > >>>- The home agent has to follow special rules in order > > >>> to identify the foreign agent which created the > > >>> data in the Foreign-Home authentication extension. > > >>> > > >>>- This method is only valid for Registration Requests > > >>> with the 'D' bit zero. > > >>> > > >>>- The foreign agent is identified by using the > > >>> "Care-of Address" field in the Registration Request > > >>> > > >>>If this is acceptable (i.e., I didn't miss the point), > > >>>I will make the appropriate changes to the text. > > >>> > > >>>Regards, > > >>>Charlie P. > > >>> > > >>>-- > > >>>Mip4 mailing list: Mip4@ietf.org > > >>> Web interface: https://www.ietf.org/mailman/listinfo/mip4 > > >>> Charter page: http://www.ietf.org/html.charters/mip4-charter.html > > >>>Supplemental site: http://www.mip4.org/ > > >> > > >> > > >> > > >>--DS8073626969754241571-- > > > > > > > > > -- > > Mip4 mailing list: Mip4@ietf.org > > Web interface: https://www.ietf.org/mailman/listinfo/mip4 > > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > > Supplemental site: http://www.mip4.org/ > > >-- >Mip4 mailing list: Mip4@ietf.org > Web interface: https://www.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html >Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Tue Mar 16 22:47:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17094 for ; Tue, 16 Mar 2004 22:47:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3S1M-0002VU-E1 for mip4-archive@odin.ietf.org; Tue, 16 Mar 2004 22:47:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2H3l8Jw009635 for mip4-archive@odin.ietf.org; Tue, 16 Mar 2004 22:47:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3S1M-0002VK-73 for mip4-web-archive@optimus.ietf.org; Tue, 16 Mar 2004 22:47:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17046 for ; Tue, 16 Mar 2004 22:47:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3S1I-0000Up-00 for mip4-web-archive@ietf.org; Tue, 16 Mar 2004 22:47:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3S0K-0000NI-00 for mip4-web-archive@ietf.org; Tue, 16 Mar 2004 22:46:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3RzK-0000Cv-00 for mip4-web-archive@ietf.org; Tue, 16 Mar 2004 22:45:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3RzK-0002ME-0N; Tue, 16 Mar 2004 22:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3RyU-0002Js-Q4 for mip4@optimus.ietf.org; Tue, 16 Mar 2004 22:44:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16804 for ; Tue, 16 Mar 2004 22:44:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3RyR-00007D-00 for mip4@ietf.org; Tue, 16 Mar 2004 22:44:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3RxX-0007mo-00 for mip4@ietf.org; Tue, 16 Mar 2004 22:43:11 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B3Rwa-0007bx-00 for mip4@ietf.org; Tue, 16 Mar 2004 22:42:13 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 16 Mar 2004 19:45:19 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i2H3ffK2004313; Tue, 16 Mar 2004 19:41:41 -0800 (PST) Received: from kleung-w2k01.cisco.com (sjc-vpn3-280.cisco.com [10.21.65.24]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ARF70673; Tue, 16 Mar 2004 19:41:40 -0800 (PST) Message-Id: <4.3.2.7.2.20040316192713.01cc8450@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 16 Mar 2004 19:41:38 -0800 To: "Charles E. Perkins" From: Kent Leung Subject: Re: [Mip4] Re: [Issue 45] RFC 3344 - FHAE issue when using a different careofaddress Cc: mip4@ietf.org In-Reply-To: <40576E9A.10330721@iprg.nokia.com> References: <4.3.2.7.2.20040316112450.02bfb150@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040315150256.02f87b38@mira-sjcm-2.cisco.com> <405258AA.10F> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.4 required=5.0 tests=AWL,NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 Hi Charlie. I thought #2 meant going with existing operation. I agree that FHAE behavior is in our hands. :) Comments below. At 01:16 PM 3/16/2004 -0800, Charles E. Perkins wrote: >Hello Kent, > >I'd like to discuss just this one point before going >forward: > >Kent Leung wrote: > > > Going with #2 means that MN would not be able to successfully > > deregister any previous CoA. And because FHAE fails, MN > > would not know if the deregistration request got lost instead > > and have to retry. > >This isn't necessarily true. We could specify the >following, given that the treatment of FHAE is >completely under control of the Mobile IPv4 >document. For instance, it isn't normatively >dependent on IPsec documents. > >Here's a proposal: > >- If there is a mobility security association between > the home agent and the foreign agent, then FHAE is > required on all registrations with lifetime > 0. >- If the FHAE is present on a deregistration message, > the home agent has to check it. This will likely cause the authentication to fail. Let's say that admin set up SA between HA and FA (either manually or AAA). The FHAE will be appended to the deregistration since FA can index the SA based on the HA field. But HA can't identify the FA to retrieve the right SA for authentication. >- If the FHAE is not present, but the Mobile-Home > authentication extension checks, then the home agent > MUST (?SHOULD?) expunge the indicated care-of address > from its list of care-of addresses registered for that > mobile node. > >Note that the FHAE doesn't seem to be related to the >content of such a deregistration message in the same >way as it might be for a registration message. >If the mobile node wants to discontinue service, >I don't see why a foreign agent in this scenario >should have anything to say about it. In fact, >maybe we should mandate that the foreign agent >MUST NOT include the FHAE, even if it does have >a security association. It could be a way to >keep the mobile node paying for service it does >not want. The FA wants to add the FHAE because it wants to secure the messages between itself and HA. There may be some extensions that FA adds which are relevant to the mobility binding. Avoiding FHAE seems to be a hack, IMHO. The root cause is lack of FA identifier to satisfy authentication process. Should we solve the problem by clearly identifying the FA using either the FA NAI or new extension (when CoA is insufficient)? Another value is that such extension and the CoA fields are protected. The source IP address is not, but the value of protecting the identifier can also be debated. :) Kent >Regards, >Charlie P. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Wed Mar 17 02:55:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24112 for ; Wed, 17 Mar 2004 02:55:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Vtb-0002x1-OO for mip4-archive@odin.ietf.org; Wed, 17 Mar 2004 02:55:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2H7tNLR011337 for mip4-archive@odin.ietf.org; Wed, 17 Mar 2004 02:55:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3VtY-0002wV-Rl for mip4-web-archive@optimus.ietf.org; Wed, 17 Mar 2004 02:55:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24072 for ; Wed, 17 Mar 2004 02:55:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3VtV-0004rD-00 for mip4-web-archive@ietf.org; Wed, 17 Mar 2004 02:55:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3VsY-0004iX-00 for mip4-web-archive@ietf.org; Wed, 17 Mar 2004 02:54:19 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3Vrb-0004Xn-00 for mip4-web-archive@ietf.org; Wed, 17 Mar 2004 02:53:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3VrM-0002ar-Tq; Wed, 17 Mar 2004 02:53:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3VrF-0002a6-Gw for mip4@optimus.ietf.org; Wed, 17 Mar 2004 02:52:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23778 for ; Wed, 17 Mar 2004 02:52:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3Vr1-0004Pp-00 for mip4@ietf.org; Wed, 17 Mar 2004 02:52:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3Vq5-0004FL-00 for mip4@ietf.org; Wed, 17 Mar 2004 02:51:45 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1B3Vp1-00040q-00 for mip4@ietf.org; Wed, 17 Mar 2004 02:50:39 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 16 Mar 2004 23:50:10 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i2H7o7WK011258; Tue, 16 Mar 2004 23:50:08 -0800 (PST) Received: from kleung-w2k01.cisco.com (sjc-vpn3-280.cisco.com [10.21.65.24]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ARF80879; Tue, 16 Mar 2004 23:50:06 -0800 (PST) Message-Id: <4.3.2.7.2.20040316233951.02698298@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 16 Mar 2004 23:50:06 -0800 To: "Charles E. Perkins" From: Kent Leung Subject: Re: [Mip4] Re: [Issue 44] RFC 3344 - Source Address of the RRQ Cc: ext Sri Gundavelli , mip4@ietf.org In-Reply-To: <40524D34.5E628689@iprg.nokia.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL autolearn=no version=2.60 Hi Charlie. Sorry for being late in this thread. Should we be more specific here? As you said, the FA may offer multiple CoA's. The MN chooses the CoA in the RRQ. It's important to RFC 3519 that this source IP address is consistent with the CoA in the RRQ. Possible text: Copied from the Care-of Address field within the Registration Request. This might be a bit more detail and accurate to support? Kent At 03:52 PM 3/12/2004 -0800, Charles E. Perkins wrote: >Hello Sri, > >This is regarding the new Issue 44. It seems that we both >tried to insert this issue at about the same time, so that >your text appears twice. Or else, I don't understand just >how the darned issue tracker works... > >Anyway. here is the text revision I propose to >resolve this issue: > >Old text: > The foreign agent's address on the interface from which > the message will be sent. > >New text: > The care-of address offered by the foreign agent for > the mobile node sending the Registration Request. > >I believe it's possible for the foreign agent to offer >a multiplicity of care-of addresses, and I tried to >arrange it so that this text does not preclude that >possibility. > >Regards, >Charlie P. > > > > >ext Sri Gundavelli wrote: > > > > RFC 3344: > > Section 3.7.2.2. Forwarding a Valid Request to the Home Agent > > > > "Specific fields within the IP header and the UDP header of the > > relayed Registration Request MUST be set as follows: > > IP Source Address > > The foreign agent's address on the interface from which > > the message will be sent." > > > > Per the above the text, the foreign agent is required to send the RRQ > > with the source address of the outgoing interface and this essentially > > conflicts with RFC 3519 (NAT Traversal) requirement. Per 3519, the > > foreign agent is required to set the source address of the RRQ to its > > care-of address, so that the home agent does not detect NAT incorrectly. > > The logic of NAT detection at the home agent is by comparing the source > > address of the RRQ to the care-of address in the RRQ's MIP header. So, > > we need to fix the text in 3344. There is no reason why the foreign agent > > MUST set the source address of the RRQ to the IP address of its outgoing > > interface. We should infact enforce the foreign agent to set the source > > address of the RRQ to the FA care of address. > > > > Sri/ > >-- >Mip4 mailing list: Mip4@ietf.org > Web interface: https://www.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html >Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Thu Mar 18 03:06:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25927 for ; Thu, 18 Mar 2004 03:06:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3sXb-0000YK-26 for mip4-archive@odin.ietf.org; Thu, 18 Mar 2004 03:06:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2I86AqE002113 for mip4-archive@odin.ietf.org; Thu, 18 Mar 2004 03:06:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3sXa-0000Y0-1p for mip4-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 03:06:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25921 for ; Thu, 18 Mar 2004 03:06:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3sXW-0002Uk-00 for mip4-web-archive@ietf.org; Thu, 18 Mar 2004 03:06:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3sWW-0002OU-00 for mip4-web-archive@ietf.org; Thu, 18 Mar 2004 03:05:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3sVW-0002E3-00 for mip4-web-archive@ietf.org; Thu, 18 Mar 2004 03:04:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3sVV-0000RK-Lh; Thu, 18 Mar 2004 03:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3rmJ-0002Rr-75 for mip4@optimus.ietf.org; Thu, 18 Mar 2004 02:17:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23168 for ; Thu, 18 Mar 2004 02:17:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3rmF-0003Tc-00 for mip4@ietf.org; Thu, 18 Mar 2004 02:17:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3rla-0003Lh-00 for mip4@ietf.org; Thu, 18 Mar 2004 02:16:35 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B3rk1-00036V-00 for mip4@ietf.org; Thu, 18 Mar 2004 02:14:57 -0500 content-class: urn:content-classes:message Subject: RE: [Mip4] [issue44] RFC 3344 - Source Address of the RRQ & FHAE issues Date: Thu, 18 Mar 2004 02:14:27 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [Mip4] [issue44] RFC 3344 - Source Address of the RRQ & FHAE issues Thread-Index: AcQJY6K5HW4mf35yTeG0GQjSbc5NBADGi30Q From: "O'Neill Alan" To: Content-Transfer-Encoding: quoted-printable Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable WG, The following fix does not seem ideal to me. RFC3344 enables the RREQ from the FA to the HA to use any address valid = at the outgoing interface as the source IP address. This as we know causes = NAT detection problems in NAT Traversal, and as such, in my view is not a = defect in RFC3344, but a defect in NAT Traversal. Keeping RFC3344 text as is presently enables a vendor/operator to use different IP addresses for the signaling control and the data forwarding plane which might be useful in a number of configurations and = operational environments. In addition, removing the general assumption that the = outgoing source IP address is associated with the outgoing interface (a fairly = common IP configuration) and replacing it with a nailed up source address = because of a bug in NAT Traversal, may well cause us future problems. I believe the better (but neither the least effort or quickest) solution = is instead to modify the NAT Traversal work by having an FA, that is NAT Traversal capable and behind a NAT (ie would presently request UDP tunneling), additionally add its RREQ source address into the RREQ as a signed skippable MIP extension. This ensures that the source address = change in the RREQ through the NAT can be explicitly and unambiguously detected = at the HA by source address comparisons, rather than by comparison with the = FA CoA in the RREQ. This is then complaint with present RFC3344. The signed source address does not of course improve NAT Traversal security because = the packet source address can still be modified by a MiTM, but it might be = more generally useful for detecting source address modifications when a NAT Traversal was neither requested nor expected. Restating, MIP architecture requires that any information used for MIP signaling or packet redirection to be a signed entity, and we are now = finding that the packet source address now needs to be considered as such information. Therefore we need to sign it. Locking the packet source = address to the signed FA CoA is a short cut to the same end, but of course = requires that handful of nails. Note also that including this extension that carries the original source address, when forwarding a deregistration of a CoA that is located at a different FA, would then resolve the FHAE issue as it would always = enable the HA to detect the forwarding FA source address and hence determine the required FHAE SA. Thoughts ? Alan. -----Original Message----- From: mip4-admin@ietf.org [mailto:mip4-admin@ietf.org] On Behalf Of Sri Gundavelli Sent: Saturday, March 13, 2004 10:06 AM To: mip4@ietf.org Subject: [Mip4] [issue44] RFC 3344 - Source Address of the RRQ [Issue] This has been entered in the issue tracker as issue 44. owner: Sri Gundavelli : category: Technical draft: draft-ietf-mip4-rfc3344bis priority: Must fix status: No discussion title: RFC 3344 - Source Address of the RRQ [Issue] RFC 3344: Section 3.7.2.2. Forwarding a Valid Request to the Home Agent "Specific fields within the IP header and the UDP header of the relayed Registration Request MUST be set as follows: IP Source Address The foreign agent's address on the interface from which the message will be sent." Per the above the text, the foreign agent is required to send the RRQ with the source address of the outgoing interface and this essentially conflicts with RFC 3519 (NAT Traversal) requirement. Per 3519, the foreign agent is required to set the source address of the RRQ to its care-of address, so that the home agent does not detect NAT incorrectly. The logic of NAT detection at the home agent is by comparing the source address of the RRQ to the care-of address in the RRQ's MIP header. So, we need to fix the text in 3344. There is no reason why the foreign = agent MUST set the source address of the RRQ to the IP address of its outgoing interface. We should infact enforce the foreign agent to set the source address of the RRQ to the FA care of address. _________________________________________________ Mip4 issue tracker _________________________________________________ --=20 Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Thu Mar 18 05:03:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00441 for ; Thu, 18 Mar 2004 05:03:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3uMz-0008O9-N0 for mip4-archive@odin.ietf.org; Thu, 18 Mar 2004 05:03:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IA3LVm032224 for mip4-archive@odin.ietf.org; Thu, 18 Mar 2004 05:03:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3uMx-0008Nf-Kt for mip4-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 05:03:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00430 for ; Thu, 18 Mar 2004 05:03:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3uMu-0001sK-00 for mip4-web-archive@ietf.org; Thu, 18 Mar 2004 05:03:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3uLt-0001kw-00 for mip4-web-archive@ietf.org; Thu, 18 Mar 2004 05:02:14 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B3uKv-0001dE-00 for mip4-web-archive@ietf.org; Thu, 18 Mar 2004 05:01:13 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B3uKw-0006aN-Rf for mip4-web-archive@ietf.org; Thu, 18 Mar 2004 05:01:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3uKl-0008Ah-8H; Thu, 18 Mar 2004 05:01:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3uJx-00088I-L9 for mip4@optimus.ietf.org; Thu, 18 Mar 2004 05:00:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00223 for ; Thu, 18 Mar 2004 05:00:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3uJu-0001Tl-00 for mip4@ietf.org; Thu, 18 Mar 2004 05:00:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3uIw-0001Ji-00 for mip4@ietf.org; Thu, 18 Mar 2004 04:59:11 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B3uI3-00015t-00 for mip4@ietf.org; Thu, 18 Mar 2004 04:58:15 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 18 Mar 2004 02:02:46 +0000 Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.70.65.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2I9viM8009181; Thu, 18 Mar 2004 01:57:44 -0800 (PST) Date: Thu, 18 Mar 2004 01:57:44 -0800 (PST) From: Sri Gundavelli To: "O'Neill Alan" cc: mip4@ietf.org Subject: RE: [Mip4] [issue44] RFC 3344 - Source Address of the RRQ & FHAE issues In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi Alan, On Thu, 18 Mar 2004, O'Neill Alan wrote: > WG, > > The following fix does not seem ideal to me. > > RFC3344 enables the RREQ from the FA to the HA to use any address valid at > the outgoing interface as the source IP address. This as we know causes NAT > detection problems in NAT Traversal, and as such, in my view is not a defect > in RFC3344, but a defect in NAT Traversal. > > Keeping RFC3344 text as is presently enables a vendor/operator to use > different IP addresses for the signaling control and the data forwarding > plane which might be useful in a number of configurations and operational > environments. In addition, removing the general assumption that the outgoing > source IP address is associated with the outgoing interface (a fairly common > IP configuration) and replacing it with a nailed up source address because of > a bug in NAT Traversal, may well cause us future problems. > > I believe the better (but neither the least effort or quickest) solution is > instead to modify the NAT Traversal work by having an FA, that is NAT > Traversal capable and behind a NAT (ie would presently request UDP > tunneling), additionally add its RREQ source address into the RREQ as a > signed skippable MIP extension. This ensures that the source address change > in the RREQ through the NAT can be explicitly and unambiguously detected at > the HA by source address comparisons, rather than by comparison with the FA > CoA in the RREQ. This is then complaint with present RFC3344. The signed > source address does not of course improve NAT Traversal security because the > packet source address can still be modified by a MiTM, but it might be more > generally useful for detecting source address modifications when a NAT > Traversal was neither requested nor expected. > I agree we need a better NAT detection scheme. What you are asking for is essentially an FA Identity extension. HA can use the information from this extension for Security Association lookup and as well for the NAT detection. This should fix both issue 44 and 45. However, if we don't plan to go that path, we can probably remove the MUST clause for setting the RRQ source address to the FA Care-of address and just leave it as a recommended and with potential for detecting NAT incorrectly ? Sri. > Restating, MIP architecture requires that any information used for MIP > signaling or packet redirection to be a signed entity, and we are now finding > that the packet source address now needs to be considered as such > information. Therefore we need to sign it. Locking the packet source address > to the signed FA CoA is a short cut to the same end, but of course requires > that handful of nails. > > Note also that including this extension that carries the original source > address, when forwarding a deregistration of a CoA that is located at a > different FA, would then resolve the FHAE issue as it would always enable the > HA to detect the forwarding FA source address and hence determine the > required FHAE SA. > > Thoughts ? > > Alan. > > -----Original Message----- > From: mip4-admin@ietf.org [mailto:mip4-admin@ietf.org] On Behalf Of Sri > Gundavelli > Sent: Saturday, March 13, 2004 10:06 AM > To: mip4@ietf.org > Subject: [Mip4] [issue44] RFC 3344 - Source Address of the RRQ [Issue] > > > This has been entered in the issue tracker as issue 44. > > owner: Sri Gundavelli : > > category: Technical > draft: draft-ietf-mip4-rfc3344bis > priority: Must fix > status: No discussion > title: RFC 3344 - Source Address of the RRQ [Issue] > > RFC 3344: > Section 3.7.2.2. Forwarding a Valid Request to the Home Agent > > "Specific fields within the IP header and the UDP header of the > relayed Registration Request MUST be set as follows: > IP Source Address > The foreign agent's address on the interface from which > the message will be sent." > > > Per the above the text, the foreign agent is required to send the RRQ > with the source address of the outgoing interface and this essentially > conflicts with RFC 3519 (NAT Traversal) requirement. Per 3519, the > foreign agent is required to set the source address of the RRQ to its > care-of address, so that the home agent does not detect NAT incorrectly. > The logic of NAT detection at the home agent is by comparing the source > address of the RRQ to the care-of address in the RRQ's MIP header. So, > we need to fix the text in 3344. There is no reason why the foreign agent > MUST set the source address of the RRQ to the IP address of its outgoing > interface. We should infact enforce the foreign agent to set the source > address of the RRQ to the FA care of address. > _________________________________________________ > Mip4 issue tracker > > _________________________________________________ > > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ > > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Thu Mar 18 14:35:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02704 for ; Thu, 18 Mar 2004 14:35:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B43I6-0004xQ-1T for mip4-archive@odin.ietf.org; Thu, 18 Mar 2004 14:34:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IJYst5019056 for mip4-archive@odin.ietf.org; Thu, 18 Mar 2004 14:34:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B43I5-0004xH-TJ for mip4-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 14:34:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02679 for ; Thu, 18 Mar 2004 14:34:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B43I3-0005gR-00 for mip4-web-archive@ietf.org; Thu, 18 Mar 2004 14:34:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B43Gz-0005Y2-00 for mip4-web-archive@ietf.org; Thu, 18 Mar 2004 14:33:46 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B43GH-0005RO-00 for mip4-web-archive@ietf.org; Thu, 18 Mar 2004 14:33:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B43GH-0004mC-P2; Thu, 18 Mar 2004 14:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B43G2-0004ke-L8 for mip4@optimus.ietf.org; Thu, 18 Mar 2004 14:32:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02531 for ; Thu, 18 Mar 2004 14:32:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B43G0-0005P1-00 for mip4@ietf.org; Thu, 18 Mar 2004 14:32:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B43En-0005Dh-00 for mip4@ietf.org; Thu, 18 Mar 2004 14:31:29 -0500 Received: from av1-2-sn1.fre.skanova.net ([81.228.11.108]) by ietf-mx with esmtp (Exim 4.12) id 1B43Dq-00057D-00 for mip4@ietf.org; Thu, 18 Mar 2004 14:30:30 -0500 Received: by av1-2-sn1.fre.skanova.net (Postfix, from userid 502) id 82A6F37E88; Thu, 18 Mar 2004 20:29:57 +0100 (CET) Received: from smtp3-2-sn1.fre.skanova.net (smtp3-2-sn1.fre.skanova.net [81.228.11.164]) by av1-2-sn1.fre.skanova.net (Postfix) with ESMTP id 748CE37E48; Thu, 18 Mar 2004 20:29:57 +0100 (CET) Received: from chardonnay.levkowetz.com (h195n1fls311o871.telia.com [213.64.174.195]) by smtp3-2-sn1.fre.skanova.net (Postfix) with ESMTP id C2DA537E44; Thu, 18 Mar 2004 20:29:56 +0100 (CET) Received: from chardonnay ([127.0.0.1]) by chardonnay.levkowetz.com with smtp (Exim 3.36 #1 (Debian)) id 1B3sqE-0005KO-00; Thu, 18 Mar 2004 09:25:26 +0100 Date: Thu, 18 Mar 2004 09:25:23 +0100 From: Henrik Levkowetz To: "O'Neill Alan" Cc: Subject: Re: [Mip4] [issue44] RFC 3344 - Source Address of the RRQ & FHAE issues Message-Id: <20040318092523.4f9f015c.henrik@levkowetz.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Alan, Your argument below is persuasive. It seems to me this would be a fairly clean solution which leaves 3344 as flexible as today, improves NAT traversal and solves the deregistration FHAE problem. Henrik Thursday 18 March 2004, O'Neill Alan wrote: > RFC3344 enables the RREQ from the FA to the HA to use any address valid at > the outgoing interface as the source IP address. This as we know causes NAT > detection problems in NAT Traversal, and as such, in my view is not a defect > in RFC3344, but a defect in NAT Traversal. > > Keeping RFC3344 text as is presently enables a vendor/operator to use > different IP addresses for the signaling control and the data forwarding > plane which might be useful in a number of configurations and operational > environments. In addition, removing the general assumption that the outgoing > source IP address is associated with the outgoing interface (a fairly common > IP configuration) and replacing it with a nailed up source address because of > a bug in NAT Traversal, may well cause us future problems. > > I believe the better (but neither the least effort or quickest) solution is > instead to modify the NAT Traversal work by having an FA, that is NAT > Traversal capable and behind a NAT (ie would presently request UDP > tunneling), additionally add its RREQ source address into the RREQ as a > signed skippable MIP extension. This ensures that the source address change > in the RREQ through the NAT can be explicitly and unambiguously detected at > the HA by source address comparisons, rather than by comparison with the FA > CoA in the RREQ. This is then complaint with present RFC3344. The signed > source address does not of course improve NAT Traversal security because the > packet source address can still be modified by a MiTM, but it might be more > generally useful for detecting source address modifications when a NAT > Traversal was neither requested nor expected. > > Restating, MIP architecture requires that any information used for MIP > signaling or packet redirection to be a signed entity, and we are now finding > that the packet source address now needs to be considered as such > information. Therefore we need to sign it. Locking the packet source address > to the signed FA CoA is a short cut to the same end, but of course requires > that handful of nails. > > Note also that including this extension that carries the original source > address, when forwarding a deregistration of a CoA that is located at a > different FA, would then resolve the FHAE issue as it would always enable the > HA to detect the forwarding FA source address and hence determine the > required FHAE SA. > > Thoughts ? > > Alan. > > -----Original Message----- > From: mip4-admin@ietf.org [mailto:mip4-admin@ietf.org] On Behalf Of Sri > Gundavelli > Sent: Saturday, March 13, 2004 10:06 AM > To: mip4@ietf.org > Subject: [Mip4] [issue44] RFC 3344 - Source Address of the RRQ [Issue] > > > This has been entered in the issue tracker as issue 44. > > owner: Sri Gundavelli : > > category: Technical > draft: draft-ietf-mip4-rfc3344bis > priority: Must fix > status: No discussion > title: RFC 3344 - Source Address of the RRQ [Issue] > > RFC 3344: > Section 3.7.2.2. Forwarding a Valid Request to the Home Agent > > "Specific fields within the IP header and the UDP header of the > relayed Registration Request MUST be set as follows: > IP Source Address > The foreign agent's address on the interface from which > the message will be sent." > > > Per the above the text, the foreign agent is required to send the RRQ > with the source address of the outgoing interface and this essentially > conflicts with RFC 3519 (NAT Traversal) requirement. Per 3519, the > foreign agent is required to set the source address of the RRQ to its > care-of address, so that the home agent does not detect NAT incorrectly. > The logic of NAT detection at the home agent is by comparing the source > address of the RRQ to the care-of address in the RRQ's MIP header. So, > we need to fix the text in 3344. There is no reason why the foreign agent > MUST set the source address of the RRQ to the IP address of its outgoing > interface. We should infact enforce the foreign agent to set the source > address of the RRQ to the FA care of address. > _________________________________________________ > Mip4 issue tracker > > _________________________________________________ > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Thu Mar 18 15:03:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04293 for ; Thu, 18 Mar 2004 15:03:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B43iz-0000nf-Lx for mip4-archive@odin.ietf.org; Thu, 18 Mar 2004 15:02:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IK2few003062 for mip4-archive@odin.ietf.org; Thu, 18 Mar 2004 15:02:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B43iz-0000nB-4W for mip4-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 15:02:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04245 for ; Thu, 18 Mar 2004 15:02:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B43iw-0007XL-00 for mip4-web-archive@ietf.org; Thu, 18 Mar 2004 15:02:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B43i3-0007Tz-00 for mip4-web-archive@ietf.org; Thu, 18 Mar 2004 15:01:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B43hQ-0007Qm-00 for mip4-web-archive@ietf.org; Thu, 18 Mar 2004 15:01:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B43hS-0008A8-Gw; Thu, 18 Mar 2004 15:01:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B43h5-0007uO-Sx for mip4@optimus.ietf.org; Thu, 18 Mar 2004 15:00:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04146 for ; Thu, 18 Mar 2004 15:00:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B43h3-0007PJ-00 for mip4@ietf.org; Thu, 18 Mar 2004 15:00:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B43gB-0007M6-00 for mip4@ietf.org; Thu, 18 Mar 2004 14:59:48 -0500 Received: from [212.182.218.5] (helo=nuoli.com) by ietf-mx with smtp (Exim 4.12) id 1B43fO-0007D3-00 for mip4@ietf.org; Thu, 18 Mar 2004 14:58:59 -0500 Received: (qmail 85964 invoked by uid 89); 18 Mar 2004 19:57:08 -0000 Message-ID: <20040318195708.85963.qmail@nuoli.com> References: <20040318092523.4f9f015c.henrik@levkowetz.com> In-Reply-To: <20040318092523.4f9f015c.henrik@levkowetz.com> From: sami.vaarala@iki.fi To: Henrik Levkowetz Cc: "O'Neill Alan" , mip4@ietf.org Date: Thu, 18 Mar 2004 21:57:08 +0200 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip4] Re: RFC 3344 - Source Address of the RRQ & FHAE issues Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.4 required=5.0 tests=AWL,NEW_DOMAIN_EXTENSIONS, NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, > Hi Alan, > > Your argument below is persuasive. It seems to me this would be a > fairly clean solution which leaves 3344 as flexible as today, improves > NAT traversal and solves the deregistration FHAE problem. I posted a reply earlier but it's probably still in moderation list. Anyway, I agree with Alan's comments as well. However, to me the most future proof solution is to add four fields into RFC 3519 or a new extension: src address, src port, dst address, dst post. These should also go in both directions (MN/FA->HA, HA->MN/FA). As NATs operate on potentially all of these fields, it makes sense to provide the originals for MIP nodes (I know this may violate against UNSAF considerations more than RFC 3519 does, though.) The immediate use would be to cover the FA CoA issue under discussion, but having an "original src port" field would also cover the (admittedly corner) case where only the source port gets NATted. This info could also be used to help with port forwarding (where destination address and/or port is translated; dest address only is not enough if only the port gets translated). Netseal implemented this as a separate extension which goes alongside the RFC 3519 extension. But it could just as well be a part of the RFC 3519 extension(s). Are there plans to revise RFC 3519 in the near future? Best, -Sami > > Henrik > > Thursday 18 March 2004, O'Neill Alan wrote: >> RFC3344 enables the RREQ from the FA to the HA to use any address valid at >> the outgoing interface as the source IP address. This as we know causes NAT >> detection problems in NAT Traversal, and as such, in my view is not a defect >> in RFC3344, but a defect in NAT Traversal. >> >> Keeping RFC3344 text as is presently enables a vendor/operator to use >> different IP addresses for the signaling control and the data forwarding >> plane which might be useful in a number of configurations and operational >> environments. In addition, removing the general assumption that the outgoing >> source IP address is associated with the outgoing interface (a fairly common >> IP configuration) and replacing it with a nailed up source address because of >> a bug in NAT Traversal, may well cause us future problems. >> >> I believe the better (but neither the least effort or quickest) solution is >> instead to modify the NAT Traversal work by having an FA, that is NAT >> Traversal capable and behind a NAT (ie would presently request UDP >> tunneling), additionally add its RREQ source address into the RREQ as a >> signed skippable MIP extension. This ensures that the source address change >> in the RREQ through the NAT can be explicitly and unambiguously detected at >> the HA by source address comparisons, rather than by comparison with the FA >> CoA in the RREQ. This is then complaint with present RFC3344. The signed >> source address does not of course improve NAT Traversal security because the >> packet source address can still be modified by a MiTM, but it might be more >> generally useful for detecting source address modifications when a NAT >> Traversal was neither requested nor expected. >> >> Restating, MIP architecture requires that any information used for MIP >> signaling or packet redirection to be a signed entity, and we are now finding >> that the packet source address now needs to be considered as such >> information. Therefore we need to sign it. Locking the packet source address >> to the signed FA CoA is a short cut to the same end, but of course requires >> that handful of nails. >> >> Note also that including this extension that carries the original source >> address, when forwarding a deregistration of a CoA that is located at a >> different FA, would then resolve the FHAE issue as it would always enable the >> HA to detect the forwarding FA source address and hence determine the >> required FHAE SA. >> >> Thoughts ? >> >> Alan. >> >> -----Original Message----- >> From: mip4-admin@ietf.org [mailto:mip4-admin@ietf.org] On Behalf Of Sri >> Gundavelli >> Sent: Saturday, March 13, 2004 10:06 AM >> To: mip4@ietf.org >> Subject: [Mip4] [issue44] RFC 3344 - Source Address of the RRQ [Issue] >> >> >> This has been entered in the issue tracker as issue 44. >> >> owner: Sri Gundavelli : >> >> category: Technical >> draft: draft-ietf-mip4-rfc3344bis >> priority: Must fix >> status: No discussion >> title: RFC 3344 - Source Address of the RRQ [Issue] >> >> RFC 3344: >> Section 3.7.2.2. Forwarding a Valid Request to the Home Agent >> >> "Specific fields within the IP header and the UDP header of the >> relayed Registration Request MUST be set as follows: >> IP Source Address >> The foreign agent's address on the interface from which >> the message will be sent." >> >> >> Per the above the text, the foreign agent is required to send the RRQ >> with the source address of the outgoing interface and this essentially >> conflicts with RFC 3519 (NAT Traversal) requirement. Per 3519, the >> foreign agent is required to set the source address of the RRQ to its >> care-of address, so that the home agent does not detect NAT incorrectly. >> The logic of NAT detection at the home agent is by comparing the source >> address of the RRQ to the care-of address in the RRQ's MIP header. So, >> we need to fix the text in 3344. There is no reason why the foreign agent >> MUST set the source address of the RRQ to the IP address of its outgoing >> interface. We should infact enforce the foreign agent to set the source >> address of the RRQ to the FA care of address. >> _________________________________________________ >> Mip4 issue tracker >> >> _________________________________________________ >> > > > > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ -- Sami Vaarala http://www.hut.fi/~svaarala -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Thu Mar 18 15:07:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04805 for ; Thu, 18 Mar 2004 15:07:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B43mo-0003I5-LW for mip4-archive@odin.ietf.org; Thu, 18 Mar 2004 15:06:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IK6cZV012643 for mip4-archive@odin.ietf.org; Thu, 18 Mar 2004 15:06:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B43mo-0003Hq-Gw for mip4-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 15:06:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04758 for ; Thu, 18 Mar 2004 15:06:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B43ml-0007my-00 for mip4-web-archive@ietf.org; Thu, 18 Mar 2004 15:06:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B43lz-0007l2-00 for mip4-web-archive@ietf.org; Thu, 18 Mar 2004 15:05:48 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B43lE-0007hj-00 for mip4-web-archive@ietf.org; Thu, 18 Mar 2004 15:05:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B43lF-0002aX-P8; Thu, 18 Mar 2004 15:05:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3syq-0002P6-Qh for mip4@optimus.ietf.org; Thu, 18 Mar 2004 03:34:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27061 for ; Thu, 18 Mar 2004 03:34:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3syo-0006D4-00 for mip4@ietf.org; Thu, 18 Mar 2004 03:34:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3sxu-00064y-00 for mip4@ietf.org; Thu, 18 Mar 2004 03:33:22 -0500 Received: from smtp2.finnetcom.net ([213.140.160.69]) by ietf-mx with esmtp (Exim 4.12) id 1B3sxG-0005xA-00 for mip4@ietf.org; Thu, 18 Mar 2004 03:32:42 -0500 Received: from populo.vip.fi (populo.vip.fi [213.173.130.25]) by smtp2.finnetcom.net (8.12.8/8.12.8) with ESMTP id i2I8WMgG018071; Thu, 18 Mar 2004 10:32:25 +0200 Received: from server.netseal.com (kone1.intrasec2.vip.fi [213.173.159.46]) by populo.vip.fi (8.8.8p2/8.8.5) with ESMTP id KAA25799; Thu, 18 Mar 2004 10:32:19 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] [issue44] RFC 3344 - Source Address of the RRQ & FHAE issues X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Thu, 18 Mar 2004 10:32:19 +0200 Message-ID: Thread-Topic: [Mip4] [issue44] RFC 3344 - Source Address of the RRQ & FHAE issues Thread-Index: AcQJY6K5HW4mf35yTeG0GQjSbc5NBADGi30QABomD1A= From: "Sami Vaarala" To: "O'Neill Alan" , Content-Transfer-Encoding: quoted-printable Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Alan, > RFC3344 enables the RREQ from the FA to the HA to use any address valid at > the outgoing interface as the source IP address. This as we know causes > NAT detection problems in NAT Traversal, and as such, in my view is not a > defect in RFC3344, but a defect in NAT Traversal. I agree. We actually had some discussion about this during RFC 3519 work, but it was last minute and there was no concrete need for a change at that time. > I believe the better (but neither the least effort or quickest) solution > is instead to modify the NAT Traversal work by having an FA, that is NAT > Traversal capable and behind a NAT (ie would presently request UDP > tunneling), additionally add its RREQ source address into the RREQ as a > signed skippable MIP extension. This ensures that the source address > [...] I've been thinking along the same lines. But I'd like to take this proposal a bit further: I'd like to include both source and destination address *and* port of the original UDP packet. This information should flow in both directions, MN->HA and HA->MN (and FAs of course). This is the cleanest approach, in my opinion, because NATs may operate on any of these fields. To be future proof, we should have all the information available for detection and compensation. (I realize this is in conflict with UNSAF considerations though.) As for the current uses, we need some extra stuff to: - to handle the FA case being discussed (allow src address !=3D CoA) - to detect destination address NAT (port forwarding) robustly (it can be done in other ways too, though.) - to cover the admittedly improbable corner case where only the MN source port (and not the source address) is NATted Best regards, -Sami -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Thu Mar 18 15:22:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06350 for ; Thu, 18 Mar 2004 15:22:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B441N-0001FO-C6 for mip4-archive@odin.ietf.org; Thu, 18 Mar 2004 15:21:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IKLfZ8004793 for mip4-archive@odin.ietf.org; Thu, 18 Mar 2004 15:21:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B441N-0001FE-43 for mip4-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 15:21:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06305 for ; Thu, 18 Mar 2004 15:21:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B441L-0000n2-00 for mip4-web-archive@ietf.org; Thu, 18 Mar 2004 15:21:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B440Y-0000kU-00 for mip4-web-archive@ietf.org; Thu, 18 Mar 2004 15:20:50 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B43zk-0000h8-00 for mip4-web-archive@ietf.org; Thu, 18 Mar 2004 15:20:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B43zl-0000RQ-4x; Thu, 18 Mar 2004 15:20:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B43zS-0000Kc-Kf for mip4@optimus.ietf.org; Thu, 18 Mar 2004 15:19:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06108 for ; Thu, 18 Mar 2004 15:19:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B43zR-0000eI-00 for mip4@ietf.org; Thu, 18 Mar 2004 15:19:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B43yX-0000c2-00 for mip4@ietf.org; Thu, 18 Mar 2004 15:18:46 -0500 Received: from av7-2-sn4.m-sp.skanova.net ([81.228.10.109]) by ietf-mx with esmtp (Exim 4.12) id 1B43xv-0000Ww-00 for mip4@ietf.org; Thu, 18 Mar 2004 15:18:07 -0500 Received: by av7-2-sn4.m-sp.skanova.net (Postfix, from userid 502) id E910F37E9C; Thu, 18 Mar 2004 21:17:34 +0100 (CET) Received: from smtp2-1-sn4.m-sp.skanova.net (smtp2-1-sn4.m-sp.skanova.net [81.228.10.183]) by av7-2-sn4.m-sp.skanova.net (Postfix) with ESMTP id D9A7A37E45; Thu, 18 Mar 2004 21:17:34 +0100 (CET) Received: from chardonnay.levkowetz.com (h195n1fls311o871.telia.com [213.64.174.195]) by smtp2-1-sn4.m-sp.skanova.net (Postfix) with ESMTP id 2B58B37E80; Thu, 18 Mar 2004 21:17:34 +0100 (CET) Received: from chardonnay ([127.0.0.1]) by chardonnay.levkowetz.com with smtp (Exim 3.36 #1 (Debian)) id 1B43xN-0005Vl-00; Thu, 18 Mar 2004 21:17:33 +0100 Date: Thu, 18 Mar 2004 21:17:32 +0100 From: Henrik Levkowetz To: sami.vaarala@iki.fi Cc: "O'Neill Alan" , mip4@ietf.org Subject: Re: [Mip4] Re: RFC 3344 - Source Address of the RRQ & FHAE issues Message-Id: <20040318211732.5c1c097f.henrik@levkowetz.com> In-Reply-To: <20040318195708.85963.qmail@nuoli.com> References: <20040318092523.4f9f015c.henrik@levkowetz.com> <20040318195708.85963.qmail@nuoli.com> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Sami, Thursday 18 March 2004, sami.vaarala@iki.fi wrote: > > > Hi Alan, > > > > Your argument below is persuasive. It seems to me this would be a > > fairly clean solution which leaves 3344 as flexible as today, improves > > NAT traversal and solves the deregistration FHAE problem. > > I posted a reply earlier but it's probably still in moderation list. > Anyway, I agree with Alan's comments as well. Yes. A lot of mail hasn't made it to me at work today, so I'm picking up a lot of stuff here at home. Sorry for the delay ... :-) > However, to me the most future proof solution is to add four fields > into RFC 3519 or a new extension: src address, src port, dst address, > dst post. These should also go in both directions (MN/FA->HA, HA->MN/FA). > As NATs operate on potentially all of these fields, it makes sense to > provide the originals for MIP nodes (I know this may violate against > UNSAF considerations more than RFC 3519 does, though.) Mm, yes, but we seem to be needing it. I like it. > The immediate use would be to cover the FA CoA issue under discussion, > but having an "original src port" field would also cover the (admittedly > corner) case where only the source port gets NATted. This info could also > be used to help with port forwarding (where destination address and/or port > is translated; dest address only is not enough if only the port gets > translated). Clearly not. > Netseal implemented this as a separate extension which goes alongside > the RFC 3519 extension. But it could just as well be a part of the > RFC 3519 extension(s). Are there plans to revise RFC 3519 in the near > future? No such plans at this time. I don't know what's better - to write a short draft defining new subtypes to the NAT traversal extensions 44 / 144, to revise 3519, or to define a new extension for this in 3344bis... I guess I'd think first in terms of a short separate document. Henrik -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Thu Mar 18 19:09:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18456 for ; Thu, 18 Mar 2004 19:09:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B47Z8-0008Dv-1W for mip4-archive@odin.ietf.org; Thu, 18 Mar 2004 19:08:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2J08kNH031607 for mip4-archive@odin.ietf.org; Thu, 18 Mar 2004 19:08:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B47Z7-0008Di-RN for mip4-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 19:08:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18447 for ; Thu, 18 Mar 2004 19:08:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B47Z4-0001t7-00 for mip4-web-archive@ietf.org; Thu, 18 Mar 2004 19:08:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B47YL-0001qF-00 for mip4-web-archive@ietf.org; Thu, 18 Mar 2004 19:07:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B47XS-0001mD-00 for mip4-web-archive@ietf.org; Thu, 18 Mar 2004 19:07:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B47XR-0007ob-G2; Thu, 18 Mar 2004 19:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B47XC-0007Zw-Qv for mip4@optimus.ietf.org; Thu, 18 Mar 2004 19:06:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18326 for ; Thu, 18 Mar 2004 19:06:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B47X9-0001jF-00 for mip4@ietf.org; Thu, 18 Mar 2004 19:06:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B47WA-0001ej-00 for mip4@ietf.org; Thu, 18 Mar 2004 19:05:43 -0500 Received: from av3-2-sn3.vrr.skanova.net ([81.228.9.110]) by ietf-mx with esmtp (Exim 4.12) id 1B47VI-0001XT-00 for mip4@ietf.org; Thu, 18 Mar 2004 19:04:48 -0500 Received: by av3-2-sn3.vrr.skanova.net (Postfix, from userid 502) id DB08337E92; Fri, 19 Mar 2004 01:04:06 +0100 (CET) Received: from smtp1-1-sn3.vrr.skanova.net (smtp1-1-sn3.vrr.skanova.net [81.228.9.177]) by av3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id CB11B37E4A for ; Fri, 19 Mar 2004 01:04:06 +0100 (CET) Received: from chardonnay.levkowetz.com (h195n1fls311o871.telia.com [213.64.174.195]) by smtp1-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 82E9E38006 for ; Fri, 19 Mar 2004 01:04:06 +0100 (CET) Received: from chardonnay ([127.0.0.1]) by chardonnay.levkowetz.com with smtp (Exim 3.36 #1 (Debian)) id 1B47Uc-0005lG-00 for ; Fri, 19 Mar 2004 01:04:06 +0100 Date: Fri, 19 Mar 2004 01:04:05 +0100 From: Henrik Levkowetz To: mip4@ietf.org Subject: Re: [Mip4] Re: [issue44] RFC 3344 - Source Address of the RRQ & FHAE issues Message-Id: <20040319010405.4b77cbcc.henrik@levkowetz.com> In-Reply-To: <20040318195708.85963.qmail@nuoli.com> References: <20040318092523.4f9f015c.henrik@levkowetz.com> <20040318195708.85963.qmail@nuoli.com> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Signature=_Fri__19_Mar_2004_01_04_05_+0100_9Cdmww_b9ZbzYQn9" Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 --Signature=_Fri__19_Mar_2004_01_04_05_+0100_9Cdmww_b9ZbzYQn9 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit || (reposting this with [issue44] in the subject line so it'll be picked || up by the issue tracker - Sami, you managed to get rid of the issue || number somehow! ,,:-) || || Our issue tracker (at http://mip4.org/issues/tracker/mip4/) is pretty || good at picking up the discussions on the list and archiving them by || issue - if there's an issue number in the subject. For now, the first || entry of an issue has to be made at the tracker web site, but I'm || looking at doing something about that too, so new issues posted to || the list with appropriate keywords will also be picked up correctly. || || Henrik Thursday 18 March 2004, sami.vaarala@iki.fi wrote: > > > Hi Alan, > > > > Your argument below is persuasive. It seems to me this would be a > > fairly clean solution which leaves 3344 as flexible as today, improves > > NAT traversal and solves the deregistration FHAE problem. > > I posted a reply earlier but it's probably still in moderation list. > Anyway, I agree with Alan's comments as well. Yes. A lot of mail hasn't made it to me at work today, so I'm picking up a lot of stuff here at home. Sorry for the delay ... :-) > However, to me the most future proof solution is to add four fields > into RFC 3519 or a new extension: src address, src port, dst address, > dst post. These should also go in both directions (MN/FA->HA, HA->MN/FA). > As NATs operate on potentially all of these fields, it makes sense to > provide the originals for MIP nodes (I know this may violate against > UNSAF considerations more than RFC 3519 does, though.) Mm, yes, but we seem to be needing it. I like it. > The immediate use would be to cover the FA CoA issue under discussion, > but having an "original src port" field would also cover the (admittedly > corner) case where only the source port gets NATted. This info could also > be used to help with port forwarding (where destination address and/or port > is translated; dest address only is not enough if only the port gets > translated). Clearly not. > Netseal implemented this as a separate extension which goes alongside > the RFC 3519 extension. But it could just as well be a part of the > RFC 3519 extension(s). Are there plans to revise RFC 3519 in the near > future? No such plans at this time. I don't know what's better - to write a short draft defining new subtypes to the NAT traversal extensions 44 / 144, to revise 3519, or to define a new extension for this in 3344bis... I guess I'd think first in terms of a short separate document. Henrik --Signature=_Fri__19_Mar_2004_01_04_05_+0100_9Cdmww_b9ZbzYQn9 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAWjj1eVhrtTJkXCMRAgKnAKCYIa7q0RFaBnjMG15HA3oPaiGe+gCcCgSg r/7NuMrOPC1ijzePB8PL9oU= =afam -----END PGP SIGNATURE----- --Signature=_Fri__19_Mar_2004_01_04_05_+0100_9Cdmww_b9ZbzYQn9-- -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Thu Mar 18 19:47:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20037 for ; Thu, 18 Mar 2004 19:47:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B489r-0001xz-EB for mip4-archive@odin.ietf.org; Thu, 18 Mar 2004 19:46:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2J0khkC007556 for mip4-archive@odin.ietf.org; Thu, 18 Mar 2004 19:46:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B489r-0001xn-4K for mip4-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 19:46:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19889 for ; Thu, 18 Mar 2004 19:46:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B489p-0004Su-00 for mip4-web-archive@ietf.org; Thu, 18 Mar 2004 19:46:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B488S-0004DX-00 for mip4-web-archive@ietf.org; Thu, 18 Mar 2004 19:45:17 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B487G-00045E-00 for mip4-web-archive@ietf.org; Thu, 18 Mar 2004 19:44:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B481U-0005vg-OF for mip4-web-archive@ietf.org; Thu, 18 Mar 2004 19:38:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B481R-0001Xl-Rl; Thu, 18 Mar 2004 19:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4818-0001SU-15 for mip4@optimus.ietf.org; Thu, 18 Mar 2004 19:37:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19597 for ; Thu, 18 Mar 2004 19:37:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4816-0003o7-00 for mip4@ietf.org; Thu, 18 Mar 2004 19:37:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B480A-0003mM-00 for mip4@ietf.org; Thu, 18 Mar 2004 19:36:43 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B47zg-0003kK-00 for mip4@ietf.org; Thu, 18 Mar 2004 19:36:12 -0500 content-class: urn:content-classes:message Subject: RE: [Mip4] Re: RFC 3344 - Source Address of the RRQ & FHAE issues Date: Thu, 18 Mar 2004 19:35:40 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [Mip4] Re: RFC 3344 - Source Address of the RRQ & FHAE issues Thread-Index: AcQNJg4sd4716peiQc6MAA541VaDKgAILRUA From: "O'Neill Alan" To: "Henrik Levkowetz" , Cc: Content-Transfer-Encoding: quoted-printable Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.2 required=5.0 tests=AWL,NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Henrik / Sami, Why don't we define the source address extension in RFC3344biz because = FHAE needs it in the discussed corner case, and state that it may be added = into the RREQ when the source address is not equal to the FA CoA, quoting the = FHAE example. You might also want to define a destination address extension = as well for completeness. A short additional doc that can later wrap into NAT Trav can then build = on this and define the additional extensions for src and dest ports (and = dest IP if not included in RFC3344biz). Alan. -----Original Message----- From: Henrik Levkowetz [mailto:henrik@levkowetz.com]=20 Sent: Friday, March 19, 2004 6:48 AM To: sami.vaarala@iki.fi Cc: O'Neill Alan; mip4@ietf.org Subject: Re: [Mip4] Re: RFC 3344 - Source Address of the RRQ & FHAE = issues Hi Sami, Thursday 18 March 2004, sami.vaarala@iki.fi wrote: >=20 > > Hi Alan,=20 > >=20 > > Your argument below is persuasive. It seems to me this would be = a > > fairly clean solution which leaves 3344 as flexible as today, = improves > > NAT traversal and solves the deregistration FHAE problem. >=20 > I posted a reply earlier but it's probably still in moderation list. > Anyway, I agree with Alan's comments as well.=20 Yes. A lot of mail hasn't made it to me at work today, so I'm picking up a lot of stuff here at home. Sorry for the delay ... :-) > However, to me the most future proof solution is to add four fields > into RFC 3519 or a new extension: src address, src port, dst address, > dst post. These should also go in both directions (MN/FA->HA, = HA->MN/FA). > As NATs operate on potentially all of these fields, it makes sense to > provide the originals for MIP nodes (I know this may violate against > UNSAF considerations more than RFC 3519 does, though.)=20 Mm, yes, but we seem to be needing it. I like it. > The immediate use would be to cover the FA CoA issue under discussion, > but having an "original src port" field would also cover the = (admittedly > corner) case where only the source port gets NATted. This info could = also > be used to help with port forwarding (where destination address and/or = port > is translated; dest address only is not enough if only the port gets > translated).=20 Clearly not. > Netseal implemented this as a separate extension which goes alongside > the RFC 3519 extension. But it could just as well be a part of the > RFC 3519 extension(s). Are there plans to revise RFC 3519 in the near > future?=20 No such plans at this time. I don't know what's better - to write a = short draft defining new subtypes to the NAT traversal extensions 44 / 144, to revise 3519, or to define a new extension for this in 3344bis... I guess I'd think first in terms of a short separate document. Henrik -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Thu Mar 18 23:59:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00527 for ; Thu, 18 Mar 2004 23:59:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4C5s-0000LT-8c for mip4-archive@odin.ietf.org; Thu, 18 Mar 2004 23:58:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2J4wqTu001321 for mip4-archive@odin.ietf.org; Thu, 18 Mar 2004 23:58:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4C5s-0000LE-3U for mip4-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 23:58:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00498 for ; Thu, 18 Mar 2004 23:58:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4C5p-00076c-00 for mip4-web-archive@ietf.org; Thu, 18 Mar 2004 23:58:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4C4r-00072e-00 for mip4-web-archive@ietf.org; Thu, 18 Mar 2004 23:57:50 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4C44-0006zg-00 for mip4-web-archive@ietf.org; Thu, 18 Mar 2004 23:57:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4C45-0000G2-2C; Thu, 18 Mar 2004 23:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4C3v-0000FN-HF for mip4@optimus.ietf.org; Thu, 18 Mar 2004 23:56:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00392 for ; Thu, 18 Mar 2004 23:56:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4C3t-0006y2-00 for mip4@ietf.org; Thu, 18 Mar 2004 23:56:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4C2v-0006rf-00 for mip4@ietf.org; Thu, 18 Mar 2004 23:55:50 -0500 Received: from av5-1-sn3.vrr.skanova.net ([81.228.9.113]) by ietf-mx with esmtp (Exim 4.12) id 1B4C1z-0006iJ-00 for mip4@ietf.org; Thu, 18 Mar 2004 23:54:51 -0500 Received: by av5-1-sn3.vrr.skanova.net (Postfix, from userid 502) id AA32C37E54; Fri, 19 Mar 2004 05:54:21 +0100 (CET) Received: from smtp1-1-sn3.vrr.skanova.net (smtp1-1-sn3.vrr.skanova.net [81.228.9.177]) by av5-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 869D137E50; Fri, 19 Mar 2004 05:54:21 +0100 (CET) Received: from chardonnay.levkowetz.com (h195n1fls311o871.telia.com [213.64.174.195]) by smtp1-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 76C643800B; Fri, 19 Mar 2004 05:54:21 +0100 (CET) Received: from chardonnay ([127.0.0.1]) by chardonnay.levkowetz.com with smtp (Exim 3.36 #1 (Debian)) id 1B4C1U-0000Mw-00; Fri, 19 Mar 2004 05:54:20 +0100 Date: Fri, 19 Mar 2004 05:54:20 +0100 From: Henrik Levkowetz To: "O'Neill Alan" Cc: , Subject: Re: [Mip4] Re: RFC 3344 - Source Address of the RRQ & FHAE issues Message-Id: <20040319055420.298c5f19.henrik@levkowetz.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Alan, Thursday 18 March 2004, O'Neill Alan wrote: > Why don't we define the source address extension in RFC3344biz because FHAE > needs it in the discussed corner case, and state that it may be added into > the RREQ when the source address is not equal to the FA CoA, quoting the FHAE > example. You might also want to define a destination address extension as > well for completeness. The main reason I was thinking to not do this in rfc3344bis is that the purpose of the revision is to take it to Draft Standard, and we definitely can forget about that with this addition. > A short additional doc that can later wrap into NAT Trav can then build on > this and define the additional extensions for src and dest ports (and dest IP > if not included in RFC3344biz). Yes. But don't you think the whole thing can be written up standalone as an addition to NAT traversal - after all it's with NAT traversal it becomes interesting. As long as you don't add any NAT traversal extension, 3344bis is fine as is without this, no? Henrik -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Fri Mar 19 00:57:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02778 for ; Fri, 19 Mar 2004 00:57:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4D01-00045G-Tf for mip4-archive@odin.ietf.org; Fri, 19 Mar 2004 00:57:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2J5urmc015698 for mip4-archive@odin.ietf.org; Fri, 19 Mar 2004 00:56:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4D01-000457-JL for mip4-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 00:56:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02772 for ; Fri, 19 Mar 2004 00:56:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4Czy-0003Vo-00 for mip4-web-archive@ietf.org; Fri, 19 Mar 2004 00:56:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4Cz2-0003Si-00 for mip4-web-archive@ietf.org; Fri, 19 Mar 2004 00:55:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4CyD-0003QD-00 for mip4-web-archive@ietf.org; Fri, 19 Mar 2004 00:55:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4CyF-0003il-H7; Fri, 19 Mar 2004 00:55:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Cy2-0003ho-Gu for mip4@optimus.ietf.org; Fri, 19 Mar 2004 00:54:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02687 for ; Fri, 19 Mar 2004 00:54:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4Cxz-0003OJ-00 for mip4@ietf.org; Fri, 19 Mar 2004 00:54:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4Cx3-0003Ku-00 for mip4@ietf.org; Fri, 19 Mar 2004 00:53:50 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B4CwD-0003F9-00 for mip4@ietf.org; Fri, 19 Mar 2004 00:52:57 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 18 Mar 2004 21:56:29 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2J5qQRO000224; Thu, 18 Mar 2004 21:52:26 -0800 (PST) Received: from kleung-w2k01.cisco.com (sjc-vpn1-353.cisco.com [10.21.97.97]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ARH66767; Thu, 18 Mar 2004 21:52:25 -0800 (PST) Message-Id: <4.3.2.7.2.20040318212945.026b4818@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 18 Mar 2004 21:52:25 -0800 To: "O'Neill Alan" From: Kent Leung Subject: RE: [Mip4] [issue44] RFC 3344 - Source Address of the RRQ & FHAE issues Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.4 required=5.0 tests=AWL,NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 Hi Alan. What is meant by "signed"? Implying FHAE protected or some FA signature in the extension? A bit more clarification would help. Let's say there is no pre-existing SA between FA and HA. How is the extension protected? It's a good idea. But I assumed that this was not used because the FA cannot add extensions without FHAE to protect the message? So as long as we have a method to protect this new extension, I'm fine with it since it meets our requirement for an FA identifier for the FHAE authentication. Though using FA NAI has the advantage of minimizing SA entries on HA. There would be one SA for FA, regardless how many CoA or source IP addresses used in the registration request. I'm sure not everyone will agree that it's a good thing. :) Kent At 02:14 AM 3/18/2004 -0500, O'Neill Alan wrote: >WG, > >The following fix does not seem ideal to me. > >RFC3344 enables the RREQ from the FA to the HA to use any address valid at >the outgoing interface as the source IP address. This as we know causes NAT >detection problems in NAT Traversal, and as such, in my view is not a defect >in RFC3344, but a defect in NAT Traversal. > >Keeping RFC3344 text as is presently enables a vendor/operator to use >different IP addresses for the signaling control and the data forwarding >plane which might be useful in a number of configurations and operational >environments. In addition, removing the general assumption that the outgoing >source IP address is associated with the outgoing interface (a fairly common >IP configuration) and replacing it with a nailed up source address because of >a bug in NAT Traversal, may well cause us future problems. > >I believe the better (but neither the least effort or quickest) solution is >instead to modify the NAT Traversal work by having an FA, that is NAT >Traversal capable and behind a NAT (ie would presently request UDP >tunneling), additionally add its RREQ source address into the RREQ as a >signed skippable MIP extension. This ensures that the source address change >in the RREQ through the NAT can be explicitly and unambiguously detected at >the HA by source address comparisons, rather than by comparison with the FA >CoA in the RREQ. This is then complaint with present RFC3344. The signed >source address does not of course improve NAT Traversal security because the >packet source address can still be modified by a MiTM, but it might be more >generally useful for detecting source address modifications when a NAT >Traversal was neither requested nor expected. > >Restating, MIP architecture requires that any information used for MIP >signaling or packet redirection to be a signed entity, and we are now finding >that the packet source address now needs to be considered as such >information. Therefore we need to sign it. Locking the packet source address >to the signed FA CoA is a short cut to the same end, but of course requires >that handful of nails. > >Note also that including this extension that carries the original source >address, when forwarding a deregistration of a CoA that is located at a >different FA, would then resolve the FHAE issue as it would always enable the >HA to detect the forwarding FA source address and hence determine the >required FHAE SA. > >Thoughts ? > >Alan. > >-----Original Message----- >From: mip4-admin@ietf.org [mailto:mip4-admin@ietf.org] On Behalf Of Sri >Gundavelli >Sent: Saturday, March 13, 2004 10:06 AM >To: mip4@ietf.org >Subject: [Mip4] [issue44] RFC 3344 - Source Address of the RRQ [Issue] > > >This has been entered in the issue tracker as issue 44. > >owner: Sri Gundavelli : > >category: Technical >draft: draft-ietf-mip4-rfc3344bis >priority: Must fix >status: No discussion >title: RFC 3344 - Source Address of the RRQ [Issue] > >RFC 3344: >Section 3.7.2.2. Forwarding a Valid Request to the Home Agent > >"Specific fields within the IP header and the UDP header of the > relayed Registration Request MUST be set as follows: > IP Source Address > The foreign agent's address on the interface from which > the message will be sent." > > >Per the above the text, the foreign agent is required to send the RRQ >with the source address of the outgoing interface and this essentially >conflicts with RFC 3519 (NAT Traversal) requirement. Per 3519, the >foreign agent is required to set the source address of the RRQ to its >care-of address, so that the home agent does not detect NAT incorrectly. >The logic of NAT detection at the home agent is by comparing the source >address of the RRQ to the care-of address in the RRQ's MIP header. So, >we need to fix the text in 3344. There is no reason why the foreign agent >MUST set the source address of the RRQ to the IP address of its outgoing >interface. We should infact enforce the foreign agent to set the source >address of the RRQ to the FA care of address. >_________________________________________________ >Mip4 issue tracker > >_________________________________________________ > >-- >Mip4 mailing list: Mip4@ietf.org > Web interface: https://www.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html >Supplemental site: http://www.mip4.org/ > >-- >Mip4 mailing list: Mip4@ietf.org > Web interface: https://www.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html >Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Fri Mar 19 01:29:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03751 for ; Fri, 19 Mar 2004 01:29:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4DV6-0005uy-VZ for mip4-archive@odin.ietf.org; Fri, 19 Mar 2004 01:29:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2J6T0oG022747 for mip4-archive@odin.ietf.org; Fri, 19 Mar 2004 01:29:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4DV6-0005ug-BR for mip4-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 01:29:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03731 for ; Fri, 19 Mar 2004 01:28:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4DV3-0005TG-00 for mip4-web-archive@ietf.org; Fri, 19 Mar 2004 01:28:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4DU4-0005PO-00 for mip4-web-archive@ietf.org; Fri, 19 Mar 2004 01:27:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4DTB-0005MJ-00 for mip4-web-archive@ietf.org; Fri, 19 Mar 2004 01:27:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4DTB-0005oV-Hg; Fri, 19 Mar 2004 01:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4DT6-0005o2-PO for mip4@optimus.ietf.org; Fri, 19 Mar 2004 01:26:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03679 for ; Fri, 19 Mar 2004 01:26:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4DT3-0005LE-00 for mip4@ietf.org; Fri, 19 Mar 2004 01:26:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4DS4-0005I2-00 for mip4@ietf.org; Fri, 19 Mar 2004 01:25:52 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B4DRV-0005CS-00 for mip4@ietf.org; Fri, 19 Mar 2004 01:25:17 -0500 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i2J6OjK2008081; Thu, 18 Mar 2004 22:24:46 -0800 (PST) Received: from kleung-w2k01.cisco.com (sjc-vpn1-353.cisco.com [10.21.97.97]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ARH68936; Thu, 18 Mar 2004 22:24:44 -0800 (PST) Message-Id: <4.3.2.7.2.20040318220522.02845948@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 18 Mar 2004 22:24:42 -0800 To: "Sami Vaarala" From: Kent Leung Subject: RE: [Mip4] [issue44] RFC 3344 - Source Address of the RRQ & FHAE issues Cc: "O'Neill Alan" , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL autolearn=no version=2.60 Hi Sami. I wonder if we really should bother with port numbers for "improbable corner case"? Has anyone ever run into the case of port address translation only without private/public IP address translation? I'm open to this only if it's for real to avoid cluttering protocol, product documentation, training, etc. :) As for identifying the destination IP address, are we talking about the case of a NAT box in front of the HA? And that NAT box translates the public IP address of HA (HApub) to private address (HApriv) for RRQ from FA/MN? It's a good idea to have both IP addresses from MN/FA and HA. The NAT Traversal detection and tunnel setup would work bidirectional. Only issue is protecting extension in FA - HA messages? MN CCOA mode would work fine. Kent At 10:32 AM 3/18/2004 +0200, Sami Vaarala wrote: >Alan, > > > RFC3344 enables the RREQ from the FA to the HA to use any address >valid at > > the outgoing interface as the source IP address. This as we know >causes > > NAT detection problems in NAT Traversal, and as such, in my view is >not a > > defect in RFC3344, but a defect in NAT Traversal. > >I agree. We actually had some discussion about this during RFC 3519 >work, but it was last minute and there was no concrete need for a change >at that time. > > > I believe the better (but neither the least effort or quickest) >solution > > is instead to modify the NAT Traversal work by having an FA, that is >NAT > > Traversal capable and behind a NAT (ie would presently request UDP > > tunneling), additionally add its RREQ source address into the RREQ as >a > > signed skippable MIP extension. This ensures that the source address > > [...] > >I've been thinking along the same lines. But I'd like to take this >proposal a bit further: I'd like to include both source and destination >address *and* port of the original UDP packet. This information should >flow in both directions, MN->HA and HA->MN (and FAs of course). > >This is the cleanest approach, in my opinion, because NATs may operate >on any of these fields. To be future proof, we should have all the >information available for detection and compensation. (I realize this >is in conflict with UNSAF considerations though.) > >As for the current uses, we need some extra stuff to: > > - to handle the FA case being discussed (allow src address != CoA) > > - to detect destination address NAT (port forwarding) robustly > (it can be done in other ways too, though.) > > - to cover the admittedly improbable corner case where only the MN > source port (and not the source address) is NATted > >Best regards, > >-Sami > > >-- >Mip4 mailing list: Mip4@ietf.org > Web interface: https://www.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html >Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Fri Mar 19 02:04:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09443 for ; Fri, 19 Mar 2004 02:04:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4E2t-0001tX-RQ for mip4-archive@odin.ietf.org; Fri, 19 Mar 2004 02:03:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2J73taT007259 for mip4-archive@odin.ietf.org; Fri, 19 Mar 2004 02:03:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4E2r-0001s6-8o for mip4-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 02:03:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08850 for ; Fri, 19 Mar 2004 02:03:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4E2n-00005W-00 for mip4-web-archive@ietf.org; Fri, 19 Mar 2004 02:03:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4E1s-00001m-00 for mip4-web-archive@ietf.org; Fri, 19 Mar 2004 02:02:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4E11-0007mH-00 for mip4-web-archive@ietf.org; Fri, 19 Mar 2004 02:01:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4E13-00013C-DI; Fri, 19 Mar 2004 02:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4E0w-00010c-ED for mip4@optimus.ietf.org; Fri, 19 Mar 2004 02:01:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06723 for ; Fri, 19 Mar 2004 02:01:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4E0t-0007kv-00 for mip4@ietf.org; Fri, 19 Mar 2004 02:01:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4Dzw-0007h6-00 for mip4@ietf.org; Fri, 19 Mar 2004 02:00:53 -0500 Received: from [212.182.218.5] (helo=nuoli.com) by ietf-mx with smtp (Exim 4.12) id 1B4Dz4-0007a1-00 for mip4@ietf.org; Fri, 19 Mar 2004 01:59:58 -0500 Received: (qmail 57967 invoked by uid 89); 19 Mar 2004 06:58:07 -0000 Message-ID: <20040319065807.57965.qmail@nuoli.com> References: <20040319055420.298c5f19.henrik@levkowetz.com> In-Reply-To: <20040319055420.298c5f19.henrik@levkowetz.com> From: sami.vaarala@iki.fi To: Henrik Levkowetz Cc: "O'Neill Alan" , sami.vaarala@iki.fi, mip4@ietf.org Date: Fri, 19 Mar 2004 08:58:07 +0200 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip4] Re: RFC 3344 - Source Address of the RRQ & FHAE issues Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alan & Henrik, > (Henrik) > The main reason I was thinking to not do this in rfc3344bis is that the > purpose of the revision is to take it to Draft Standard, and we definitely > can forget about that with this addition. Although I don't like proliferation of extensions, I'd have to agree. In an ideal world I'd like to have RFC 3519 and this a part of the base specification, though. > Yes. But don't you think the whole thing can be written up standalone as an > addition to NAT traversal - after all it's with NAT traversal it becomes > interesting. As long as you don't add any NAT traversal extension, 3344bis > is fine as is without this, no? As a practical matter it might be easiest to have this in an RFC 3519 revision (from an implementor's point of view). Still, as the address information may be useful in other situations too, a separate extension may be warranted. I don't like the latter approach too much because it has overlapping processing with RFC 3519 -- should an RFC 3519 compliant node do NAT detection based on CoA field or these addresses, i.e. do we override RFC 3519 semantics IF this extension is present? If we don't, do we require consistency checks, e.g. if MN is using co-located, CoA should match original source address, etc. We implemented an extension ("original address info") containing the four fields, and some of the rrq/rrp processing was complicated slightly by that. I've got some notes regarding the changes required for rrq/rrp, so that might be helpful if we decide to use this route. Best, -Sami -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Fri Mar 19 05:11:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25381 for ; Fri, 19 Mar 2004 05:11:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Gy0-0005MS-Ah for mip4-archive@odin.ietf.org; Fri, 19 Mar 2004 05:11:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2JAB3do020580 for mip4-archive@odin.ietf.org; Fri, 19 Mar 2004 05:11:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Gxx-0005Ln-AH for mip4-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 05:11:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25350 for ; Fri, 19 Mar 2004 05:10:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4Gxu-0005uO-00 for mip4-web-archive@ietf.org; Fri, 19 Mar 2004 05:10:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4Gww-0005qp-00 for mip4-web-archive@ietf.org; Fri, 19 Mar 2004 05:09:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4Gvz-0005nN-00 for mip4-web-archive@ietf.org; Fri, 19 Mar 2004 05:08:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Gw2-0005F1-EV; Fri, 19 Mar 2004 05:09:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Gv5-00053u-Vh for mip4@optimus.ietf.org; Fri, 19 Mar 2004 05:08:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25289 for ; Fri, 19 Mar 2004 05:08:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4Gv2-0005k1-00 for mip4@ietf.org; Fri, 19 Mar 2004 05:08:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4Gu8-0005gx-00 for mip4@ietf.org; Fri, 19 Mar 2004 05:07:04 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B4Gts-0005dX-01 for mip4@ietf.org; Fri, 19 Mar 2004 05:06:48 -0500 content-class: urn:content-classes:message Subject: RE: [Mip4] Re: RFC 3344 - Source Address of the RRQ & FHAE issues Date: Fri, 19 Mar 2004 05:06:23 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [Mip4] Re: RFC 3344 - Source Address of the RRQ & FHAE issues Thread-Index: AcQNbkDPOpvx0XkARwSB9ORn5NJLAQAKC4DA From: "O'Neill Alan" To: "Henrik Levkowetz" Cc: , Content-Transfer-Encoding: quoted-printable Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Of course Henrik - your absolutely right.=20 I was just thinking that the extension might be more generally useful = but it is in contrast absolutely tied to NAT Traversal. -----Original Message----- From: Henrik Levkowetz [mailto:henrik@levkowetz.com]=20 Sent: Friday, March 19, 2004 3:24 PM To: O'Neill Alan Cc: sami.vaarala@iki.fi; mip4@ietf.org Subject: Re: [Mip4] Re: RFC 3344 - Source Address of the RRQ & FHAE = issues Hi Alan, Thursday 18 March 2004, O'Neill Alan wrote: > Why don't we define the source address extension in RFC3344biz because = FHAE > needs it in the discussed corner case, and state that it may be added = into > the RREQ when the source address is not equal to the FA CoA, quoting = the FHAE > example. You might also want to define a destination address extension = as > well for completeness. The main reason I was thinking to not do this in rfc3344bis is that the purpose of the revision is to take it to Draft Standard, and we = definitely can forget about that with this addition. > A short additional doc that can later wrap into NAT Trav can then = build on > this and define the additional extensions for src and dest ports (and = dest IP > if not included in RFC3344biz). Yes. But don't you think the whole thing can be written up standalone = as an addition to NAT traversal - after all it's with NAT traversal it becomes = interesting. As long as you don't add any NAT traversal extension, = 3344bis is fine as is without this, no? Henrik -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Fri Mar 19 06:05:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25380 for ; Fri, 19 Mar 2004 05:11:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Gy0-0005MR-AX for mip4-archive@odin.ietf.org; Fri, 19 Mar 2004 05:11:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2JAB3ce020579 for mip4-archive@odin.ietf.org; Fri, 19 Mar 2004 05:11:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Gxw-0005Lh-Oa for mip4-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 05:11:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25347 for ; Fri, 19 Mar 2004 05:10:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4Gxt-0005uH-00 for mip4-web-archive@ietf.org; Fri, 19 Mar 2004 05:10:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4Gwv-0005qh-00 for mip4-web-archive@ietf.org; Fri, 19 Mar 2004 05:09:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4Gvz-0005nK-00 for mip4-web-archive@ietf.org; Fri, 19 Mar 2004 05:08:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Gw1-0005ES-PY; Fri, 19 Mar 2004 05:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Gv4-00053R-Gh for mip4@optimus.ietf.org; Fri, 19 Mar 2004 05:08:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25286 for ; Fri, 19 Mar 2004 05:07:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4Gv1-0005jo-00 for mip4@ietf.org; Fri, 19 Mar 2004 05:07:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4Gu7-0005gn-00 for mip4@ietf.org; Fri, 19 Mar 2004 05:07:03 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B4Gts-0005dX-00 for mip4@ietf.org; Fri, 19 Mar 2004 05:06:48 -0500 content-class: urn:content-classes:message Subject: RE: [Mip4] [issue44] RFC 3344 - Source Address of the RRQ & FHAE issues Date: Fri, 19 Mar 2004 05:06:16 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [Mip4] [issue44] RFC 3344 - Source Address of the RRQ & FHAE issues Thread-Index: AcQNdl7mzU5lTf+4QmG8JXOXeUfzaQAIF7bg From: "O'Neill Alan" To: "Kent Leung" Cc: Content-Transfer-Encoding: quoted-printable Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.4 required=5.0 tests=AWL,NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Kent, -----Original Message----- From: Kent Leung [mailto:kleung@cisco.com]=20 What is meant by "signed"? Implying FHAE protected or some FA signature in the extension? A bit more clarification would help. AWO> Yes - FHAE protected was the assumption if one exists.=20 Let's say there is no pre-existing SA between FA and HA. How is the extension protected? AWO> Thinking as I write (which is often inadvisable at 8.30pm), it may = well be, that in principle, given that this extension is only used in a = comparison with the unprotected packet source address, that it might be ok to leave unsigned because whilst a fraudulent delta could be created by a MiTM by modifying the extension, they could just as easily create that delta = with a signed version, simply by changing the unprotected packet source = address. We should think about that aspect a lot more though I agree. It's a good idea. But I assumed that this was not used because the FA cannot add extensions without FHAE to protect the message? So as long as we have a method to protect this new extension, I'm fine with it since it meets our requirement for an FA identifier for the FHAE authentication. AWO> Ok - that's good. Though using FA NAI has the advantage of minimizing SA entries on HA. There would be one SA for FA, regardless how many CoA or source IP addresses used in the registration request. I'm sure not everyone will agree that it's a good thing. :) AWO> I was primarily keen to push back on the FA CoA nailing, and an = FHAE identification solution potentially falls out as well. However, I can certainly see the benefit of your scheme for the FHAE issue. Alan -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Mon Mar 22 04:28:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11861 for ; Mon, 22 Mar 2004 04:28:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5LjI-0006hu-V7 for mip4-archive@odin.ietf.org; Mon, 22 Mar 2004 04:28:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2M9SKFc025772 for mip4-archive@odin.ietf.org; Mon, 22 Mar 2004 04:28:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5LjG-0006hb-8c for mip4-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 04:28:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11858 for ; Mon, 22 Mar 2004 04:28:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5LjD-0004w2-00 for mip4-web-archive@ietf.org; Mon, 22 Mar 2004 04:28:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5LiM-0004rY-00 for mip4-web-archive@ietf.org; Mon, 22 Mar 2004 04:27:22 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5Li6-0004mf-00 for mip4-web-archive@ietf.org; Mon, 22 Mar 2004 04:27:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Li8-0006bO-2W; Mon, 22 Mar 2004 04:27:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5LhW-0006Zh-Ev for mip4@optimus.ietf.org; Mon, 22 Mar 2004 04:26:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11801 for ; Mon, 22 Mar 2004 04:26:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5LhT-0004lM-00 for mip4@ietf.org; Mon, 22 Mar 2004 04:26:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5LgV-0004ey-00 for mip4@ietf.org; Mon, 22 Mar 2004 04:25:28 -0500 Received: from [210.82.33.227] (helo=vpn.uptech.com) by ietf-mx with esmtp (Exim 4.12) id 1B5Lfb-0004RU-00 for mip4@ietf.org; Mon, 22 Mar 2004 04:24:32 -0500 Received: from bj01.beijing.uptech.com ([10.1.1.1]) by vpn.uptech.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 22 Mar 2004 17:23:15 +0800 Received: from ALEX ([10.3.201.166] RDNS failed) by bj01.beijing.uptech.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 22 Mar 2004 17:23:14 +0800 Message-ID: <012a01c40fef$62a81700$a6c9030a@ALEX> From: "Alexandre Tian" To: Date: Mon, 22 Mar 2004 17:23:47 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0127_01C41032.6F1BAB30" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 22 Mar 2004 09:23:14.0954 (UTC) FILETIME=[4DC47EA0:01C40FEF] Subject: [Mip4] Suggestion for Multiple-Interface MNs Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.9 required=5.0 tests=AWL,FORGED_OUTLOOK_TAGS, MIME_BASE64_TEXT autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0127_01C41032.6F1BAB30 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SSB0aGluayB0aGlzIHdvcmRzIGZvdW5kIGluIKGwQXBwZW5kaXggQiAtIExvdyBMYXRlbmN5IEhh bmRvZmZzIGZvciBNdWx0aXBsZS1JbnRlcmZhY2UgTU5zobE6obBUaGUgTU4gYWN0aXZhdGVzIHRo ZSBpbnRlcmZhY2UgdG8gUk4yIGJ1dCBjb250aW51ZXMgY29tbXVuaWNhdGluZyB0aHJvdWdoIFJO MS4gIFRoZSBNTiBtYXkgc29saWNpdCBhZHZlcnRpc2VtZW50cyBmcm9tIG5GQSB0aHJvdWdoIHRo ZSAgaW50ZXJmYWNlIGNvbm5lY3RlZCB0byBSTjEgdG8gc3BlZWQgdXAgdGhlIGhhbmRvZmYgcHJv Y2VzcywgcHJvdmlkZWQgdGhlcmUgaXMgbm8gVFRMIHJlc3RyaWN0aW9uLCBvciBpdCBjYW4gc29s aWNpdCBhZHZlcnRpc2VtZW50cyB0aHJvdWdoIHRoZSBpbnRlcmZhY2UgY29ubmVjdGVkIHRvIFJO MiBpZiBpdCBoYXMgYmVlbiBjb25maWd1cmVkIGZvciBJUCB0cmFmZmljLqGxIG1heWJlIGluYWNj dXJhdGUuIFRoZXNlIGNvdWxkbid0IHByb3ZpZGUgInNlYW1sZXNzIGhhbmRvZmYiIGFzIHNhaWQg aW4gdGhlIGZvbGxvd2luZy4NCkkgaGF2ZSByZWFsaXplZCBhIE1vYmlsZSBJUCBpbXBsZW1lbnRh dGlvbiBpbiBXaW5kb3dzIDIwMDAgcGxhdGZvcm0gb25lIHllYXIgYWdvLiBJbiBhIE11bHRpcGxl IFBoeXNpY2FsIEludGVyZmFjZSBzaXR1YXRpb24sIHRoZXJlIHNob3VsZCBvbmx5IGJlIG9uZSBJ UCBpbnRlcmZhY2UgZm9yIE1uLiBpZiB3ZSB3YW50IHNlYW1sZXNzIGhhbmRvZmYuIEZvciBleGFt cGxlLCBhc3N1bWUgd2UgaGF2ZSB0d28gcGh5c2ljYWwgaW50ZXJmYWNlcyggUEkxIGFuZCBQSTIp IGFuZCBib3RoIGhhdmUgdGhlaXIgb3duIElQIGludGVyZmFjZS4gV2hlbiB0aGVyZSBpcyBhIGhh bmRvZmYgZnJvbSBQSTEgdG8gUEkyLCB3ZSBtdXN0IGZpcnN0IHVuYmluZCBtb2JpbGUgaXAgYWRk cmVzcyBmcm9tIFBJMSBhbmQgdGhlbiBiaW5kIGl0IHRvIFBJMi4gRHVyaW5nIHRoZSBicmVhayAo ZXZlbiBvbmx5IHNldmVyYWwgbWlsbGlzZWNvbmRzKSwgdGhlIElQIHJvdXRlIHRhYmxlIHdvdWxk IGJlIGVtcHR5IGFuZCB1bnVzYWJsZSwgdGhhdCB3b3VsZCBzdXJlbHkgYnJlYWsgbW9zdCBzdHJl YW0gYXBwbGljYXRpb25zIGxpa2Ugb25saW5lIG1vdmllIG9yIFZvSVAgcGhvbmUuDQpTdGlsbCB0 aGUgZXhhbXBsZSwgbXkgaW1wbGVtZW50YXRpb24gY2FuY2VscyB0aGUgb3JpZ2luYWwgSVAgYmlu ZGluZ3Mgb2YgYm90aCBQSTEgYW5kIFBJMi4gSW5zdGVhZCwgSSB1c2UgdW5pcXVlIHN5c3RlbSB2 aXJ0dWFsIElQIGRldmljZSBhbmQgY29uZmlndXJlIHRoZSBtb2JpbGUgaXAgYWRkcmVzcyB0byBp dC4gQWxsIHBoeXNpY2FsIGludGVyZmFjZXMgYXJlIG9ubHkgTGF5ZXIgMiBkZXZpY2VzIGFuZCBt YW5hZ2VkIGJ5IHRoZSB2aXJ0dWFsIGxheWVyIDMgSVAgZGV2aWNlKFZJUEQpLiBJUCBwYWNrZXRz IGFyZSB0cmFuc21pdHRlZCBieSB0aGUgVklQRC4gT2YgY2F1c2UgLCBWSVBEIHNlbGVjdCB3aGlj aCBkZXZpY2UgdG8gc2VuZCBhIHNwZWNpZmljIElQIHBhY2tldC4gV2hlbiBoYW5kb2ZmIGZyb20g UEkxIGxpbmsgdG8gUEkyIGxpbmssIFZJUEQga2VlcCBJUCB0cmFmZmljIHRocm91Z2ggUEkxLCBh bmQgc2VuZCBzb2xpY2l0IGFkdmVydGlzZW1lbnRzIHRocm91Z2ggUEkyLg0KVGh1cywgZHVyaW5n IHRoZSBoYW5kb2ZmLCB0aGVyZSBpcyBubyBJUCBhZGRyZXNzIHVuYmluZGluZyBhbmQgYmluZGlu ZyBuZWVkIG1vcmUuIFRoaXMgaXMgcmVhbCBzZWFtbGVzcyBoYW5kb2ZmLiANCg== ------=_NextPart_000_0127_01C41032.6F1BAB30 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yODAwLjE0MDAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIg c2l6ZT00PkkgdGhpbmsgdGhpcyB3b3JkcyBmb3VuZCBpbiChsEFwcGVuZGl4IEIgDQotIExvdyBM YXRlbmN5IEhhbmRvZmZzIGZvciBNdWx0aXBsZS1JbnRlcmZhY2UgTU5zobE6obBUaGUgTU4gYWN0 aXZhdGVzIHRoZSANCmludGVyZmFjZSB0byBSTjIgYnV0IGNvbnRpbnVlcyBjb21tdW5pY2F0aW5n IHRocm91Z2ggUk4xLiZuYnNwOyBUaGUgTU4gbWF5IA0Kc29saWNpdCBhZHZlcnRpc2VtZW50cyBm cm9tIG5GQSB0aHJvdWdoIHRoZSZuYnNwOyBpbnRlcmZhY2UgY29ubmVjdGVkIHRvIFJOMSB0byAN CnNwZWVkIHVwIHRoZSBoYW5kb2ZmIHByb2Nlc3MsIHByb3ZpZGVkIHRoZXJlIGlzIG5vIFRUTCBy ZXN0cmljdGlvbiwgb3IgaXQgY2FuIA0Kc29saWNpdCBhZHZlcnRpc2VtZW50cyB0aHJvdWdoIHRo ZSBpbnRlcmZhY2UgY29ubmVjdGVkIHRvIFJOMiBpZiBpdCBoYXMgYmVlbiANCmNvbmZpZ3VyZWQg Zm9yIElQIHRyYWZmaWMuobEgbWF5YmUgaW5hY2N1cmF0ZS4gVGhlc2UgY291bGRuJ3QgcHJvdmlk ZSAic2VhbWxlc3MgDQpoYW5kb2ZmIiBhcyBzYWlkIGluIHRoZSBmb2xsb3dpbmcuPEJSPkkgaGF2 ZSByZWFsaXplZCBhIE1vYmlsZSBJUCBpbXBsZW1lbnRhdGlvbiANCmluIFdpbmRvd3MgMjAwMCBw bGF0Zm9ybSBvbmUgeWVhciBhZ28uIEluIGEgTXVsdGlwbGUgUGh5c2ljYWwgSW50ZXJmYWNlIA0K c2l0dWF0aW9uLCB0aGVyZSBzaG91bGQgb25seSBiZSBvbmUgSVAgaW50ZXJmYWNlIGZvciBNbi4g aWYgd2Ugd2FudCBzZWFtbGVzcyANCmhhbmRvZmYuIEZvciBleGFtcGxlLCBhc3N1bWUgd2UgaGF2 ZSB0d28gcGh5c2ljYWwgaW50ZXJmYWNlcyggUEkxIGFuZCBQSTIpIGFuZCANCmJvdGggaGF2ZSB0 aGVpciBvd24gSVAgaW50ZXJmYWNlLiBXaGVuIHRoZXJlIGlzIGEgaGFuZG9mZiBmcm9tIFBJMSB0 byBQSTIsIHdlIA0KbXVzdCBmaXJzdCB1bmJpbmQgbW9iaWxlIGlwIGFkZHJlc3MgZnJvbSBQSTEg YW5kIHRoZW4gYmluZCBpdCB0byBQSTIuIER1cmluZyB0aGUgDQpicmVhayAoZXZlbiBvbmx5IHNl dmVyYWwgbWlsbGlzZWNvbmRzKSwgdGhlIElQIHJvdXRlIHRhYmxlIHdvdWxkIGJlIGVtcHR5IGFu ZCANCnVudXNhYmxlLCB0aGF0IHdvdWxkIHN1cmVseSBicmVhayBtb3N0IHN0cmVhbSBhcHBsaWNh dGlvbnMgbGlrZSBvbmxpbmUgbW92aWUgb3IgDQpWb0lQIHBob25lLjxCUj5TdGlsbCB0aGUgZXhh bXBsZSwgbXkgaW1wbGVtZW50YXRpb24gY2FuY2VscyB0aGUgb3JpZ2luYWwgSVAgDQpiaW5kaW5n cyBvZiBib3RoIFBJMSBhbmQgUEkyLiBJbnN0ZWFkLCBJIHVzZSB1bmlxdWUgc3lzdGVtIHZpcnR1 YWwgSVAgZGV2aWNlIGFuZCANCmNvbmZpZ3VyZSB0aGUgbW9iaWxlIGlwIGFkZHJlc3MgdG8gaXQu IEFsbCBwaHlzaWNhbCBpbnRlcmZhY2VzIGFyZSBvbmx5IExheWVyIDIgDQpkZXZpY2VzIGFuZCBt YW5hZ2VkIGJ5IHRoZSB2aXJ0dWFsIGxheWVyIDMgSVAgZGV2aWNlKFZJUEQpLiBJUCBwYWNrZXRz IGFyZSANCnRyYW5zbWl0dGVkIGJ5IHRoZSBWSVBELiBPZiBjYXVzZSAsIFZJUEQgc2VsZWN0IHdo aWNoIGRldmljZSB0byBzZW5kIGEgc3BlY2lmaWMgDQpJUCBwYWNrZXQuIFdoZW4gaGFuZG9mZiBm cm9tIFBJMSBsaW5rIHRvIFBJMiBsaW5rLCBWSVBEIGtlZXAgSVAgdHJhZmZpYyB0aHJvdWdoIA0K UEkxLCBhbmQgc2VuZCBzb2xpY2l0IGFkdmVydGlzZW1lbnRzIHRocm91Z2ggUEkyLjxCUj5UaHVz LCBkdXJpbmcgdGhlIGhhbmRvZmYsIA0KdGhlcmUgaXMgbm8gSVAgYWRkcmVzcyB1bmJpbmRpbmcg YW5kIGJpbmRpbmcgbmVlZCBtb3JlLiBUaGlzIGlzIHJlYWwgc2VhbWxlc3MgDQpoYW5kb2ZmLiA8 QlI+PC9GT05UPjwvRElWPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_0127_01C41032.6F1BAB30-- -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Mon Mar 22 04:32:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11975 for ; Mon, 22 Mar 2004 04:32:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5LnD-00070Q-61 for mip4-archive@odin.ietf.org; Mon, 22 Mar 2004 04:32:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2M9WNhl026926 for mip4-archive@odin.ietf.org; Mon, 22 Mar 2004 04:32:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5LnC-00070D-NU for mip4-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 04:32:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11963 for ; Mon, 22 Mar 2004 04:32:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5Ln9-0005Gg-00 for mip4-web-archive@ietf.org; Mon, 22 Mar 2004 04:32:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5LmC-0005Bo-00 for mip4-web-archive@ietf.org; Mon, 22 Mar 2004 04:31:21 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5Llr-000571-00 for mip4-web-archive@ietf.org; Mon, 22 Mar 2004 04:30:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Llt-0006ry-4O; Mon, 22 Mar 2004 04:31:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5LlA-0006kD-Ff for mip4@optimus.ietf.org; Mon, 22 Mar 2004 04:30:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11918 for ; Mon, 22 Mar 2004 04:30:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5Ll7-00055n-00 for mip4@ietf.org; Mon, 22 Mar 2004 04:30:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5Lk9-00050d-00 for mip4@ietf.org; Mon, 22 Mar 2004 04:29:13 -0500 Received: from [210.82.33.227] (helo=vpn.uptech.com) by ietf-mx with esmtp (Exim 4.12) id 1B5Lj9-0004s7-00 for mip4@ietf.org; Mon, 22 Mar 2004 04:28:12 -0500 Received: from bj01.beijing.uptech.com ([10.1.1.1]) by vpn.uptech.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 22 Mar 2004 17:27:02 +0800 Received: from ALEX ([10.3.201.166] RDNS failed) by bj01.beijing.uptech.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 22 Mar 2004 17:27:02 +0800 Message-ID: <013b01c40fef$ea2c51f0$a6c9030a@ALEX> From: "Alexandre Tian" To: Date: Mon, 22 Mar 2004 17:27:34 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0138_01C41032.F69D9C30" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 22 Mar 2004 09:27:02.0195 (UTC) FILETIME=[D536B830:01C40FEF] Subject: [Mip4] Suggestion for Multiple-Interface MNs in <> Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.0 required=5.0 tests=AWL,FORGED_OUTLOOK_TAGS, MIME_BASE64_TEXT autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0138_01C41032.F69D9C30 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SSB0aGluayB0aGlzIHdvcmRzIGZvdW5kIGluIKGwQXBwZW5kaXggQiAtIExvdyBMYXRlbmN5IEhh bmRvZmZzIGZvciBNdWx0aXBsZS1JbnRlcmZhY2UgTU5zobE6obBUaGUgTU4gYWN0aXZhdGVzIHRo ZSBpbnRlcmZhY2UgdG8gUk4yIGJ1dCBjb250aW51ZXMgY29tbXVuaWNhdGluZyB0aHJvdWdoIFJO MS4gIFRoZSBNTiBtYXkgc29saWNpdCBhZHZlcnRpc2VtZW50cyBmcm9tIG5GQSB0aHJvdWdoIHRo ZSAgaW50ZXJmYWNlIGNvbm5lY3RlZCB0byBSTjEgdG8gc3BlZWQgdXAgdGhlIGhhbmRvZmYgcHJv Y2VzcywgcHJvdmlkZWQgdGhlcmUgaXMgbm8gVFRMIHJlc3RyaWN0aW9uLCBvciBpdCBjYW4gc29s aWNpdCBhZHZlcnRpc2VtZW50cyB0aHJvdWdoIHRoZSBpbnRlcmZhY2UgY29ubmVjdGVkIHRvIFJO MiBpZiBpdCBoYXMgYmVlbiBjb25maWd1cmVkIGZvciBJUCB0cmFmZmljLqGxIG1heWJlIGluYWNj dXJhdGUuIFRoZXNlIGNvdWxkbid0IHByb3ZpZGUgInNlYW1sZXNzIGhhbmRvZmYiIGFzIHNhaWQg aW4gdGhlIGZvbGxvd2luZy4NCkkgaGF2ZSByZWFsaXplZCBhIE1vYmlsZSBJUCBpbXBsZW1lbnRh dGlvbiBpbiBXaW5kb3dzIDIwMDAgcGxhdGZvcm0gb25lIHllYXIgYWdvLiBJbiBhIE11bHRpcGxl IFBoeXNpY2FsIEludGVyZmFjZSBzaXR1YXRpb24sIHRoZXJlIHNob3VsZCBvbmx5IGJlIG9uZSBJ UCBpbnRlcmZhY2UgZm9yIE1uLiBpZiB3ZSB3YW50IHNlYW1sZXNzIGhhbmRvZmYuIEZvciBleGFt cGxlLCBhc3N1bWUgd2UgaGF2ZSB0d28gcGh5c2ljYWwgaW50ZXJmYWNlcyggUEkxIGFuZCBQSTIp IGFuZCBib3RoIGhhdmUgdGhlaXIgb3duIElQIGludGVyZmFjZS4gV2hlbiB0aGVyZSBpcyBhIGhh bmRvZmYgZnJvbSBQSTEgdG8gUEkyLCB3ZSBtdXN0IGZpcnN0IHVuYmluZCBtb2JpbGUgaXAgYWRk cmVzcyBmcm9tIFBJMSBhbmQgdGhlbiBiaW5kIGl0IHRvIFBJMi4gRHVyaW5nIHRoZSBicmVhayAo ZXZlbiBvbmx5IHNldmVyYWwgbWlsbGlzZWNvbmRzKSwgdGhlIElQIHJvdXRlIHRhYmxlIHdvdWxk IGJlIGVtcHR5IGFuZCB1bnVzYWJsZSwgdGhhdCB3b3VsZCBzdXJlbHkgYnJlYWsgbW9zdCBzdHJl YW0gYXBwbGljYXRpb25zIGxpa2Ugb25saW5lIG1vdmllIG9yIFZvSVAgcGhvbmUuDQpTdGlsbCB0 aGUgZXhhbXBsZSwgbXkgaW1wbGVtZW50YXRpb24gY2FuY2VscyB0aGUgb3JpZ2luYWwgSVAgYmlu ZGluZ3Mgb2YgYm90aCBQSTEgYW5kIFBJMi4gSW5zdGVhZCwgSSB1c2UgdW5pcXVlIHN5c3RlbSB2 aXJ0dWFsIElQIGRldmljZSBhbmQgY29uZmlndXJlIHRoZSBtb2JpbGUgaXAgYWRkcmVzcyB0byBp dC4gQWxsIHBoeXNpY2FsIGludGVyZmFjZXMgYXJlIG9ubHkgTGF5ZXIgMiBkZXZpY2VzIGFuZCBt YW5hZ2VkIGJ5IHRoZSB2aXJ0dWFsIGxheWVyIDMgSVAgZGV2aWNlKFZJUEQpLiBJUCBwYWNrZXRz IGFyZSB0cmFuc21pdHRlZCBieSB0aGUgVklQRC4gT2YgY2F1c2UgLCBWSVBEIHNlbGVjdCB3aGlj aCBkZXZpY2UgdG8gc2VuZCBhIHNwZWNpZmljIElQIHBhY2tldC4gV2hlbiBoYW5kb2ZmIGZyb20g UEkxIGxpbmsgdG8gUEkyIGxpbmssIFZJUEQga2VlcCBJUCB0cmFmZmljIHRocm91Z2ggUEkxLCBh bmQgc2VuZCBzb2xpY2l0IGFkdmVydGlzZW1lbnRzIHRocm91Z2ggUEkyLg0KVGh1cywgZHVyaW5n IHRoZSBoYW5kb2ZmLCB0aGVyZSBpcyBubyBJUCBhZGRyZXNzIHVuYmluZGluZyBhbmQgYmluZGlu ZyBuZWVkIG1vcmUuIFRoaXMgaXMgcmVhbCBzZWFtbGVzcyBoYW5kb2ZmLiANCg== ------=_NextPart_000_0138_01C41032.F69D9C30 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yODAwLjE0MDAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj4NCjxESVY+PEZPTlQgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPTQ+SSB0aGluayB0aGlzIHdvcmRzIGZvdW5kIGluIKGw QXBwZW5kaXggQiANCi0gTG93IExhdGVuY3kgSGFuZG9mZnMgZm9yIE11bHRpcGxlLUludGVyZmFj ZSBNTnOhsTqhsFRoZSBNTiBhY3RpdmF0ZXMgdGhlIA0KaW50ZXJmYWNlIHRvIFJOMiBidXQgY29u dGludWVzIGNvbW11bmljYXRpbmcgdGhyb3VnaCBSTjEuJm5ic3A7IFRoZSBNTiBtYXkgDQpzb2xp Y2l0IGFkdmVydGlzZW1lbnRzIGZyb20gbkZBIHRocm91Z2ggdGhlJm5ic3A7IGludGVyZmFjZSBj b25uZWN0ZWQgdG8gUk4xIHRvIA0Kc3BlZWQgdXAgdGhlIGhhbmRvZmYgcHJvY2VzcywgcHJvdmlk ZWQgdGhlcmUgaXMgbm8gVFRMIHJlc3RyaWN0aW9uLCBvciBpdCBjYW4gDQpzb2xpY2l0IGFkdmVy dGlzZW1lbnRzIHRocm91Z2ggdGhlIGludGVyZmFjZSBjb25uZWN0ZWQgdG8gUk4yIGlmIGl0IGhh cyBiZWVuIA0KY29uZmlndXJlZCBmb3IgSVAgdHJhZmZpYy6hsSBtYXliZSBpbmFjY3VyYXRlLiBU aGVzZSBjb3VsZG4ndCBwcm92aWRlICJzZWFtbGVzcyANCmhhbmRvZmYiIGFzIHNhaWQgaW4gdGhl IGZvbGxvd2luZy48QlI+SSBoYXZlIHJlYWxpemVkIGEgTW9iaWxlIElQIGltcGxlbWVudGF0aW9u IA0KaW4gV2luZG93cyAyMDAwIHBsYXRmb3JtIG9uZSB5ZWFyIGFnby4gSW4gYSBNdWx0aXBsZSBQ aHlzaWNhbCBJbnRlcmZhY2UgDQpzaXR1YXRpb24sIHRoZXJlIHNob3VsZCBvbmx5IGJlIG9uZSBJ UCBpbnRlcmZhY2UgZm9yIE1uLiBpZiB3ZSB3YW50IHNlYW1sZXNzIA0KaGFuZG9mZi4gRm9yIGV4 YW1wbGUsIGFzc3VtZSB3ZSBoYXZlIHR3byBwaHlzaWNhbCBpbnRlcmZhY2VzKCBQSTEgYW5kIFBJ MikgYW5kIA0KYm90aCBoYXZlIHRoZWlyIG93biBJUCBpbnRlcmZhY2UuIFdoZW4gdGhlcmUgaXMg YSBoYW5kb2ZmIGZyb20gUEkxIHRvIFBJMiwgd2UgDQptdXN0IGZpcnN0IHVuYmluZCBtb2JpbGUg aXAgYWRkcmVzcyBmcm9tIFBJMSBhbmQgdGhlbiBiaW5kIGl0IHRvIFBJMi4gRHVyaW5nIHRoZSAN CmJyZWFrIChldmVuIG9ubHkgc2V2ZXJhbCBtaWxsaXNlY29uZHMpLCB0aGUgSVAgcm91dGUgdGFi bGUgd291bGQgYmUgZW1wdHkgYW5kIA0KdW51c2FibGUsIHRoYXQgd291bGQgc3VyZWx5IGJyZWFr IG1vc3Qgc3RyZWFtIGFwcGxpY2F0aW9ucyBsaWtlIG9ubGluZSBtb3ZpZSBvciANClZvSVAgcGhv bmUuPEJSPlN0aWxsIHRoZSBleGFtcGxlLCBteSBpbXBsZW1lbnRhdGlvbiBjYW5jZWxzIHRoZSBv cmlnaW5hbCBJUCANCmJpbmRpbmdzIG9mIGJvdGggUEkxIGFuZCBQSTIuIEluc3RlYWQsIEkgdXNl IHVuaXF1ZSBzeXN0ZW0gdmlydHVhbCBJUCBkZXZpY2UgYW5kIA0KY29uZmlndXJlIHRoZSBtb2Jp bGUgaXAgYWRkcmVzcyB0byBpdC4gQWxsIHBoeXNpY2FsIGludGVyZmFjZXMgYXJlIG9ubHkgTGF5 ZXIgMiANCmRldmljZXMgYW5kIG1hbmFnZWQgYnkgdGhlIHZpcnR1YWwgbGF5ZXIgMyBJUCBkZXZp Y2UoVklQRCkuIElQIHBhY2tldHMgYXJlIA0KdHJhbnNtaXR0ZWQgYnkgdGhlIFZJUEQuIE9mIGNh dXNlICwgVklQRCBzZWxlY3Qgd2hpY2ggZGV2aWNlIHRvIHNlbmQgYSBzcGVjaWZpYyANCklQIHBh Y2tldC4gV2hlbiBoYW5kb2ZmIGZyb20gUEkxIGxpbmsgdG8gUEkyIGxpbmssIFZJUEQga2VlcCBJ UCB0cmFmZmljIHRocm91Z2ggDQpQSTEsIGFuZCBzZW5kIHNvbGljaXQgYWR2ZXJ0aXNlbWVudHMg dGhyb3VnaCBQSTIuPEJSPlRodXMsIGR1cmluZyB0aGUgaGFuZG9mZiwgDQp0aGVyZSBpcyBubyBJ UCBhZGRyZXNzIHVuYmluZGluZyBhbmQgYmluZGluZyBuZWVkIG1vcmUuIFRoaXMgaXMgcmVhbCBz ZWFtbGVzcyANCmhhbmRvZmYuIDxCUj48L0ZPTlQ+PC9ESVY+PC9GT05UPjwvRElWPjwvQk9EWT48 L0hUTUw+DQo= ------=_NextPart_000_0138_01C41032.F69D9C30-- -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Mon Mar 22 12:08:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06526 for ; Mon, 22 Mar 2004 12:08:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Su6-0002Rq-5x for mip4-archive@odin.ietf.org; Mon, 22 Mar 2004 12:08:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MH7oAg009179 for mip4-archive@odin.ietf.org; Mon, 22 Mar 2004 12:07:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Stx-0002Ll-Q5 for mip4-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 12:07:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06512 for ; Mon, 22 Mar 2004 12:07:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5Str-0005bd-00 for mip4-web-archive@ietf.org; Mon, 22 Mar 2004 12:07:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5St3-0005VR-00 for mip4-web-archive@ietf.org; Mon, 22 Mar 2004 12:06:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5SsY-0005Oa-00 for mip4-web-archive@ietf.org; Mon, 22 Mar 2004 12:06:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Sqw-00022u-Nf; Mon, 22 Mar 2004 12:04:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Spv-0001za-8e for mip4@optimus.ietf.org; Mon, 22 Mar 2004 12:03:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06281 for ; Mon, 22 Mar 2004 12:03:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5Spt-00056Z-00 for mip4@ietf.org; Mon, 22 Mar 2004 12:03:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5Sp7-0004z5-00 for mip4@ietf.org; Mon, 22 Mar 2004 12:02:50 -0500 Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx with esmtp (Exim 4.12) id 1B5SoM-0004nF-00 for mip4@ietf.org; Mon, 22 Mar 2004 12:02:02 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i2MH1UTN011941 for ; Mon, 22 Mar 2004 11:01:30 -0600 (CST) Message-ID: <405F1D45.C101C243@alcatel.com> Date: Mon, 22 Mar 2004 11:07:17 -0600 From: Tim Ozugur X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mip4@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip4] CFP:Broadband Wireless Networking Symposium 2004 - Extended Deadline Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,LINES_OF_YELLING, LINES_OF_YELLING_2 autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit (Apologies if you are receiving this message more than once) ----------------------------------------------------------------------- CALL FOR PAPERS BroadNets 2004 Broadband Wireless Networking Symposium 2004 October 25 - 29, 2004 San Jose, California, USA www.broadnets.org ***** Extended Submission Deadline: April 1, 2004 ***** ----------------------------------------------------------------------- SCOPE ----- BroadNets 2004 is a new conference focusing on broadband networking and covers the entire gamut of next generation networks with ultra-high bandwidth available all the way from access networks (xDSL, Cable, EPON, Broadband Wireless, multi-Gigabit uplinks), to regional and metropolitan networks to wide-area core networks. The conference will consist of the following two symposia: ** Broadband Wireless Networking that is defined to cover high-speed wireless networking for access, regional and backhaul networks including backhaul capacity provisioning using wireless, including the WLAN networks and WMAN. ** Broadband Optical Networking includes WDM technologies, Ethernet and MPLS integration into the optical layer, Next-Gen SONET/SDH, as well as SAN extentions over DWDM/SONET/SDH. BroadNets 2004 will thus offer a unique forum for researchers from academia, government and industry to share ideas and disseminate new results in these important areas. In addition to expansion in scope, BroadNets 2004 will expand its target audience by encouraging industry contributions, through architecture and position papers. More details can be found at www.broadnets.org. This Call for Papers describes the details for the Broadband Wireless Networking Symposium ONLY. (Refer to the broadnets.org website for the Broadband Optical Symposium details.) We are soliciting full papers in all research, development, and deployment areas on broadband wireless networking. Applications/position/system papers from industry are also encouraged. Topics of interest include, but not limited to, the following: - 3G/4G Systems - Fixed Broadband Wireless Access - Wireless Local Area Networks - WLAN Hotspots - Wireless indoor & home networks - Wireless Personal Area Networks including IEEE 802.15 - IEEE 802.16 (WiMax) Standards Activities and Products - Wireless Metropolitan Area Networks - Wireless Wide Area Networks - Free-Space Optics - Ultra Wideband (UWB) Networks - Ad-hoc networks - Cellular mobile/WLAN interoperability - System architecture - Network Topology management - Neighbour discovery - Unicast and multicast routing - Quality-of-Service support - Security techniques and systems - Resource management - Software-defined radio - Space-time processing, MIMO systems - Digital signal processing - Smart (directional) antennas - Power control - Wireless emergency systems - Standards, Licensing and regulation - Interference mitigation for multiple access - Economics and business cases IMPORTANT DATES --------------- Full papers due: April 1, 2004 Notification of acceptance: June 7, 2004 Final manuscript due: July 7, 2004 Conference Dates: October 25 - 29, 2004 PAPER SUBMISSION INSTRUCTIONS ----------------------------- Authors are invited to submit full papers of up to 20 double-spaced pages in Times 10pt font, including references, figures and tables. All submissions should be submitted electronically to EDAS system at http://edas.info/Conferences.cgi and in Postscript or Adobe PDF format. Papers of particular merit will be considered for a special issue of ACM/Kluwer Mobile Networks (MONET) Journal. PROPOSALS FOR WORKSHOPS, TUTORIALS AND PANELS --------------------------------------------- Proposals for workshops, tutorials and panels on broadband wireless networking and related topics are solicited. Contact information for respective Chairs can be found at www.broadnets.org. Workshop proposals should consist of: 1) title of the workshop, 2) description of potential audience, 3) description of the workshop topic and justification of why the proposed topic is interesting and timely and, 4) intended format of the workshop. Please submit your proposals to the appropriate Chairs by April 1, 2004. Tutorial proposals should consist of: 1) title and outline of materials to be presented, 2) description of potential audience, 3) justification of why the proposed topic is interesting and timely and, 4) biographical sketch of the presenter(s). Please submit your proposals to the appropriate Chairs by May 1, 2004. Panel topics should address innovative, controversial, or otherwise provocative issues of interest related to broadband wireless networking and communications. Please submit your proposals to the appropriate Chairs by May 1, 2004. CONFERENCE INFORMATION ---------------------- For the general information about the organization of the BroadNets 2004 conference, please visit http://www.broadnets.org or contact one of the conference chairs listed below (more details are on the website). CONFERENCE ORGANIZING COMMITTEE ------------------------------- BroadNets Conference General Chair: Dr. Raj Jain, Nayna Networks/Ohio State University, raj@nayna.com Broadband Wireless Networking Symposium Chair: Dr. Zhensheng Zhang, San Diego Research Center, zzhang@ieee.org Technical Program Co-Chairs: Dr. Parameswaran Ramanathan, Univ. of Wisconsin-Madison, parmesh@ece.wisc.edu Dr. Thomas Hou, Virginia Tech, thou@vt.edu Panels Co-Chairs: Dr. Byrav Ramamurthy, University of Nebraska - Lincoln, byrav@cse.unl.edu Dr. Loukas Paraschis, Cisco Systems, loukas@cisco.com Tutorials Co-Chairs: Dr. Hakki Candan Cankaya, Alcatel USA, hakki.cankaya@alcatel.com Dr. Surendar Chandra, Univ of Notre Dame, surendar@cse.nd.edu Workshops Co-Chairs: Dr. Nasir Ghani, Tennessee Tech University, nghani@ieee.org Dr. Rajeev Shorey, National University of Singapore and IBM Research India, rajeev@comp.nus.edu.sg Exhibits and Sponsorships Chairs: Dr. Samrat Ganguly, NEC Labs, samrat@nec-labs.com Dr. Javier Aracil, Universidad Publica de Navarra, Spain, javier.aracil@unavarra.es Publications Chair: Dr. Srinivasan Ramasubramanian, U. of Arizona srini@ece.arizona.edu Local Arrangements Co-Chairs: Dr. Subhankar Dhar, San Jose State University, dhar_s@cob.sjsu.edu Dr. Sukesh Pai, Microsoft, sukeshp@microsoft.com Publicity Co-Chairs: Dr. Tim Ozugur, Alcatel USA, tim.ozugur@alcatel.com Dr. Gaoxi Xiao, Nanyang Technological Univ. Singapore, egxxiao@ntu.edu.sg Dr. Marcos Rogerio Salvador, CPqD Telecom & IT Solutions, marcosrs@cpqd.com.br Steering Committee Co-Chairs: Dr. Imrich Chlamtac, UT Dallas, chlamtac@utdallas.edu Dr. Krishna Sivalingam, University of Maryland, Baltimore County, krishna@umbc.edu -------------------------------------------------------------------------- -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Mon Mar 22 19:01:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05101 for ; Mon, 22 Mar 2004 19:01:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5ZLj-0006C3-80 for mip4-archive@odin.ietf.org; Mon, 22 Mar 2004 19:00:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2N00tSB023807 for mip4-archive@odin.ietf.org; Mon, 22 Mar 2004 19:00:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5ZLj-0006Bu-2p for mip4-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 19:00:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05067 for ; Mon, 22 Mar 2004 19:00:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5ZLf-0003AD-00 for mip4-web-archive@ietf.org; Mon, 22 Mar 2004 19:00:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5ZKh-00033v-00 for mip4-web-archive@ietf.org; Mon, 22 Mar 2004 18:59:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5ZJr-0002ye-00 for mip4-web-archive@ietf.org; Mon, 22 Mar 2004 18:58:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5ZJs-00061G-IJ; Mon, 22 Mar 2004 18:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5ZJh-00060n-5F for mip4@optimus.ietf.org; Mon, 22 Mar 2004 18:58:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04977 for ; Mon, 22 Mar 2004 18:58:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5ZJd-0002wg-00 for mip4@ietf.org; Mon, 22 Mar 2004 18:58:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5ZIg-0002qo-00 for mip4@ietf.org; Mon, 22 Mar 2004 18:57:47 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B5ZHr-0002fx-00 for mip4@ietf.org; Mon, 22 Mar 2004 18:56:55 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 22 Mar 2004 16:02:16 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i2MNuJaD002347; Mon, 22 Mar 2004 15:56:20 -0800 (PST) Received: from kleung-w2k01.cisco.com (cdechaux-w2k.cisco.com [128.107.163.105]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ARJ94363; Mon, 22 Mar 2004 15:56:18 -0800 (PST) Message-Id: <4.3.2.7.2.20040322155116.028f4638@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 22 Mar 2004 15:56:18 -0800 To: Pete McCann From: Kent Leung Subject: RE: [Mip4] [issue44] RFC 3344 - Source Address of the RRQ & FHAE issues Cc: "O'Neill Alan" , In-Reply-To: <16479.27017.343035.61958@gargle.gargle.HOWL> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.3 required=5.0 tests=AWL,NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 Hi Pete. We can put together a draft on Mobility Agent Identifier extension for SAs to guard against NAT traversal, if that's OK with everyone. I agree that 3344bis doesn't need the RFC 3519-related change. Kent At 04:32 PM 3/22/2004 -0600, Pete McCann wrote: >Hi, > >[sorry about my long absence from the thread; was traveling all last > week] > >Kent, I think your response last week convinced me that ignoring the R >bit is not a good idea, and I agree that the HA should check the FHAE, >if it is present, and discard the message if it doesn't check. > >It also seems like the cleanest solution to the NAT traversal problem >is to encode the identities of the FA and HA (probably using NAI >format) in Mobile IP extensions, and to use these identities to index >security associations. There is some precedent for this in the MN-AAA >extension, when used with the MN NAI extension and all-zero IP source >address. > >I also agree with Alan that the restriction on the RRQ source IP >address made in 3519 is not ideal, and that we shouldn't require this >in the base protocol. > >However, we need to figure out how to get from where we are now to the >ideal case. It sounds like there were different opinions on whether a >NAT traversal fix of some sort (new extension) should go into the base >protocol or into a new document. > >I tend to come out on the side of a new document, and to let the >sleeping dog (NAT traversal) lie for now with the current >IP-address-indexed SAs and the band-aid solution given in 3519. This >is based on a desire to get 3344 done without too many fundamental >changes, although I am not sure that even now we can go directly to >Draft Standard with the changes we have made so far. It is also based >on my own old-fashioned bias that IP protocols shouldn't have to take >NATs into account during their design; rather, it should be the other >way around. > >If someone wants to put together a new document on Mobility Agent >Identifier extensions I think that would be a good idea. In that >document, we could make changes to the way that SAs are indexed in a >way that is robust against all forms of NAT. > >Does anyone feel really strongly that we need to make this change now >in the 3344bis document? > >-Pete -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Wed Mar 24 21:08:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07058 for ; Wed, 24 Mar 2004 21:08:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6KHT-0001Yn-QQ for mip4-archive@odin.ietf.org; Wed, 24 Mar 2004 21:07:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2P27d94005995 for mip4-archive@odin.ietf.org; Wed, 24 Mar 2004 21:07:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6KHT-0001Yc-H8 for mip4-web-archive@optimus.ietf.org; Wed, 24 Mar 2004 21:07:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07044 for ; Wed, 24 Mar 2004 21:07:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6KHR-00002J-00 for mip4-web-archive@ietf.org; Wed, 24 Mar 2004 21:07:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6KGW-0007mY-00 for mip4-web-archive@ietf.org; Wed, 24 Mar 2004 21:06:41 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6KFs-0007im-00 for mip4-web-archive@ietf.org; Wed, 24 Mar 2004 21:06:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6KFu-0001L6-0i; Wed, 24 Mar 2004 21:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6KFc-0001K1-Te for mip4@optimus.ietf.org; Wed, 24 Mar 2004 21:05:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06969 for ; Wed, 24 Mar 2004 21:05:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6KFa-0007hm-00 for mip4@ietf.org; Wed, 24 Mar 2004 21:05:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6KEd-0007eJ-00 for mip4@ietf.org; Wed, 24 Mar 2004 21:04:43 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B6KE6-0007Xk-00 for mip4@ietf.org; Wed, 24 Mar 2004 21:04:10 -0500 content-class: urn:content-classes:message Subject: [Mip4] RFC3344biz Dynamic HoA bug ? Date: Wed, 24 Mar 2004 21:03:26 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [Mip4] RFC3344biz Dynamic HoA bug ? Thread-Index: AcQP79+HaVjzgs9HRYyVMYW8jgxlZgCFRVGQ From: "O'Neill Alan" To: Content-Transfer-Encoding: quoted-printable Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Wg, I think I may have discovered a hole / corner case in RFC3344biz, but I thought a bit of discussion might be beneficial before putting it into = the tracker. A MN places 0.0.0.0 into the Home Address field of the RREQ to trigger assignment by the Home Agent. The address allocation lifetime is assumed = to be the MIP binding lifetime because no other information exists, and permanent allocations are of course not good. However, what then happens = when the MN returns home ? The MN cancels the binding, and according to the spec ceases to use MIP signaling. However, if the address lifetime is tied to the binding = lifetime then the MN just lost its address. I assume this might not have been = spotted before because we are mostly focusing on cellular systems where the MN = has a virtual home network, and hence cannot ever get home, but given the = scope of RFC3344 this 'hole', if people concur, needs to be filled. The following options spring to mind. a) We define a Home Address Lease Grant (HALG) Extension which is = optionally returned by the HA in addition to the binding lifetime. The extension specifies an allocation lifetime that is greater than the binding = lifetime (clearly cannot be less, and there is no point using it, if it is = equal). A MN that returns home is then able to cancel its binding, but can = maintain the use of the home address to avoid session disruption. Specifically, one = can imagine the HA adding this extension during that deregistration. Note = also that this separation of binding lifetime from address allocation = lifetime also enables a MN to terminate MIP bindings in a foreign network (ie for efficiency) yet still maintain the home address at the HA, so that it = can later restart MIP with the same HoA and HA. b) We might also want to consider defining a Home Address Lease Request (HALR) Extension, with the MN requesting a lease-time and the HA = reducing it to an acceptable value, with lease termination being signaled by = requesting a zero lease-time (by analogy with binding lifetime processing). c) The MN could then continue to use MIP to refresh this home address = lease by periodically resending RREQs with binding CoA=3DHoA and lifetime=3D0, = such that the HA can then return a new lease. Alternatively, the MN can = report, and then maintain, the home address via DHCP (assuming some HA/DHCP = back-end link), with these two options (and maybe others) being distinguished by = flags in the HALG. Now in terms of RFC3344biz progression, as a first alternative we could minimally add clarification text that states that a MN that has = been dynamically assigned a Home Address via MIP, will explicitly lose that address when it deregisters. This means that deregistered MNs that = return home cannot maintain sessions, and must then go to DHCP (or whatever) to = get a new address for local connectivity. Whilst non-ideal technically, it = at least lets RFC3344biz progress with clarity. We could then define HALG, = HALR and associated processing in a new document.=20 The second alternative is to remove dynamic home address allocation from RFC3344biz, and put that into the new doc along with the HALG and = HALR work, so that RFC3344biz does not go forward with the corner case of returning home. The third option is to wrap the HALG, and minimal associated processing, into RFC3344biz to support the MN returning home, and hence = to fix the corner case. The HALR can then be left to the new doc.=20 The fourth option is of course that I am mistaken about the corner case and we can all sleep soundly. Thoughts ? Alan -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Thu Mar 25 02:28:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06657 for ; Thu, 25 Mar 2004 02:28:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6PHh-000496-Mx for mip4-archive@odin.ietf.org; Thu, 25 Mar 2004 02:28:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2P7SDcQ015931 for mip4-archive@odin.ietf.org; Thu, 25 Mar 2004 02:28:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6PHg-00048s-2u for mip4-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 02:28:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06541 for ; Thu, 25 Mar 2004 02:28:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6PHc-00073C-00 for mip4-web-archive@ietf.org; Thu, 25 Mar 2004 02:28:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6PFK-0006ZG-00 for mip4-web-archive@ietf.org; Thu, 25 Mar 2004 02:25:49 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B6PCh-0005yM-00 for mip4-web-archive@ietf.org; Thu, 25 Mar 2004 02:23:03 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B6PCi-00070K-J5 for mip4-web-archive@ietf.org; Thu, 25 Mar 2004 02:23:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6PCg-00025v-Em; Thu, 25 Mar 2004 02:23:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6PCc-00024G-DO for mip4@optimus.ietf.org; Thu, 25 Mar 2004 02:22:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05679 for ; Thu, 25 Mar 2004 02:22:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6PCY-0005wP-00 for mip4@ietf.org; Thu, 25 Mar 2004 02:22:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6PAf-0005Vy-00 for mip4@ietf.org; Thu, 25 Mar 2004 02:20:58 -0500 Received: from fep01-0.kolumbus.fi ([193.229.0.41] helo=fep01-app.kolumbus.fi) by ietf-mx with esmtp (Exim 4.12) id 1B6P8y-000577-00 for mip4@ietf.org; Thu, 25 Mar 2004 02:19:12 -0500 Received: from yin.bjorns.net ([212.246.227.197]) by fep01-app.kolumbus.fi with ESMTP id <20040325071912.DHRO4029.fep01-app.kolumbus.fi@yin.bjorns.net>; Thu, 25 Mar 2004 09:19:12 +0200 Received: from bjorn by yin.bjorns.net with local (Exim 3.35 #1 (Debian)) id 1B6P9W-000568-00; Thu, 25 Mar 2004 09:19:46 +0200 Date: Thu, 25 Mar 2004 09:19:46 +0200 From: Bjorn Andersson To: "O'Neill Alan" Cc: mip4@ietf.org Subject: Re: [Mip4] RFC3344biz Dynamic HoA bug ? Message-ID: <20040325071946.GA19418@yin.bjorns.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Wed, Mar 24 2004, at 21:03:26 -0500, O'Neill Alan wrote: > A MN places 0.0.0.0 into the Home Address field of the RREQ to trigger > assignment by the Home Agent. The address allocation lifetime is assumed to > be the MIP binding lifetime because no other information exists, and > permanent allocations are of course not good. However, what then happens when > the MN returns home ? This has been discussed before on this list and I think that this is really a problem that we should solve before we have n proprietery solutions. Good that you brought up the discussion again! There have been at least two drafts that have been addressing this problem. Without any further digging I found these: - draft-glass-mobileip-agent-dhcp-proxy - draft-thuel-mobileip-tt > The MN cancels the binding, and according to the spec ceases to use MIP > signaling. However, if the address lifetime is tied to the binding lifetime > then the MN just lost its address. I assume this might not have been spotted > before because we are mostly focusing on cellular systems where the MN has a > virtual home network, and hence cannot ever get home, but given the scope of > RFC3344 this 'hole', if people concur, needs to be filled. The following > options spring to mind. I have been focusing on non-cellular systems for a number of years and come across this problem several times in real deployment scenarios. So far this can only be solved with proprietery solutions and I really support standardizing a solution. Something along the lines with your proposed HALG/HALR sounds reasonable. I think this is the way to go. Bjorn -- Bjorn Andersson PGP id 5AFC144B -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Thu Mar 25 05:19:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13085 for ; Thu, 25 Mar 2004 05:19:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Rww-0008Hd-4Y for mip4-archive@odin.ietf.org; Thu, 25 Mar 2004 05:18:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PAIwwi031835 for mip4-archive@odin.ietf.org; Thu, 25 Mar 2004 05:18:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Rwv-0008HO-Pz for mip4-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 05:18:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12802 for ; Thu, 25 Mar 2004 05:18:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Rws-0006iG-00 for mip4-web-archive@ietf.org; Thu, 25 Mar 2004 05:18:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Ruo-0006Bh-00 for mip4-web-archive@ietf.org; Thu, 25 Mar 2004 05:16:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6RtM-0005wi-02 for mip4-web-archive@ietf.org; Thu, 25 Mar 2004 05:15:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Rgy-00060w-SH; Thu, 25 Mar 2004 05:02:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Quu-0003BH-JY for mip4@optimus.ietf.org; Thu, 25 Mar 2004 04:12:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10170 for ; Thu, 25 Mar 2004 04:12:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Qur-00003r-00 for mip4@ietf.org; Thu, 25 Mar 2004 04:12:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Qtu-0007nX-00 for mip4@ietf.org; Thu, 25 Mar 2004 04:11:46 -0500 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx with esmtp (Exim 4.12) id 1B6QtV-0007kA-00 for mip4@ietf.org; Thu, 25 Mar 2004 04:11:21 -0500 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 25 Mar 2004 10:11:19 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE : [Mip4] RFC3344biz Dynamic HoA bug ? Date: Thu, 25 Mar 2004 10:11:18 +0100 Message-ID: Thread-Topic: [Mip4] RFC3344biz Dynamic HoA bug ? Thread-Index: AcQP79+HaVjzgs9HRYyVMYW8jgxlZgCFRVGQABBu8bA= From: "KASSI-LAHLOU Mohammed FTRD/DMI/CAE" To: "O'Neill Alan" , X-OriginalArrivalTime: 25 Mar 2004 09:11:19.0256 (UTC) FILETIME=[226AE580:01C41249] Content-Transfer-Encoding: quoted-printable Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, How about if the MN deregisters by sending RREQs with binding CoA=3DHoA = and lifetime not 0 (=3D binding lifetime)? Kassi -----Message d'origine----- De : mip4-admin@ietf.org [mailto:mip4-admin@ietf.org] De la part de = O'Neill Alan Envoy=E9 : jeudi 25 mars 2004 03:03 =C0 : mip4@ietf.org Objet : [Mip4] RFC3344biz Dynamic HoA bug ? Wg, I think I may have discovered a hole / corner case in RFC3344biz, but I = thought a bit of discussion might be beneficial before putting it into = the tracker. A MN places 0.0.0.0 into the Home Address field of the RREQ to trigger = assignment by the Home Agent. The address allocation lifetime is assumed = to be the MIP binding lifetime because no other information exists, and = permanent allocations are of course not good. However, what then happens = when the MN returns home ? The MN cancels the binding, and according to the spec ceases to use MIP = signaling. However, if the address lifetime is tied to the binding = lifetime then the MN just lost its address. I assume this might not have = been spotted before because we are mostly focusing on cellular systems = where the MN has a virtual home network, and hence cannot ever get home, = but given the scope of RFC3344 this 'hole', if people concur, needs to = be filled. The following options spring to mind. a) We define a Home Address Lease Grant (HALG) Extension which is = optionally returned by the HA in addition to the binding lifetime. The = extension specifies an allocation lifetime that is greater than the = binding lifetime (clearly cannot be less, and there is no point using = it, if it is equal). A MN that returns home is then able to cancel its = binding, but can maintain the use of the home address to avoid session = disruption. Specifically, one can imagine the HA adding this extension = during that deregistration. Note also that this separation of binding = lifetime from address allocation lifetime also enables a MN to terminate = MIP bindings in a foreign network (ie for efficiency) yet still maintain the home address at the HA, so that it = can later restart MIP with the same HoA and HA. b) We might also want to consider defining a Home Address Lease Request (HALR) Extension, with the MN requesting a lease-time and the HA = reducing it to an acceptable value, with lease termination being = signaled by requesting a zero lease-time (by analogy with binding = lifetime processing). c) The MN could then continue to use MIP to refresh this home address = lease by periodically resending RREQs with binding CoA=3DHoA and = lifetime=3D0, such that the HA can then return a new lease. = Alternatively, the MN can report, and then maintain, the home address = via DHCP (assuming some HA/DHCP back-end link), with these two options = (and maybe others) being distinguished by flags in the HALG. Now in terms of RFC3344biz progression, as a first alternative we could = minimally add clarification text that states that a MN that has been = dynamically assigned a Home Address via MIP, will explicitly lose that = address when it deregisters. This means that deregistered MNs that = return home cannot maintain sessions, and must then go to DHCP (or = whatever) to get a new address for local connectivity. Whilst non-ideal = technically, it at least lets RFC3344biz progress with clarity. We could = then define HALG, HALR and associated processing in a new document.=20 The second alternative is to remove dynamic home address allocation = from RFC3344biz, and put that into the new doc along with the HALG and = HALR work, so that RFC3344biz does not go forward with the corner case = of returning home. The third option is to wrap the HALG, and minimal associated = processing, into RFC3344biz to support the MN returning home, and hence = to fix the corner case. The HALR can then be left to the new doc.=20 The fourth option is of course that I am mistaken about the corner case = and we can all sleep soundly. Thoughts ? Alan --=20 Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Thu Mar 25 09:11:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21995 for ; Thu, 25 Mar 2004 09:11:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VZG-0007YX-V7 for mip4-archive@odin.ietf.org; Thu, 25 Mar 2004 09:10:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PEAkV7029035 for mip4-archive@odin.ietf.org; Thu, 25 Mar 2004 09:10:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VZG-0007YE-PH for mip4-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 09:10:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21797 for ; Thu, 25 Mar 2004 09:10:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6VZF-0006MI-00 for mip4-web-archive@ietf.org; Thu, 25 Mar 2004 09:10:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6VXv-00067T-00 for mip4-web-archive@ietf.org; Thu, 25 Mar 2004 09:09:24 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6VXH-0005xj-00 for mip4-web-archive@ietf.org; Thu, 25 Mar 2004 09:08:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VXI-0006Qb-NH; Thu, 25 Mar 2004 09:08:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6SO8-0001MV-8N for mip4@optimus.ietf.org; Thu, 25 Mar 2004 05:47:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14274 for ; Thu, 25 Mar 2004 05:47:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6SO4-0001oF-00 for mip4@ietf.org; Thu, 25 Mar 2004 05:47:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6SN3-0001ii-00 for mip4@ietf.org; Thu, 25 Mar 2004 05:45:58 -0500 Received: from fep21-0.kolumbus.fi ([193.229.0.48] helo=fep21-app.kolumbus.fi) by ietf-mx with esmtp (Exim 4.12) id 1B6SMP-0001dm-00 for mip4@ietf.org; Thu, 25 Mar 2004 05:45:17 -0500 Received: from yin.bjorns.net ([212.246.227.197]) by fep21-app.kolumbus.fi with ESMTP id <20040325104518.OXDF19565.fep21-app.kolumbus.fi@yin.bjorns.net> for ; Thu, 25 Mar 2004 12:45:18 +0200 Received: from bjorn by yin.bjorns.net with local (Exim 3.35 #1 (Debian)) id 1B6SMy-0005Tk-00 for ; Thu, 25 Mar 2004 12:45:52 +0200 Date: Thu, 25 Mar 2004 12:45:52 +0200 From: Bjorn Andersson To: mip4@ietf.org Subject: Re: RE : [Mip4] RFC3344biz Dynamic HoA bug ? Message-ID: <20040325104552.GA20407@yin.bjorns.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Thu, Mar 25 2004, at 10:11:18 +0100, KASSI-LAHLOU Mohammed FTRD/DMI/CAE wrote: > How about if the MN deregisters by sending RREQs with binding > CoA=HoA and lifetime not 0 (= binding lifetime)? I think this would be a good solution but it would break backwards compatibility. This may be an issue for some. Bjorn -- Bjorn Andersson PGP id 5AFC144B -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Thu Mar 25 12:42:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10173 for ; Thu, 25 Mar 2004 12:42:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Ys9-0000vY-8V for mip4-archive@odin.ietf.org; Thu, 25 Mar 2004 12:42:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PHgT9r003560 for mip4-archive@odin.ietf.org; Thu, 25 Mar 2004 12:42:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Ys9-0000vL-3P for mip4-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 12:42:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10107 for ; Thu, 25 Mar 2004 12:42:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Ys7-0003DV-00 for mip4-web-archive@ietf.org; Thu, 25 Mar 2004 12:42:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6YrB-00038M-00 for mip4-web-archive@ietf.org; Thu, 25 Mar 2004 12:41:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6YqH-00034S-00 for mip4-web-archive@ietf.org; Thu, 25 Mar 2004 12:40:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6YqH-0000ox-Mu; Thu, 25 Mar 2004 12:40:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6YpG-0000d9-Qj for mip4@optimus.ietf.org; Thu, 25 Mar 2004 12:39:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09928 for ; Thu, 25 Mar 2004 12:39:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6YpF-00030T-00 for mip4@ietf.org; Thu, 25 Mar 2004 12:39:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6YoS-0002xj-00 for mip4@ietf.org; Thu, 25 Mar 2004 12:38:41 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B6Yno-0002sk-00 for mip4@ietf.org; Thu, 25 Mar 2004 12:38:00 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 25 Mar 2004 09:42:47 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i2PHbSGX015252; Thu, 25 Mar 2004 09:37:28 -0800 (PST) Received: from kleung-w2k01.cisco.com (sjc-vpn1-464.cisco.com [10.21.97.208]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ARM33686; Thu, 25 Mar 2004 09:37:27 -0800 (PST) Message-Id: <4.3.2.7.2.20040325092153.03274220@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 25 Mar 2004 09:37:27 -0800 To: Bjorn Andersson From: Kent Leung Subject: Re: [Mip4] RFC3344biz Dynamic HoA bug ? Cc: "O'Neill Alan" , mip4@ietf.org In-Reply-To: <20040325071946.GA19418@yin.bjorns.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL autolearn=no version=2.60 Yes, this is a known problem for many years. :) In addition, draft-mccann-mobileip-sessionid 's Address Management section attempted to covered this issue as well. We haven't addressed this since most SP deployments have not had the need to return to home network. And for Enterprise environment where DHCP is prevalent, Steve Glass's draft-glass-mobileip-agent-dhcp-proxy made sense. I agree with Hasse that 3344bis should just state that when MN returns home, the dynamically assigned address needs to remain associated with the MN. The details to be covered in another draft. Kent At 09:19 AM 3/25/2004 +0200, Bjorn Andersson wrote: >On Wed, Mar 24 2004, at 21:03:26 -0500, O'Neill Alan wrote: > > A MN places 0.0.0.0 into the Home Address field of the RREQ to trigger > > assignment by the Home Agent. The address allocation lifetime is assumed to > > be the MIP binding lifetime because no other information exists, and > > permanent allocations are of course not good. However, what then > happens when > > the MN returns home ? > >This has been discussed before on this list and I think that this is >really a problem that we should solve before we have n proprietery >solutions. Good that you brought up the discussion again! There >have been at least two drafts that have been addressing this >problem. Without any further digging I found these: >- draft-glass-mobileip-agent-dhcp-proxy >- draft-thuel-mobileip-tt > > > The MN cancels the binding, and according to the spec ceases to use MIP > > signaling. However, if the address lifetime is tied to the binding lifetime > > then the MN just lost its address. I assume this might not have been > spotted > > before because we are mostly focusing on cellular systems where the MN > has a > > virtual home network, and hence cannot ever get home, but given the > scope of > > RFC3344 this 'hole', if people concur, needs to be filled. The following > > options spring to mind. > >I have been focusing on non-cellular systems for a number of years and >come across this problem several times in real deployment scenarios. So >far this can only be solved with proprietery solutions and I really >support standardizing a solution. Something along the lines with your >proposed HALG/HALR sounds reasonable. I think this is the way to go. > > Bjorn > >-- >Bjorn Andersson >PGP id 5AFC144B > >-- >Mip4 mailing list: Mip4@ietf.org > Web interface: https://www.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html >Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Thu Mar 25 13:50:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13588 for ; Thu, 25 Mar 2004 13:50:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Zvw-0001Dk-UR for mip4-archive@odin.ietf.org; Thu, 25 Mar 2004 13:50:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PIoSNj004691 for mip4-archive@odin.ietf.org; Thu, 25 Mar 2004 13:50:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Zvw-0001DZ-Nf for mip4-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 13:50:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13583 for ; Thu, 25 Mar 2004 13:50:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Zvu-0007bm-00 for mip4-web-archive@ietf.org; Thu, 25 Mar 2004 13:50:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Zuz-0007ZX-00 for mip4-web-archive@ietf.org; Thu, 25 Mar 2004 13:49:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6Zu3-0007XB-00 for mip4-web-archive@ietf.org; Thu, 25 Mar 2004 13:48:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Zu4-00012r-M0; Thu, 25 Mar 2004 13:48:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Zs4-0000gH-Hd for mip4@optimus.ietf.org; Thu, 25 Mar 2004 13:46:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13398 for ; Thu, 25 Mar 2004 13:46:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Zs1-0007Q5-00 for mip4@ietf.org; Thu, 25 Mar 2004 13:46:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Zr9-0007NN-00 for mip4@ietf.org; Thu, 25 Mar 2004 13:45:32 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1B6ZqD-0007IL-00 for mip4@ietf.org; Thu, 25 Mar 2004 13:44:33 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i2PIhxu28395; Thu, 25 Mar 2004 10:43:59 -0800 X-mProtect: <200403251843> Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd1SaLyF; Thu, 25 Mar 2004 10:43:57 PST Message-ID: <40632863.A3359AE4@iprg.nokia.com> Date: Thu, 25 Mar 2004 10:43:47 -0800 From: "Charles E.Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "O'Neill Alan" CC: mip4@ietf.org Subject: Re: [Mip4] RFC3344biz Dynamic HoA bug ? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello folks, Honestly, I do not think there is a specification issue here for rfc3344bis. O'Neill Alan wrote: > The MN cancels the binding, and according to the spec ceases to use MIP > signaling. Check. This is fine. > However, if the address lifetime is tied to the binding lifetime > then the MN just lost its address. No, by Mobile IP protocol signaling, the mobile node lost its care-of address. The lifetime for the home address should _never_ be tied to the lifetime of its binding to the care-of address, and no Mobile IP standards track document ever made any such correspondence. If the address allocation makes the correspondence, without additional protocol (not Mobile IP), then the address allocation system has a bug. > a) We define a Home Address Lease Grant (HALG) Extension which is optionally > returned by the HA in addition to the binding lifetime. ....... > b) We might also want to consider defining a Home Address Lease Request > (HALR) Extension, with the MN requesting a lease-time and the HA reducing it > to an acceptable value, with lease termination being signaled by requesting a > zero lease-time (by analogy with binding lifetime processing). I think it is a mistake to undertake these matters as part of rfc3344bis, because it essentially amounts to bundling address allocation details into Mobile IP (which is not an address allocation protocol). There are too many details, and it is appropriate to do this as a separate task which can normatively reference the finalized rfc3344bis document. > The second alternative is to remove dynamic home address allocation > from RFC3344biz, and put that into the new doc along with the HALG and HALR > work, so that RFC3344biz does not go forward with the corner case of > returning home. As mentioned above, this "corner case" results from a bug in a program not directly related to Mobile IP, and so I think it is not needed to change the existing rfc3344bis (<--- note, not 'z'). Regards, Charlie P. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Thu Mar 25 14:19:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14646 for ; Thu, 25 Mar 2004 14:19:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6aO2-0004FS-QG for mip4-archive@odin.ietf.org; Thu, 25 Mar 2004 14:19:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PJJUtR016330 for mip4-archive@odin.ietf.org; Thu, 25 Mar 2004 14:19:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6aO2-0004FJ-LV for mip4-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 14:19:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14632 for ; Thu, 25 Mar 2004 14:19:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6aO0-0001S6-00 for mip4-web-archive@ietf.org; Thu, 25 Mar 2004 14:19:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6aNA-0001Pf-00 for mip4-web-archive@ietf.org; Thu, 25 Mar 2004 14:18:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6aMT-0001N1-00 for mip4-web-archive@ietf.org; Thu, 25 Mar 2004 14:17:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6aMU-00045R-RT; Thu, 25 Mar 2004 14:17:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6aLE-00041E-VO for mip4@optimus.ietf.org; Thu, 25 Mar 2004 14:16:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14503 for ; Thu, 25 Mar 2004 14:16:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6aLC-0001H7-00 for mip4@ietf.org; Thu, 25 Mar 2004 14:16:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6aKI-0001Cy-00 for mip4@ietf.org; Thu, 25 Mar 2004 14:15:39 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B6aJT-00015K-00 for mip4@ietf.org; Thu, 25 Mar 2004 14:14:47 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 25 Mar 2004 11:20:43 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i2PJEDKj020927; Thu, 25 Mar 2004 11:14:13 -0800 (PST) Received: from kleung-w2k01.cisco.com (sjc-vpn4-105.cisco.com [10.21.80.105]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ARM44496; Thu, 25 Mar 2004 11:14:12 -0800 (PST) Message-Id: <4.3.2.7.2.20040325105440.01da26f8@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 25 Mar 2004 11:14:12 -0800 To: "Charles E.Perkins" From: Kent Leung Subject: Re: [Mip4] RFC3344biz Dynamic HoA bug ? Cc: "O'Neill Alan" , mip4@ietf.org In-Reply-To: <40632863.A3359AE4@iprg.nokia.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 Hi Charlie. The issue is when a mobility binding for an MN is deleted (either lifetime expired or deregistered from foreign/home network), the HA does not have any information to know if MN still needs to maintain the HoA. Here are some cases to consider. For DHCP, as long as the MN knows about the DHCP server and client ID, it can be responsible to maintain the HoA after deregistration on home network. For cases where HA manages the HoA, such as proxy DHCP client mode, local pool, etc., the protocol used to trigger address assignment is Mobile IP. However, when the mobility binding is no longer needed (which is maintained by registrations), there's a lack of signaling to keep the HoA for MN while it's at home. This issue came with RFC 2794 when dynamic HoA started. The mobility binding and address management is coupled. The Proxy DHCP draft has some information to decouple the 2 functions but specific to DHCP. We can separate the functions provided some address management information is introduced in the signaling, which is basically what the listed drafts and Alan's proposal are based on. I agree this is not 3344bis specific problem. But I believe that Mobile IP does not address dynamically-assigned-HoA MN returning home in today's RFCs. Kent At 10:43 AM 3/25/2004 -0800, Charles E.Perkins wrote: >Hello folks, > >Honestly, I do not think there is a specification >issue here for rfc3344bis. > >O'Neill Alan wrote: > > > The MN cancels the binding, and according to the spec ceases to use MIP > > signaling. > >Check. This is fine. > > > However, if the address lifetime is tied to the binding lifetime > > then the MN just lost its address. > >No, by Mobile IP protocol signaling, the mobile node lost its >care-of address. The lifetime for the home address should >_never_ be tied to the lifetime of its binding to the care-of >address, and no Mobile IP standards track document ever made >any such correspondence. > >If the address allocation makes the correspondence, without >additional protocol (not Mobile IP), then the address allocation >system has a bug. > > > a) We define a Home Address Lease Grant (HALG) Extension which is > optionally > > returned by the HA in addition to the binding lifetime. > ....... > > b) We might also want to consider defining a Home Address Lease Request > > (HALR) Extension, with the MN requesting a lease-time and the HA > reducing it > > to an acceptable value, with lease termination being signaled by > requesting a > > zero lease-time (by analogy with binding lifetime processing). > >I think it is a mistake to undertake these matters as part >of rfc3344bis, because it essentially amounts to bundling >address allocation details into Mobile IP (which is not an >address allocation protocol). > >There are too many details, and it is appropriate to do this >as a separate task which can normatively reference the >finalized rfc3344bis document. > > > > The second alternative is to remove dynamic home address allocation > > from RFC3344biz, and put that into the new doc along with the HALG and HALR > > work, so that RFC3344biz does not go forward with the corner case of > > returning home. > >As mentioned above, this "corner case" results from a bug in a >program not directly related to Mobile IP, and so I think it is >not needed to change the existing rfc3344bis (<--- note, not 'z'). > >Regards, >Charlie P. > >-- >Mip4 mailing list: Mip4@ietf.org > Web interface: https://www.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html >Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Thu Mar 25 14:37:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15567 for ; Thu, 25 Mar 2004 14:37:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6afQ-0005p0-GO for mip4-archive@odin.ietf.org; Thu, 25 Mar 2004 14:37:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PJbSEC022377 for mip4-archive@odin.ietf.org; Thu, 25 Mar 2004 14:37:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6afQ-0005oq-9y for mip4-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 14:37:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15545 for ; Thu, 25 Mar 2004 14:37:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6afN-0002No-00 for mip4-web-archive@ietf.org; Thu, 25 Mar 2004 14:37:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6aeP-0002Kf-00 for mip4-web-archive@ietf.org; Thu, 25 Mar 2004 14:36:26 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6adW-0002Gw-00 for mip4-web-archive@ietf.org; Thu, 25 Mar 2004 14:35:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6adY-0005XP-8S; Thu, 25 Mar 2004 14:35:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6abf-0005PR-B3 for mip4@optimus.ietf.org; Thu, 25 Mar 2004 14:33:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15279 for ; Thu, 25 Mar 2004 14:33:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6abc-00029T-00 for mip4@ietf.org; Thu, 25 Mar 2004 14:33:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6aah-00026a-00 for mip4@ietf.org; Thu, 25 Mar 2004 14:32:36 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1B6aa8-00023P-00 for mip4@ietf.org; Thu, 25 Mar 2004 14:32:00 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i2PJVKv32188; Thu, 25 Mar 2004 11:31:20 -0800 X-mProtect: <200403251931> Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd9bvWu1; Thu, 25 Mar 2004 11:31:18 PST Message-ID: <4063337D.4F79B41C@iprg.nokia.com> Date: Thu, 25 Mar 2004 11:31:09 -0800 From: "Charles E.Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Kent Leung CC: mip4@ietf.org Subject: Re: [Mip4] RFC3344biz Dynamic HoA bug ? References: <4.3.2.7.2.20040325105440.01da26f8@mira-sjcm-2.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Kent, Kent Leung wrote: > The issue is when a mobility binding for an MN is deleted (either lifetime > expired or deregistered from foreign/home network), the HA does not have > any information to know if MN still needs to maintain the HoA. That information is not part of Mobile IP. If a mobile node has a home address, that address is supposed to be routable to the home network. If the mobile node has a care-of address, the home address is still routable to the home network, but the home agent acts on behalf of the mobile node to deliver the packets. The packets are still routable to the home network, one way or the other. De-registering the care-of address does not change the fact that the home address is still routable to the home network, unless there is a bug somewhere. (***) > ............ For DHCP, as long as the MN knows about > the DHCP server and client ID, it can be responsible to maintain the HoA > after deregistration on home network. For cases where HA manages the HoA, > such as proxy DHCP client mode, local pool, etc., the protocol used to trigger > address assignment is Mobile IP. How one uses the internal signaling flow related to Mobile IP is not a priori a matter that has to be worked out as part of the Mobile IP specification. For instance, when a node gets a care-of address, it might want to make some user interface changes (I don't know why!). We can't specify all of those contingencies in the Mobile IP document. > However, when the mobility binding is no > longer needed (which is maintained by registrations), there's a lack of > signaling to keep the HoA for MN while it's at home. That's not a Mobile IP problem. I refer back to my previous paragraph (***). > This issue came with RFC 2794 when dynamic HoA started. The mobility binding > and address management is coupled. The Proxy DHCP draft has some information > to decouple the 2 functions but specific to DHCP. We can separate the > functions > provided some address management information is introduced in the > signaling, which > is basically what the listed drafts and Alan's proposal are based on. It is fine for the other drafts to make proposals, and for the problem discussion to proceed. However, I hope to point out that the problem discussion has not identified a Mobile IP problem. > I agree this is not 3344bis specific problem. Thanks! > But I believe that Mobile IP does not > address dynamically-assigned-HoA MN returning home in today's RFCs. rfc3344bis does not solve all problems related to dynamic address assignment -- and specifically, not all problems related to dynamic address assignment of home addresses. There are related efforts, using AAA I believe, to work out some more of the details. As one example, if one has a dynamically allocated address, and a security engine that depends upon the value of one's IP address, then there is work needed to get the security engine started. All of these things can be neatly solved in ways that should be external to rfc3344bis. The solutions can normatively reference the result of rfc3344bis document develop. Regards, Charlie P. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Thu Mar 25 19:08:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04256 for ; Thu, 25 Mar 2004 19:08:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6esz-0008Q1-70 for mip4-archive@odin.ietf.org; Thu, 25 Mar 2004 19:07:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2Q07jGN032355 for mip4-archive@odin.ietf.org; Thu, 25 Mar 2004 19:07:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6esz-0008Pm-15 for mip4-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 19:07:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04232 for ; Thu, 25 Mar 2004 19:07:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6esv-0006OV-00 for mip4-web-archive@ietf.org; Thu, 25 Mar 2004 19:07:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6es5-0006Kj-00 for mip4-web-archive@ietf.org; Thu, 25 Mar 2004 19:06:50 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6erI-0006Gb-00 for mip4-web-archive@ietf.org; Thu, 25 Mar 2004 19:06:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6erJ-00085H-Et; Thu, 25 Mar 2004 19:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6er5-00083i-Ak for mip4@optimus.ietf.org; Thu, 25 Mar 2004 19:05:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04069 for ; Thu, 25 Mar 2004 19:05:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6er2-0006FW-00 for mip4@ietf.org; Thu, 25 Mar 2004 19:05:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6eq4-0006BP-00 for mip4@ietf.org; Thu, 25 Mar 2004 19:04:44 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B6epM-00064u-00 for mip4@ietf.org; Thu, 25 Mar 2004 19:04:00 -0500 content-class: urn:content-classes:message Subject: RE: [Mip4] RFC3344biz Dynamic HoA bug ? Date: Thu, 25 Mar 2004 19:03:16 -0500 MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [Mip4] RFC3344biz Dynamic HoA bug ? Thread-Index: AcQSoFwQIn4Mc4+EQ0+02bXOeDlPfgAIJRTA From: "O'Neill Alan" To: "Charles E.Perkins" , "Kent Leung" Cc: Content-Transfer-Encoding: quoted-printable Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Charlie, Kent, Thanks for the historical and architectural context to this. So I can buy the argument that says that this should have nothing to do = with RFC3344bis, because MIP is not an address management protocol, until I = see that RFC3344bis includes dynamic address allocation.=20 I then find the mechanisms as stated appear under specified and prone to failure on returning home because of the omission of any indication on correct behaviour or a stated allocation lifetime, and punting on such a = key point seems poor. I believe any attempt to suggest that the address has = been allocated with an indefinite lifetime is a bad road. So I would minimally expect some clarification text, and some future = protocol work to produce at least one definitive mandatory to implement solution = that to me has to be based on additional MIP extensions that minimally define address lifetime and subsequent processing on binding cancellation. = Other work could then re-document the other options that have deeper = dependencies on other wgs such as DHCP and AAA. A more surgical approach, with a lot more pints being spilled no doubt, = would be to amputate dynamic HoA and HA allocation out of RFC3344bis (because = the later requires the former), and wrap these together with the dynamic HA redirection work which also has a significant dynamic HoA dependency). = This ensures that all the pure MIP stuff (which doesn't do dynamic = allocation) is in RFC3344bis, and all the additional dynamic stuff is handled in = another place, where the various special HoA field formats and extensions can be defined together whilst preserving backwards compatibility. I am happy = to provide my own time for this but doubt it is realistic. I can also live with a concrete clarification in RFC3344bis, and/or a = minimal fix to a mechanism that some people are reporting is broken in the = field.=20 However, having said all that Charlie, you and others have spent years = on RFC3344bis and its parents, and I will be happy to defer to your = preferences with ongoing thanks for your effort. Regards, Alan. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Thu Mar 25 19:32:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05263 for ; Thu, 25 Mar 2004 19:32:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6fGA-0001TV-Qg for mip4-archive@odin.ietf.org; Thu, 25 Mar 2004 19:31:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2Q0VgP9005665 for mip4-archive@odin.ietf.org; Thu, 25 Mar 2004 19:31:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6fGA-0001TI-MA for mip4-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 19:31:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05250 for ; Thu, 25 Mar 2004 19:31:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6fG8-0000GV-00 for mip4-web-archive@ietf.org; Thu, 25 Mar 2004 19:31:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6fFO-0000Cm-00 for mip4-web-archive@ietf.org; Thu, 25 Mar 2004 19:30:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6fEW-00007S-00 for mip4-web-archive@ietf.org; Thu, 25 Mar 2004 19:30:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6fEX-0001J5-15; Thu, 25 Mar 2004 19:30:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6fDn-0001HB-D0 for mip4@optimus.ietf.org; Thu, 25 Mar 2004 19:29:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05117 for ; Thu, 25 Mar 2004 19:29:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6fDl-000013-00 for mip4@ietf.org; Thu, 25 Mar 2004 19:29:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6fD0-0007hH-00 for mip4@ietf.org; Thu, 25 Mar 2004 19:28:27 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B6fBp-0007Ph-00 for mip4@ietf.org; Thu, 25 Mar 2004 19:27:13 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 25 Mar 2004 16:33:13 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i2Q0QgGX026016; Thu, 25 Mar 2004 16:26:42 -0800 (PST) Received: from kleung-w2k01.cisco.com ([128.107.176.232]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ARM77380; Thu, 25 Mar 2004 16:26:41 -0800 (PST) Message-Id: <4.3.2.7.2.20040325161322.02984470@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 25 Mar 2004 16:26:40 -0800 To: "Charles E.Perkins" From: Kent Leung Subject: Re: [Mip4] RFC3344biz Dynamic HoA bug ? Cc: mip4@ietf.org In-Reply-To: <4063337D.4F79B41C@iprg.nokia.com> References: <4.3.2.7.2.20040325105440.01da26f8@mira-sjcm-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL autolearn=no version=2.60 Hi Charlie. The home address is still routable to the home network. That is not the problem. It's _who_ is actually receiving the packet, as the home address may be relinquished and assigned to another MN. It's not typical that the home address is assigned to the same MN infinitely. I think we're in agreement that 3344bis does not solve dynamic home address assignment. The solution should be addressed in other RFCs. But what started this thread was reference in 3344bis on dynamic home address assignment and that returning home is a gap (as I said in RFC 2794). I assume this text is the culprit? > If the mobile node is not configured with a home address, it MAY use > the Mobile Node NAI extension [6] to identify itself, and set the > Home Address field of the Registration Request to 0.0.0.0. In this > case, the mobile node MUST be able to assign its home address after > extracting this information from the Registration Reply from the home > agent. Kent At 11:31 AM 3/25/2004 -0800, Charles E.Perkins wrote: >Hello Kent, > >Kent Leung wrote: > > > The issue is when a mobility binding for an MN is deleted (either lifetime > > expired or deregistered from foreign/home network), the HA does not have > > any information to know if MN still needs to maintain the HoA. > >That information is not part of Mobile IP. If a mobile node has >a home address, that address is supposed to be routable to the home >network. If the mobile node has a care-of address, the home >address is still routable to the home network, but the home agent >acts on behalf of the mobile node to deliver the packets. The >packets are still routable to the home network, one way or the >other. De-registering the care-of address does not change the >fact that the home address is still routable to the home network, >unless there is a bug somewhere. (***) > > > ............ For DHCP, as long as the MN knows about > > the DHCP server and client ID, it can be responsible to maintain the HoA > > after deregistration on home network. For cases where HA manages the HoA, > > such as proxy DHCP client mode, local pool, etc., the protocol used to > trigger > > address assignment is Mobile IP. > >How one uses the internal signaling flow related to Mobile IP >is not a priori a matter that has to be worked out as part >of the Mobile IP specification. For instance, when a node >gets a care-of address, it might want to make some user >interface changes (I don't know why!). We can't specify >all of those contingencies in the Mobile IP document. > > > However, when the mobility binding is no > > longer needed (which is maintained by registrations), there's a lack of > > signaling to keep the HoA for MN while it's at home. > >That's not a Mobile IP problem. I refer back to my previous >paragraph (***). > > > This issue came with RFC 2794 when dynamic HoA started. The mobility > binding > > and address management is coupled. The Proxy DHCP draft has some > information > > to decouple the 2 functions but specific to DHCP. We can separate the > > functions > > provided some address management information is introduced in the > > signaling, which > > is basically what the listed drafts and Alan's proposal are based on. > >It is fine for the other drafts to make proposals, and for the >problem discussion to proceed. However, I hope to point out that >the problem discussion has not identified a Mobile IP problem. > > > I agree this is not 3344bis specific problem. > >Thanks! > > > But I believe that Mobile IP does not > > address dynamically-assigned-HoA MN returning home in today's RFCs. > >rfc3344bis does not solve all problems related to dynamic >address assignment -- and specifically, not all problems >related to dynamic address assignment of home addresses. > >There are related efforts, using AAA I believe, to work >out some more of the details. As one example, if one has >a dynamically allocated address, and a security engine >that depends upon the value of one's IP address, then >there is work needed to get the security engine started. > >All of these things can be neatly solved in ways that should >be external to rfc3344bis. The solutions can normatively >reference the result of rfc3344bis document develop. > >Regards, >Charlie P. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Thu Mar 25 19:44:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05857 for ; Thu, 25 Mar 2004 19:44:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6fRl-0002fh-ST for mip4-archive@odin.ietf.org; Thu, 25 Mar 2004 19:43:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2Q0hf4q010264 for mip4-archive@odin.ietf.org; Thu, 25 Mar 2004 19:43:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6fRl-0002fQ-Nz for mip4-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 19:43:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05847 for ; Thu, 25 Mar 2004 19:43:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6fRk-0001Bn-00 for mip4-web-archive@ietf.org; Thu, 25 Mar 2004 19:43:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6fQo-00018v-00 for mip4-web-archive@ietf.org; Thu, 25 Mar 2004 19:42:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6fQ8-00015y-00 for mip4-web-archive@ietf.org; Thu, 25 Mar 2004 19:42:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6fQ8-0002SF-Qn; Thu, 25 Mar 2004 19:42:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6fPh-0002Rm-Ko for mip4@optimus.ietf.org; Thu, 25 Mar 2004 19:41:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05777 for ; Thu, 25 Mar 2004 19:41:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6fPf-00013y-00 for mip4@ietf.org; Thu, 25 Mar 2004 19:41:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6fOi-0000zn-00 for mip4@ietf.org; Thu, 25 Mar 2004 19:40:33 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1B6fNn-0000sB-00 for mip4@ietf.org; Thu, 25 Mar 2004 19:39:35 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i2Q0cuN23040; Thu, 25 Mar 2004 16:38:56 -0800 X-mProtect: <200403260038> Nokia Silicon Valley Messaging Protection Received: from esnira-pool4015237.nokia.com (10.162.15.237, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdOs1qEk; Thu, 25 Mar 2004 16:38:51 PST Message-ID: <40637B8C.7070805@iprg.nokia.com> Date: Thu, 25 Mar 2004 16:38:36 -0800 From: "Charles E. Perkins" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kent Leung CC: mip4@ietf.org Subject: Re: [Mip4] RFC3344biz Dynamic HoA bug ? References: <4.3.2.7.2.20040325105440.01da26f8@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040325161322.02984470@mira-sjcm-2.cisco.com> In-Reply-To: <4.3.2.7.2.20040325161322.02984470@mira-sjcm-2.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Kent, Kent Leung wrote: > > Hi Charlie. The home address is still routable to the home network. > That > is not the problem. Check. > It's _who_ is actually receiving the packet, as the home > address may be relinquished and assigned to another MN. It's not typical > that the home address is assigned to the same MN infinitely. But, it's not prohibited either, and if additional support mechanisms are needed for the dynamic case, they can be specified in another document. In fact, I reckon there will be more than one way in use, so there will be multiple documents. > I think we're in agreement that 3344bis does not solve dynamic home > address assignment. The solution should be addressed in other RFCs. > But what started this thread was reference in 3344bis on dynamic > home address assignment and that returning home is a gap (as I > said in RFC 2794). My participation came in response to a suggestion that the extra specification should be put into rfc3344bis. If that doesn't happen, then I am much happier. > I assume this text is the culprit? > >> If the mobile node is not configured with a home address, it MAY use >> the Mobile Node NAI extension [6] to identify itself, and set the >> Home Address field of the Registration Request to 0.0.0.0. In this >> case, the mobile node MUST be able to assign its home address after >> extracting this information from the Registration Reply from the home >> agent. > This doesn't necessarily imply anything about dynamic allocation, and it doesn't imply that the address has a lifetime. Regards, Charlie P. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Thu Mar 25 21:07:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08922 for ; Thu, 25 Mar 2004 21:07:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6gk7-0007vh-Li for mip4-archive@odin.ietf.org; Thu, 25 Mar 2004 21:06:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2Q26hBj030475 for mip4-archive@odin.ietf.org; Thu, 25 Mar 2004 21:06:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6gk7-0007vS-Gd for mip4-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 21:06:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08918 for ; Thu, 25 Mar 2004 21:06:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6gk5-0006jN-00 for mip4-web-archive@ietf.org; Thu, 25 Mar 2004 21:06:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6gjD-0006gW-00 for mip4-web-archive@ietf.org; Thu, 25 Mar 2004 21:05:48 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6giT-0006dB-00 for mip4-web-archive@ietf.org; Thu, 25 Mar 2004 21:05:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6giU-0007mP-Ak; Thu, 25 Mar 2004 21:05:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6giG-0007ld-M9 for mip4@optimus.ietf.org; Thu, 25 Mar 2004 21:04:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08848 for ; Thu, 25 Mar 2004 21:04:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6giE-0006cX-00 for mip4@ietf.org; Thu, 25 Mar 2004 21:04:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6ghK-0006Yv-00 for mip4@ietf.org; Thu, 25 Mar 2004 21:03:50 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1B6ggu-0006Ue-00 for mip4@ietf.org; Thu, 25 Mar 2004 21:03:24 -0500 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i2Q22qGX016938; Thu, 25 Mar 2004 18:02:52 -0800 (PST) Received: from kleung-w2k01.cisco.com (sjc-vpn4-212.cisco.com [10.21.80.212]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ARM85680; Thu, 25 Mar 2004 18:02:50 -0800 (PST) Message-Id: <4.3.2.7.2.20040325171551.029a7388@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 25 Mar 2004 18:02:50 -0800 To: "Charles E. Perkins" From: Kent Leung Subject: Re: [Mip4] RFC3344biz Dynamic HoA bug ? Cc: mip4@ietf.org In-Reply-To: <40637B8C.7070805@iprg.nokia.com> References: <4.3.2.7.2.20040325161322.02984470@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040325105440.01da26f8@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040325161322.02984470@mira-sjcm-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 Hi Charlie. At 04:38 PM 3/25/2004 -0800, Charles E. Perkins wrote: >> It's _who_ is actually receiving the packet, as the home >>address may be relinquished and assigned to another MN. It's not typical >>that the home address is assigned to the same MN infinitely. > >But, it's not prohibited either, and if additional support mechanisms >are needed for the dynamic case, they can be specified in another >document. In fact, I reckon there will be more than one way in >use, so there will be multiple documents. It's not, but the problem arises when lifetime of HoA is not infinite, which is a common case. We cannot assume that HoA is always associated with particular MN. So we're in agreement that there is an outstanding issue with dynamic HoA in regards to returning home? And that can be solved by new drafts or revised old drafts? My point has been that it doesn't matter which type of address management scheme is used, we need some more information in Mobile IP protocol to allow MN to communicate how it wants to maintain the HoA when at home. Mobile IP lacks this today. >My participation came in response to a suggestion that the extra >specification should be put into rfc3344bis. If that doesn't happen, >then I am much happier. Now looking at RFC 3344, I see only minor reference to dynamic home address assignment. Since spec does not describe how this is accomplished, I don't see value in documenting any flaws or gaps of a scheme covered elsewhere. Maybe it may have been better if base protocol spec did not contain any dynamic home address assignment reference and let that be completely covered in other specifications? Purely MHO. Anyways, given the text today, I would vote for no additional text in 3344bis. Just one vote though. :) The reason is that we would be clarifying an issue that's actually in RFC 2794, not specific to RFC 3344. >>> If the mobile node is not configured with a home address, it MAY use >>> the Mobile Node NAI extension [6] to identify itself, and set the >>> Home Address field of the Registration Request to 0.0.0.0. In this >>> case, the mobile node MUST be able to assign its home address after >>> extracting this information from the Registration Reply from the home >>> agent. >This doesn't necessarily imply anything about dynamic allocation, >and it doesn't imply that the address has a lifetime. I read it as a mechanism to be assigned a home address dynamically. I was just pointing out that there are references to dynamic HoA assignment in 3344bis. The lifetime issue is what's not addressed in existing dynamic HoA scheme, that others seek clarifications. Kent -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Thu Mar 25 21:15:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09130 for ; Thu, 25 Mar 2004 21:15:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6grv-0000AF-K9 for mip4-archive@odin.ietf.org; Thu, 25 Mar 2004 21:14:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2Q2ElWD000629 for mip4-archive@odin.ietf.org; Thu, 25 Mar 2004 21:14:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6gru-0000A4-6i for mip4-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 21:14:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09122 for ; Thu, 25 Mar 2004 21:14:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6grr-0007F5-00 for mip4-web-archive@ietf.org; Thu, 25 Mar 2004 21:14:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6gqv-0007BZ-00 for mip4-web-archive@ietf.org; Thu, 25 Mar 2004 21:13:46 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6gqC-000784-00 for mip4-web-archive@ietf.org; Thu, 25 Mar 2004 21:13:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6gqD-0008Vp-IQ; Thu, 25 Mar 2004 21:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6gpv-0008VA-PQ for mip4@optimus.ietf.org; Thu, 25 Mar 2004 21:12:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09078 for ; Thu, 25 Mar 2004 21:12:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6gpt-00076X-00 for mip4@ietf.org; Thu, 25 Mar 2004 21:12:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6goy-00073N-00 for mip4@ietf.org; Thu, 25 Mar 2004 21:11:45 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B6gof-00070A-00 for mip4@ietf.org; Thu, 25 Mar 2004 21:11:25 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 25 Mar 2004 18:16:16 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2Q2AsUe027910 for ; Thu, 25 Mar 2004 18:10:54 -0800 (PST) Received: from kleung-w2k01.cisco.com (sjc-vpn4-212.cisco.com [10.21.80.212]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ARM86231; Thu, 25 Mar 2004 18:10:54 -0800 (PST) Message-Id: <4.3.2.7.2.20040325180951.01cd57e0@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 25 Mar 2004 18:10:53 -0800 To: mip4@ietf.org From: Kent Leung Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Mip4] NAI-based dynamic home address assignment draft Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 FYI. To: IETF-Announce: ; Subject: I-D ACTION:draft-paulkandasamy-mobileip-nai-based-home-addres-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Mobile IPv4 NAI-based Home Address Assignment Author(s) : N. PaulKandasamy, K. Leung Filename : draft-paulkandasamy-mobileip-nai-based-home-addres-00.txt Pages : 21 Date : 2004-3-25 With the introduction of NAIs for identifying Mobile Nodes, RFC 2794 also enabled the Home Agents to be able to assign IP addresses to the Mobile Nodes during the initial registration. Though the concept of NAI-based home address assignment is referenced in both RFC 2794 and RFC 3344, a comprehensive procedure for achieving such a NAI-based home address assignment has not been outlined. More particularly, the Home Agent and Mobile Node behaviors including the error recovery mechanisms for various scenarios related to NAI- based home address assignment have not yet been specified. This document specifies a procedure that the Mobile IP entities should follow in order to facilitate NAI-based home address assignment under various circumstances. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-paulkandasamy-mobileip-nai-based-home-addres-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-paulkandasamy-mobileip-nai-based-home-addres-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-paulkandasamy-mobileip-nai-based-home-addres-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <2004-3-25154523.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-paulkandasamy-mobileip-nai-based-home-addres-00.txt -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Thu Mar 25 21:34:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09936 for ; Thu, 25 Mar 2004 21:34:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6hAH-0001J5-63 for mip4-archive@odin.ietf.org; Thu, 25 Mar 2004 21:33:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2Q2XjXY005017 for mip4-archive@odin.ietf.org; Thu, 25 Mar 2004 21:33:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6hAH-0001Iq-1o for mip4-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 21:33:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09922 for ; Thu, 25 Mar 2004 21:33:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6hAE-0000r5-00 for mip4-web-archive@ietf.org; Thu, 25 Mar 2004 21:33:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6h9I-0000n5-00 for mip4-web-archive@ietf.org; Thu, 25 Mar 2004 21:32:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6h8Y-0000jk-00 for mip4-web-archive@ietf.org; Thu, 25 Mar 2004 21:31:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6h8a-00017d-9M; Thu, 25 Mar 2004 21:32:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6h8H-00016u-NV for mip4@optimus.ietf.org; Thu, 25 Mar 2004 21:31:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09857 for ; Thu, 25 Mar 2004 21:31:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6h8F-0000ht-00 for mip4@ietf.org; Thu, 25 Mar 2004 21:31:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6h7H-0000dI-00 for mip4@ietf.org; Thu, 25 Mar 2004 21:30:40 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1B6h6L-0000Vu-00 for mip4@ietf.org; Thu, 25 Mar 2004 21:29:41 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i2Q2T3j06490; Thu, 25 Mar 2004 18:29:03 -0800 X-mProtect: <200403260229> Nokia Silicon Valley Messaging Protection Received: from esnira-pool4015237.nokia.com (10.162.15.237, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdhrKKXG; Thu, 25 Mar 2004 18:29:01 PST Message-ID: <40639560.6030709@iprg.nokia.com> Date: Thu, 25 Mar 2004 18:28:48 -0800 From: "Charles E. Perkins" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kent Leung CC: mip4@ietf.org Subject: Re: [Mip4] RFC3344biz Dynamic HoA bug ? References: <4.3.2.7.2.20040325161322.02984470@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040325105440.01da26f8@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040325161322.02984470@mira-sjcm-2.cisco.com> <4.3.2.7.2.200403 In-Reply-To: <4.3.2.7.2.20040325171551.029a7388@mira-sjcm-2.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Kent, Kent Leung wrote: > So we're in agreement that there is an outstanding issue with > dynamic HoA in regards to returning home? And that can be > solved by new drafts or revised old drafts? I'd rather say that, if the assignment mechanism in rfc3344bis is used, and the allocation is dynamic, then the method by which the address lifetimes are communicated to the mobile node are not specified in rfc3344bis. But, nothing in rfc3344bis requires or prevents the address from being statically allocated, or dynamically allocated, either way. And, I am convinced that rfc3344bis is not the correct draft for creating those specifications. > My point has been that it doesn't matter which type of address > management scheme is used, we need some more information > in Mobile IP protocol to allow MN to communicate how it wants > to maintain the HoA when at home. Mobile IP lacks this today. I'd be happy if you would delete "in Mobile IP protocol" in the above paragraph, and replace the last sentence by: "Solving this problem is out of scope for rfc3344bis". Regards, Charlie P. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Fri Mar 26 13:38:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06904 for ; Fri, 26 Mar 2004 13:38:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6wDl-00017m-VO for mip4-archive@odin.ietf.org; Fri, 26 Mar 2004 13:38:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2QIcLKK004318 for mip4-archive@odin.ietf.org; Fri, 26 Mar 2004 13:38:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6wDl-00017R-PB for mip4-web-archive@optimus.ietf.org; Fri, 26 Mar 2004 13:38:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06882 for ; Fri, 26 Mar 2004 13:38:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6wDj-0003UF-00 for mip4-web-archive@ietf.org; Fri, 26 Mar 2004 13:38:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6wCs-0003R9-00 for mip4-web-archive@ietf.org; Fri, 26 Mar 2004 13:37:26 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6wCW-0003N1-00 for mip4-web-archive@ietf.org; Fri, 26 Mar 2004 13:37:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6wCU-0000jO-1S; Fri, 26 Mar 2004 13:37:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6wBi-0000iV-IT for mip4@optimus.ietf.org; Fri, 26 Mar 2004 13:36:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06743 for ; Fri, 26 Mar 2004 13:36:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6wBg-0003Kq-00 for mip4@ietf.org; Fri, 26 Mar 2004 13:36:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6wAr-0003Ht-00 for mip4@ietf.org; Fri, 26 Mar 2004 13:35:22 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B6wA9-0003Ar-00 for mip4@ietf.org; Fri, 26 Mar 2004 13:34:37 -0500 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2QIY5Ue015212; Fri, 26 Mar 2004 10:34:05 -0800 (PST) Received: from kleung-w2k01.cisco.com (dhcp-171-71-210-99.cisco.com [171.71.210.99]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ARN30338; Fri, 26 Mar 2004 10:34:04 -0800 (PST) Message-Id: <4.3.2.7.2.20040326102906.02984ec0@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 26 Mar 2004 10:34:04 -0800 To: "Charles E. Perkins" From: Kent Leung Subject: Re: [Mip4] RFC3344biz Dynamic HoA bug ? Cc: mip4@ietf.org In-Reply-To: <40639560.6030709@iprg.nokia.com> References: <4.3.2.7.2.20040325171551.029a7388@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040325161322.02984470@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040325105440.01da26f8@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040325161322.02984470@mira-sjcm-2.cisco.com> <4.3.2.7.2.200403> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 Hi Charlie. When I said, "Mobile IP protocol", that meant the set of RFCs pertaining to Mobile IP. And "3344bis" is specific to the draft. So I meant what I said. :) Kent At 06:28 PM 3/25/2004 -0800, Charles E. Perkins wrote: >Hello Kent, > >Kent Leung wrote: > >>So we're in agreement that there is an outstanding issue with >>dynamic HoA in regards to returning home? And that can be >>solved by new drafts or revised old drafts? > >I'd rather say that, if the assignment mechanism in rfc3344bis >is used, and the allocation is dynamic, then the method by which >the address lifetimes are communicated to the mobile node >are not specified in rfc3344bis. But, nothing in rfc3344bis >requires or prevents the address from being statically allocated, >or dynamically allocated, either way. And, I am convinced that >rfc3344bis is not the correct draft for creating those specifications. > >>My point has been that it doesn't matter which type of address >>management scheme is used, we need some more information >>in Mobile IP protocol to allow MN to communicate how it wants >>to maintain the HoA when at home. Mobile IP lacks this today. > >I'd be happy if you would delete "in Mobile IP protocol" in the >above paragraph, and replace the last sentence by: >"Solving this problem is out of scope for rfc3344bis". > >Regards, >Charlie P. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Fri Mar 26 14:16:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09144 for ; Fri, 26 Mar 2004 14:16:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6woA-0004PH-7p for mip4-archive@odin.ietf.org; Fri, 26 Mar 2004 14:15:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2QJFwUb016933 for mip4-archive@odin.ietf.org; Fri, 26 Mar 2004 14:15:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6woA-0004P2-1f for mip4-web-archive@optimus.ietf.org; Fri, 26 Mar 2004 14:15:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08980 for ; Fri, 26 Mar 2004 14:15:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6wo7-0006og-00 for mip4-web-archive@ietf.org; Fri, 26 Mar 2004 14:15:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6wmh-0006am-00 for mip4-web-archive@ietf.org; Fri, 26 Mar 2004 14:14:29 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6wlI-0006LC-00 for mip4-web-archive@ietf.org; Fri, 26 Mar 2004 14:13:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6wlK-00047C-0l; Fri, 26 Mar 2004 14:13:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6wko-00046S-Lh for mip4@optimus.ietf.org; Fri, 26 Mar 2004 14:12:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08648 for ; Fri, 26 Mar 2004 14:12:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6wkm-0006J0-00 for mip4@ietf.org; Fri, 26 Mar 2004 14:12:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6wjy-0006EN-00 for mip4@ietf.org; Fri, 26 Mar 2004 14:11:39 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1B6wjK-000664-00 for mip4@ietf.org; Fri, 26 Mar 2004 14:10:58 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i2QJAGj10867; Fri, 26 Mar 2004 11:10:16 -0800 X-mProtect: <200403261910> Nokia Silicon Valley Messaging Protection Received: from esnira-pool3014181.nokia.com (10.162.14.181, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdHa04Kb; Fri, 26 Mar 2004 11:10:13 PST Message-ID: <40648009.6050402@iprg.nokia.com> Date: Fri, 26 Mar 2004 11:10:01 -0800 From: "Charles E. Perkins" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kent Leung CC: mip4@ietf.org Subject: Re: [Mip4] RFC3344biz Dynamic HoA bug ? References: <4.3.2.7.2.20040325171551.029a7388@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040325161322.02984470@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040325105440.01da26f8@mira-sjcm-2.cisco.com> <4.3.2.7.2.200403 In-Reply-To: <4.3.2.7.2.20040326102906.02984ec0@mira-sjcm-2.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Kent, Well, I'm not meaning to refute your overall point that additional lifetime information is needed by the mobile node when dealing with dynamically allocated addresses. But, the _subject_ of this thread has to do with rfc3344bis, and that is a document I am working on. So, I am being very picky to try to understand what needs to go into that document, and I really want to make sure there is not a bug in that document. Sorry if I wasn't clear about that. Regards, Charlie P. Kent Leung wrote: > Hi Charlie. > > When I said, "Mobile IP protocol", that meant the set of RFCs pertaining > to Mobile IP. And "3344bis" is specific to the draft. So I meant what I > said. :) > > Kent > > At 06:28 PM 3/25/2004 -0800, Charles E. Perkins wrote: > >> Hello Kent, >> >> Kent Leung wrote: >> >>> So we're in agreement that there is an outstanding issue with >>> dynamic HoA in regards to returning home? And that can be >>> solved by new drafts or revised old drafts? >> >> >> I'd rather say that, if the assignment mechanism in rfc3344bis >> is used, and the allocation is dynamic, then the method by which >> the address lifetimes are communicated to the mobile node >> are not specified in rfc3344bis. But, nothing in rfc3344bis >> requires or prevents the address from being statically allocated, >> or dynamically allocated, either way. And, I am convinced that >> rfc3344bis is not the correct draft for creating those specifications. >> >>> My point has been that it doesn't matter which type of address >>> management scheme is used, we need some more information >>> in Mobile IP protocol to allow MN to communicate how it wants >>> to maintain the HoA when at home. Mobile IP lacks this today. >> >> >> I'd be happy if you would delete "in Mobile IP protocol" in the >> above paragraph, and replace the last sentence by: >> "Solving this problem is out of scope for rfc3344bis". >> >> Regards, >> Charlie P. > > > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Fri Mar 26 17:46:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22292 for ; Fri, 26 Mar 2004 17:46:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B705n-0001rF-16 for mip4-archive@odin.ietf.org; Fri, 26 Mar 2004 17:46:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2QMkMex007137 for mip4-archive@odin.ietf.org; Fri, 26 Mar 2004 17:46:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B705m-0001r2-QO for mip4-web-archive@optimus.ietf.org; Fri, 26 Mar 2004 17:46:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22286 for ; Fri, 26 Mar 2004 17:46:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B705k-0001dF-00 for mip4-web-archive@ietf.org; Fri, 26 Mar 2004 17:46:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B704u-0001aL-00 for mip4-web-archive@ietf.org; Fri, 26 Mar 2004 17:45:28 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B704R-0001We-00 for mip4-web-archive@ietf.org; Fri, 26 Mar 2004 17:44:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B704S-0001cD-UR; Fri, 26 Mar 2004 17:45:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B703n-0001aw-Jt for mip4@optimus.ietf.org; Fri, 26 Mar 2004 17:44:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22190 for ; Fri, 26 Mar 2004 17:44:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B703l-0001Tv-00 for mip4@ietf.org; Fri, 26 Mar 2004 17:44:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B702n-0001Pb-00 for mip4@ietf.org; Fri, 26 Mar 2004 17:43:18 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1B701y-0001JL-00 for mip4@ietf.org; Fri, 26 Mar 2004 17:42:26 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-5.cisco.com with ESMTP; 26 Mar 2004 14:42:04 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i2QMfsKj029782; Fri, 26 Mar 2004 14:41:55 -0800 (PST) Received: from kleung-w2k01.cisco.com (sjc-vpn4-843.cisco.com [10.21.83.74]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ARN54978; Fri, 26 Mar 2004 14:41:54 -0800 (PST) Message-Id: <4.3.2.7.2.20040326112624.02984460@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 26 Mar 2004 11:34:12 -0800 To: "Charles E. Perkins" From: Kent Leung Subject: Re: [Mip4] RFC3344biz Dynamic HoA bug ? Cc: mip4@ietf.org In-Reply-To: <40648009.6050402@iprg.nokia.com> References: <4.3.2.7.2.20040326102906.02984ec0@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040325171551.029a7388@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040325161322.02984470@mira-sjcm-2.cisco.com> <4.3.2.7.2.20040325105440.01da26f8@mira-sjcm-2.cisco.com> <4.3.2.7.2.200403> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,DATE_IN_PAST_03_06 autolearn=no version=2.60 Hi Charlie. OK. I was tackling the general issue from both Mobile IP and 3344bis perspective and was trying to be clear from which perspective each statement was about. Some of the other discussions were also commenting on their preferences on work items for 3344bis and in general for WG... Sorry, if I strayed too far from 3344bis specifics... Kent At 11:10 AM 3/26/2004 -0800, Charles E. Perkins wrote: >Hello Kent, > >Well, I'm not meaning to refute your overall point that >additional lifetime information is needed by the mobile >node when dealing with dynamically allocated addresses. >But, the _subject_ of this thread has to do with >rfc3344bis, and that is a document I am working on. >So, I am being very picky to try to understand what >needs to go into that document, and I really want to >make sure there is not a bug in that document. > >Sorry if I wasn't clear about that. > >Regards, >Charlie P. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Mon Mar 29 02:51:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16772 for ; Mon, 29 Mar 2004 02:51:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7rYE-0004cH-PW for mip4-archive@odin.ietf.org; Mon, 29 Mar 2004 02:51:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2T7pIhg017744 for mip4-archive@odin.ietf.org; Mon, 29 Mar 2004 02:51:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7rYE-0004c7-B7 for mip4-web-archive@optimus.ietf.org; Mon, 29 Mar 2004 02:51:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16769 for ; Mon, 29 Mar 2004 02:51:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7rYA-0000Hn-00 for mip4-web-archive@ietf.org; Mon, 29 Mar 2004 02:51:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7rXK-0000A2-00 for mip4-web-archive@ietf.org; Mon, 29 Mar 2004 02:50:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B7rWx-00001z-00 for mip4-web-archive@ietf.org; Mon, 29 Mar 2004 02:49:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7rX0-0004WI-8e; Mon, 29 Mar 2004 02:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7rWJ-0004UC-Rm for mip4@optimus.ietf.org; Mon, 29 Mar 2004 02:49:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16688 for ; Mon, 29 Mar 2004 02:49:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7rWG-0007nh-00 for mip4@ietf.org; Mon, 29 Mar 2004 02:49:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7rVR-0007f8-00 for mip4@ietf.org; Mon, 29 Mar 2004 02:48:26 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B7rUY-0007NN-00 for mip4@ietf.org; Mon, 29 Mar 2004 02:47:30 -0500 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 29 Mar 2004 02:47:01 -0500 Subject: RE: [Mip4] RFC3344biz Dynamic HoA bug ? Date: Mon, 29 Mar 2004 02:47:01 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: [Mip4] RFC3344biz Dynamic HoA bug ? Content-Class: urn:content-classes:message Thread-Index: AcQSmSVML+phPt/rS2qE59+SfBH+bwCkZcFA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 From: "O'Neill Alan" To: X-OriginalArrivalTime: 29 Mar 2004 07:47:01.0710 (UTC) FILETIME=[05899EE0:01C41562] Content-Transfer-Encoding: quoted-printable Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Ok so I am hoping to clarify some of the alternative interpretations of RFC3344bis, that I think we have discussed wrt dynamic HoA allocation, = given that RFC3344bis is mute on the point. ------------------------- 1) The first interpretation is that the address allocation lifetime in RFC3344bis is not tied to the binding lifetime, and by default is = UNDEFINED (static=3Dinfinity until otherwise defined ?). Hence when the MN returns = home and cancels a binding then the packets remain deliverable because the MN still has the address. This means that RFC3344bis does not deliver an = address life-time, and Charlie feels any such lifetime is out of scope of = RFC3344bis. I am not sure how many products interpret RFC3344bis this way. FIX to RFC3344bis: So to fully support this interpretation in = RFC3344bis, some text needs to be added into to state this clearly. Future Work outside of RFC3344bis: The additional work here then is = define how the address lifetime moves from UNDEFINED to DEFINED, and the = address subsequently recovered so that the HA can reallocate safely. This could = use MIP or non-MIP mechanisms. ----------------------- 2) An alternative view is that the default address lifetime is equal to = the MIP binding lifetime, such that the HA recovers the dynamically assigned = HoA on binding cessation. This works fine for virtual home networks (ie cellular), such that the MN cannot return home and lose its address prematurely. However, if a real home can be visited (such as enterprise) = then we have the forced in-session address deallocation problem on binding cessation. I do know of MIP products that ship today that employ this interpretation of RFC3344bis. FIX to RFC3344bis: So to fully support this interpretation in = RFC3344bis, some text needs to be added to state this clearly, clearly indicating = that the address is deallocated automatically on returning home. Future Work outside of RFC3344bis: In addition, some additional work = then needs to occur to address the uncontrolled address deallocation problem = when returning to real home networks, which for example could use the = HALR/HALG model. The interop with non_MIP address management mechanisms would also = be useful here. --------------------- 3) A third interpretation is not to interpret. By this I mean that = RFC3344bis leaves the address lifetime as UNDEFINED with no explanation, and hence = some systems can make it static whilst others can make the address lifetime = equal to the MIP lifetime. FIX: Do nothing and wait for interop problems before fixing which I = assume no-one wants. ---------------------- A Personal Opinion So I am generally troubled by RFC3344bis going ahead with interpretation = 1, given that it defines an incomplete entity lifecycle for a commercially valuable entity.=20 I also feel that the default lifetime in RFC3344bis (MIP lifetime v UNDEFINED) should be representative of the major usage case, with future = work adding refinements via extensions such as HALR/HALG, and other non-MIP mechanisms. I know of a significant requirement for dynamic address = lifetimes that are tied to the MIP session duration, because operators want to statistically multiplex the address block across the MN population, and = to be able to recover addresses on MN failures (after MIP time-out).=20 Personally, I cannot envisage a substantial requirement for dynamic = address allocation with UNDEFINED (static) lifetimes, given the dominant need = for statistical reallocation. However, if we do have a significant installed = base of, or requirement for, interpretation 1 in RFC3344bis, then I guess the = wg needs to consider this (info/views?), and then maybe we have to rely on HALR/HALG type stuff even for the common case of address = lifetime=3Dbinding lifetime. Alan. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by other is=20 strictly prohibited. If you are not the inteded recipient please = contact the sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Mon Mar 29 04:57:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22705 for ; Mon, 29 Mar 2004 04:57:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7tWL-000376-6K for mip4-archive@odin.ietf.org; Mon, 29 Mar 2004 04:57:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2T9vTFV011967 for mip4-archive@odin.ietf.org; Mon, 29 Mar 2004 04:57:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7tWK-00036o-Rq for mip4-web-archive@optimus.ietf.org; Mon, 29 Mar 2004 04:57:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22685 for ; Mon, 29 Mar 2004 04:57:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7tWH-0002ps-00 for mip4-web-archive@ietf.org; Mon, 29 Mar 2004 04:57:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7tVL-0002ix-00 for mip4-web-archive@ietf.org; Mon, 29 Mar 2004 04:56:29 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B7tUu-0002bl-00 for mip4-web-archive@ietf.org; Mon, 29 Mar 2004 04:56:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7tUw-0002tQ-GT; Mon, 29 Mar 2004 04:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7tUJ-0002my-Nt for mip4@optimus.ietf.org; Mon, 29 Mar 2004 04:55:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22570 for ; Mon, 29 Mar 2004 04:55:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7tUG-0002aS-00 for mip4@ietf.org; Mon, 29 Mar 2004 04:55:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7tTJ-0002Sw-00 for mip4@ietf.org; Mon, 29 Mar 2004 04:54:22 -0500 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 1B7tSW-0002Lc-00 for mip4@ietf.org; Mon, 29 Mar 2004 04:53:32 -0500 Received: from ipunplugged.com (echo.local.ipunplugged.com [192.168.4.74]) by mailgw.local.ipunplugged.com (8.12.8/8.12.3) with ESMTP id i2T9rSvO011778; Mon, 29 Mar 2004 11:53:28 +0200 Message-ID: <4067F168.8000804@ipunplugged.com> Date: Mon, 29 Mar 2004 11:50:32 +0200 From: =?ISO-8859-1?Q?Hans_Sj=F6strand?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: sv, en-us, en, ja MIME-Version: 1.0 To: "O'Neill Alan" , mip4@ietf.org Subject: Re: [Mip4] RFC3344biz Dynamic HoA bug ? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Virus-Scanned: clamd / ClamAV version 0.70rc, clamav-milter version 0.70 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mailgw.local.ipunplugged.com id i2T9rSvO011778 Content-Transfer-Encoding: quoted-printable Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Alan, =CD agree that there might in some scenarios be nive to add address=20 allocation lifetimes to Home Agent implementations, especially in the=20 cases where the home agent for some reason maintain an address pool. In=20 these scenarious it might be whise to do a extension to mobile IP to=20 perform address management. This is best started with a draft and then=20 the WG will decide if it's worthwhile work to take on. But to state saying that 3344 or even worse, Mobiel IP, is broken=20 because there are no address lifetime management specified is going to=20 far. I tried to explain that how the home agent allocates a address to=20 the MN as the MN home address is not at all a business for the Mobilr IP=20 protocool. An example Mobile IP should handle that computers can roam away from the home=20 network, and still maintain all that it could do before. But not more! A=20 computer that is turned on on a local LAN most often uses DHCP is=20 dynamic address allocation is used in that LAN environment. The sysadmin=20 has decided a lease time for these, quite common is one hour. So, the=20 computer gets a lease for 1 hour, and must make sure that it's renewed=20 before that expires if the computer intends to continiue using it. Note=20 that the DHCP server *does not* arp to make sure that the computer still=20 are out there and alive, and very seldom does the computer leave back=20 the lease to the server before it expires. Add mobile IP to this, Now we have a MN thats booted somewhree in the=20 world, he registeres with it's HA. The HA must now make sure that it=20 allocates a address to this MN, and that the HA maintains that address=20 aslong as the MN is registerd with the HA. Thats his task. His task *is=20 not" to leave back the IP address to the DHCP server if the session is=20 ended. When/if the MN returns home, the MN deregisteres with the HA and thereby=20 releving the HA from it's task to maintain the address and now takes=20 responsibility to maintain it himself. This quite clearly illustrate that there are no need to have any more=20 explicit adress management build into Mobile IP. There is no connectno=20 between teh lifetime of the binding, adn the lifetime of the lease. How=20 a HA allocates addresses are deployment specific. RFCF3344 should not /=20 need not to be burdend by it. The HA implementation of course needs to=20 be burdend with it, but thats a different thing. Unfortunately I haven't had time to read Naveen PaulKandasamy and Kent=20 Leung's draft about this. Hopefull it is compatible with what I wrote ;-) Regards /// Hasse O'Neill Alan wrote: >Ok so I am hoping to clarify some of the alternative interpretations of >RFC3344bis, that I think we have discussed wrt dynamic HoA allocation, g= iven >that RFC3344bis is mute on the point. > >------------------------- > >1) The first interpretation is that the address allocation lifetime in >RFC3344bis is not tied to the binding lifetime, and by default is UNDEFI= NED >(static=3Dinfinity until otherwise defined ?). Hence when the MN returns= home >and cancels a binding then the packets remain deliverable because the MN >still has the address. This means that RFC3344bis does not deliver an ad= dress >life-time, and Charlie feels any such lifetime is out of scope of RFC334= 4bis. >I am not sure how many products interpret RFC3344bis this way. > >FIX to RFC3344bis: So to fully support this interpretation in RFC3344bis= , >some text needs to be added into to state this clearly. > >Future Work outside of RFC3344bis: The additional work here then is defi= ne >how the address lifetime moves from UNDEFINED to DEFINED, and the addres= s >subsequently recovered so that the HA can reallocate safely. This could = use >MIP or non-MIP mechanisms. > >----------------------- > >2) An alternative view is that the default address lifetime is equal to = the >MIP binding lifetime, such that the HA recovers the dynamically assigned= HoA >on binding cessation. This works fine for virtual home networks (ie >cellular), such that the MN cannot return home and lose its address >prematurely. However, if a real home can be visited (such as enterprise)= then >we have the forced in-session address deallocation problem on binding >cessation. I do know of MIP products that ship today that employ this >interpretation of RFC3344bis. > >FIX to RFC3344bis: So to fully support this interpretation in RFC3344bis= , >some text needs to be added to state this clearly, clearly indicating th= at >the address is deallocated automatically on returning home. > >Future Work outside of RFC3344bis: In addition, some additional work the= n >needs to occur to address the uncontrolled address deallocation problem = when >returning to real home networks, which for example could use the HALR/HA= LG >model. The interop with non_MIP address management mechanisms would also= be >useful here. > >--------------------- > >3) A third interpretation is not to interpret. By this I mean that RFC33= 44bis >leaves the address lifetime as UNDEFINED with no explanation, and hence = some >systems can make it static whilst others can make the address lifetime e= qual >to the MIP lifetime. > >FIX: Do nothing and wait for interop problems before fixing which I assu= me >no-one wants. > >---------------------- > >A Personal Opinion > >So I am generally troubled by RFC3344bis going ahead with interpretation= 1, >given that it defines an incomplete entity lifecycle for a commercially >valuable entity.=20 > >I also feel that the default lifetime in RFC3344bis (MIP lifetime v >UNDEFINED) should be representative of the major usage case, with future= work >adding refinements via extensions such as HALR/HALG, and other non-MIP >mechanisms. I know of a significant requirement for dynamic address life= times >that are tied to the MIP session duration, because operators want to >statistically multiplex the address block across the MN population, and = to be >able to recover addresses on MN failures (after MIP time-out).=20 > >Personally, I cannot envisage a substantial requirement for dynamic addr= ess >allocation with UNDEFINED (static) lifetimes, given the dominant need fo= r >statistical reallocation. However, if we do have a significant installed= base >of, or requirement for, interpretation 1 in RFC3344bis, then I guess the= wg >needs to consider this (info/views?), and then maybe we have to rely on >HALR/HALG type stuff even for the common case of address lifetime=3Dbind= ing >lifetime. > >Alan. > > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D >This email may contain confidential and privileged material for the sole >use of the intended recipient. Any review or distribution by other is=20 >strictly prohibited. If you are not the inteded recipient please contac= t >the sender and delete all copies. >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > > > =20 > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Mon Mar 29 16:35:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28190 for ; Mon, 29 Mar 2004 16:35:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B84PF-00068N-1w for mip4-archive@odin.ietf.org; Mon, 29 Mar 2004 16:34:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2TLYqeH023578 for mip4-archive@odin.ietf.org; Mon, 29 Mar 2004 16:34:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B84P8-000684-Sc for mip4-web-archive@optimus.ietf.org; Mon, 29 Mar 2004 16:34:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28152 for ; Mon, 29 Mar 2004 16:34:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B84P3-0002tY-00 for mip4-web-archive@ietf.org; Mon, 29 Mar 2004 16:34:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B84OE-0002lh-00 for mip4-web-archive@ietf.org; Mon, 29 Mar 2004 16:33:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B84NR-0002dY-00 for mip4-web-archive@ietf.org; Mon, 29 Mar 2004 16:33:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B84NS-00060x-5F; Mon, 29 Mar 2004 16:33:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B84NN-00060E-VG for mip4@optimus.ietf.org; Mon, 29 Mar 2004 16:32:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28088 for ; Mon, 29 Mar 2004 16:32:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B84NM-0002cX-00 for mip4@ietf.org; Mon, 29 Mar 2004 16:32:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B84MI-0002TB-00 for mip4@ietf.org; Mon, 29 Mar 2004 16:31:51 -0500 Received: from mail-gw0.york.ac.uk ([144.32.128.245]) by ietf-mx with esmtp (Exim 4.12) id 1B84Lf-0002IJ-00 for mip4@ietf.org; Mon, 29 Mar 2004 16:31:11 -0500 Received: from grouse (grouse.ohm.york.ac.uk [144.32.137.104]) by mail-gw0.york.ac.uk (8.12.10/8.12.10) with SMTP id i2TLUXTA012756; Mon, 29 Mar 2004 22:30:33 +0100 (BST) Message-ID: <00c201c415d5$1d163af0$68892090@grouse> From: "Jee J.Z." To: "O'Neill Alan" Cc: "Mobile IP v4" References: Subject: Re: [Mip4] RFC3344biz Dynamic HoA bug ? Date: Mon, 29 Mar 2004 22:30:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-York-MailScanner: Found to be clean Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.6 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi O'Neill, IMHO, I think the third interpretation would be better. I think the HoA lifetime is implementation dependent, since some small enterprises may prefer 'permanent' HoA allocation while other large ISPs may prefer dynamical one. Moreover, I don't understand why we should put forward this issue (?). I mean, I think HoA allocation should be independent of any other CoA configurations. When a MN boots in a foreign network and needs dynamical HoA allocation, can't it just utilize its acquired CoA and NAI to request its HA to act as a proxy DHCP client to ask for a HoA from a DHCP server on its home network? From then on, the MN renew its HoA lifetime independently if needed. Why shall we worry about the loss of HoA when the MN returns home? I must be missing something obvious. Cheers, Jee > Ok so I am hoping to clarify some of the alternative interpretations of > RFC3344bis, that I think we have discussed wrt dynamic HoA allocation, given > that RFC3344bis is mute on the point. > > ------------------------- > > 1) The first interpretation is that the address allocation lifetime in > RFC3344bis is not tied to the binding lifetime, and by default is UNDEFINED > (static=infinity until otherwise defined ?). Hence when the MN returns home > and cancels a binding then the packets remain deliverable because the MN > still has the address. This means that RFC3344bis does not deliver an address > life-time, and Charlie feels any such lifetime is out of scope of RFC3344bis. > I am not sure how many products interpret RFC3344bis this way. > > FIX to RFC3344bis: So to fully support this interpretation in RFC3344bis, > some text needs to be added into to state this clearly. > > Future Work outside of RFC3344bis: The additional work here then is define > how the address lifetime moves from UNDEFINED to DEFINED, and the address > subsequently recovered so that the HA can reallocate safely. This could use > MIP or non-MIP mechanisms. > > ----------------------- > > 2) An alternative view is that the default address lifetime is equal to the > MIP binding lifetime, such that the HA recovers the dynamically assigned HoA > on binding cessation. This works fine for virtual home networks (ie > cellular), such that the MN cannot return home and lose its address > prematurely. However, if a real home can be visited (such as enterprise) then > we have the forced in-session address deallocation problem on binding > cessation. I do know of MIP products that ship today that employ this > interpretation of RFC3344bis. > > FIX to RFC3344bis: So to fully support this interpretation in RFC3344bis, > some text needs to be added to state this clearly, clearly indicating that > the address is deallocated automatically on returning home. > > Future Work outside of RFC3344bis: In addition, some additional work then > needs to occur to address the uncontrolled address deallocation problem when > returning to real home networks, which for example could use the HALR/HALG > model. The interop with non_MIP address management mechanisms would also be > useful here. > > --------------------- > > 3) A third interpretation is not to interpret. By this I mean that RFC3344bis > leaves the address lifetime as UNDEFINED with no explanation, and hence some > systems can make it static whilst others can make the address lifetime equal > to the MIP lifetime. > > FIX: Do nothing and wait for interop problems before fixing which I assume > no-one wants. > > ---------------------- > > A Personal Opinion > > So I am generally troubled by RFC3344bis going ahead with interpretation 1, > given that it defines an incomplete entity lifecycle for a commercially > valuable entity. > > I also feel that the default lifetime in RFC3344bis (MIP lifetime v > UNDEFINED) should be representative of the major usage case, with future work > adding refinements via extensions such as HALR/HALG, and other non-MIP > mechanisms. I know of a significant requirement for dynamic address lifetimes > that are tied to the MIP session duration, because operators want to > statistically multiplex the address block across the MN population, and to be > able to recover addresses on MN failures (after MIP time-out). > > Personally, I cannot envisage a substantial requirement for dynamic address > allocation with UNDEFINED (static) lifetimes, given the dominant need for > statistical reallocation. However, if we do have a significant installed base > of, or requirement for, interpretation 1 in RFC3344bis, then I guess the wg > needs to consider this (info/views?), and then maybe we have to rely on > HALR/HALG type stuff even for the common case of address lifetime=binding > lifetime. > > Alan. > > > ======================================================== > This email may contain confidential and privileged material for the sole > use of the intended recipient. Any review or distribution by other is > strictly prohibited. If you are not the inteded recipient please contact > the sender and delete all copies. > ======================================================== > > > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ > > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Mon Mar 29 18:59:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04738 for ; Mon, 29 Mar 2004 18:59:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B86eV-0006pU-G5 for mip4-archive@odin.ietf.org; Mon, 29 Mar 2004 18:58:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2TNwlII026251 for mip4-archive@odin.ietf.org; Mon, 29 Mar 2004 18:58:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B86eV-0006pK-AP for mip4-web-archive@optimus.ietf.org; Mon, 29 Mar 2004 18:58:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04714 for ; Mon, 29 Mar 2004 18:58:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B86eS-0007B7-00 for mip4-web-archive@ietf.org; Mon, 29 Mar 2004 18:58:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B86dY-00073A-00 for mip4-web-archive@ietf.org; Mon, 29 Mar 2004 18:57:49 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B86cl-0006vl-00 for mip4-web-archive@ietf.org; Mon, 29 Mar 2004 18:56:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B86cm-0006cs-Kw; Mon, 29 Mar 2004 18:57:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B86cf-0006cD-B8 for mip4@optimus.ietf.org; Mon, 29 Mar 2004 18:56:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04632 for ; Mon, 29 Mar 2004 18:56:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B86cc-0006ug-00 for mip4@ietf.org; Mon, 29 Mar 2004 18:56:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B86bg-0006mI-00 for mip4@ietf.org; Mon, 29 Mar 2004 18:55:53 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B86as-0006Wq-00 for mip4@ietf.org; Mon, 29 Mar 2004 18:55:02 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 29 Mar 2004 16:01:49 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2TNsUUe013936; Mon, 29 Mar 2004 15:54:31 -0800 (PST) Received: from kleung-w2k01.cisco.com (dhcp-128-107-163-47.cisco.com [128.107.163.47]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ARO96520; Mon, 29 Mar 2004 15:54:30 -0800 (PST) Message-Id: <4.3.2.7.2.20040329094135.03e29560@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 29 Mar 2004 15:54:29 -0800 To: Hans =?iso-8859-1?Q?Sj=F6strand?= From: Kent Leung Subject: Re: [Mip4] RFC3344biz Dynamic HoA bug ? Cc: "O'Neill Alan" , mip4@ietf.org In-Reply-To: <4067F168.8000804@ipunplugged.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Here are my 2 cents .. :) The registration lifetime is used for aging the mobility binding - RFC 3344 states "The number of seconds remaining before the registration is considered expired." There are no message fields or extensions to= specify address lease time in any RFC. The only plausible way to effectively manage a reusable address pool is by releasing the address when mobility binding is no longer needed. So in effect, the address lease lifetime is the same as= the registration lifetime. My interpretation, #2 on Alan's list :) Though=20 for 3344bis, I think since specification does not cover how address management works, it shouldn't be required to cover what's wrong with it. To support an address management function, here are some common scenarios. 1) DHCP is common in Enterprise and can be used as an external protocol=20 with some integration of DHCP and Mobile IP (see Proxy DHCP draft) using extensions. 2) Local pool managed by the HA requires some integrated Mobile IP=20 signaling to maintain the address lease. 3) AAA manages address pool in conjunction with HA. HA notifies AAA server= =20 using RADIUS messages when MN's session starts and stops. From HA's perspective,= =20 this scenario is like #2 where Mobile IP signaling is enhanced to provide=20 information on when MN is done with leased address. For cases #2 and #3, there is the assumption that MNs don't support=20 DHCP. In general, there are 2 methods for supporting address management, external protocol=20 such as DHCP or address management information in Mobile IP messages when HA manages the address pool or interacts with AAA server. Unfortunately, we had written our draft awhile back and didn't cover the=20 return home scenario as it's not common. For Enterprise, DHCP using existing draft=20 would work. Typically SPs don't need to have MNs return home. We welcome inputs for ideas such as HALR/HALG for solutions there. :) Kent At 11:50 AM 3/29/2004 +0200, Hans Sj=F6strand wrote: >Alan, > >=CD agree that there might in some scenarios be nive to add address=20 >allocation lifetimes to Home Agent implementations, especially in the=20 >cases where the home agent for some reason maintain an address pool. In=20 >these scenarious it might be whise to do a extension to mobile IP to=20 >perform address management. This is best started with a draft and then the= =20 >WG will decide if it's worthwhile work to take on. > >But to state saying that 3344 or even worse, Mobiel IP, is broken because= =20 >there are no address lifetime management specified is going to far. I=20 >tried to explain that how the home agent allocates a address to the MN as= =20 >the MN home address is not at all a business for the Mobilr IP protocool. > >An example > >Mobile IP should handle that computers can roam away from the home=20 >network, and still maintain all that it could do before. But not more! A=20 >computer that is turned on on a local LAN most often uses DHCP is dynamic= =20 >address allocation is used in that LAN environment. The sysadmin has=20 >decided a lease time for these, quite common is one hour. So, the computer= =20 >gets a lease for 1 hour, and must make sure that it's renewed before that= =20 >expires if the computer intends to continiue using it. Note that the DHCP= =20 >server *does not* arp to make sure that the computer still are out there=20 >and alive, and very seldom does the computer leave back the lease to the=20 >server before it expires. > >Add mobile IP to this, Now we have a MN thats booted somewhree in the=20 >world, he registeres with it's HA. The HA must now make sure that it=20 >allocates a address to this MN, and that the HA maintains that address=20 >aslong as the MN is registerd with the HA. Thats his task. His task *is=20 >not" to leave back the IP address to the DHCP server if the session is= ended. > >When/if the MN returns home, the MN deregisteres with the HA and thereby=20 >releving the HA from it's task to maintain the address and now takes=20 >responsibility to maintain it himself. > >This quite clearly illustrate that there are no need to have any more=20 >explicit adress management build into Mobile IP. There is no connectno=20 >between teh lifetime of the binding, adn the lifetime of the lease. How a= =20 >HA allocates addresses are deployment specific. RFCF3344 should not / need= =20 >not to be burdend by it. The HA implementation of course needs to be=20 >burdend with it, but thats a different thing. > >Unfortunately I haven't had time to read Naveen PaulKandasamy and Kent=20 >Leung's draft about this. Hopefull it is compatible with what I wrote ;-) > >Regards >/// Hasse > > >O'Neill Alan wrote: > >>Ok so I am hoping to clarify some of the alternative interpretations of >>RFC3344bis, that I think we have discussed wrt dynamic HoA allocation,= given >>that RFC3344bis is mute on the point. >> >>------------------------- >> >>1) The first interpretation is that the address allocation lifetime in >>RFC3344bis is not tied to the binding lifetime, and by default is= UNDEFINED >>(static=3Dinfinity until otherwise defined ?). Hence when the MN returns= home >>and cancels a binding then the packets remain deliverable because the MN >>still has the address. This means that RFC3344bis does not deliver an= address >>life-time, and Charlie feels any such lifetime is out of scope of= RFC3344bis. >>I am not sure how many products interpret RFC3344bis this way. >> >>FIX to RFC3344bis: So to fully support this interpretation in RFC3344bis, >>some text needs to be added into to state this clearly. >> >>Future Work outside of RFC3344bis: The additional work here then is define >>how the address lifetime moves from UNDEFINED to DEFINED, and the address >>subsequently recovered so that the HA can reallocate safely. This could= use >>MIP or non-MIP mechanisms. >> >>----------------------- >> >>2) An alternative view is that the default address lifetime is equal to= the >>MIP binding lifetime, such that the HA recovers the dynamically assigned= HoA >>on binding cessation. This works fine for virtual home networks (ie >>cellular), such that the MN cannot return home and lose its address >>prematurely. However, if a real home can be visited (such as enterprise)= then >>we have the forced in-session address deallocation problem on binding >>cessation. I do know of MIP products that ship today that employ this >>interpretation of RFC3344bis. >> >>FIX to RFC3344bis: So to fully support this interpretation in RFC3344bis, >>some text needs to be added to state this clearly, clearly indicating that >>the address is deallocated automatically on returning home. >> >>Future Work outside of RFC3344bis: In addition, some additional work then >>needs to occur to address the uncontrolled address deallocation problem= when >>returning to real home networks, which for example could use the HALR/HALG >>model. The interop with non_MIP address management mechanisms would also= be >>useful here. >> >>--------------------- >> >>3) A third interpretation is not to interpret. By this I mean that= RFC3344bis >>leaves the address lifetime as UNDEFINED with no explanation, and hence= some >>systems can make it static whilst others can make the address lifetime= equal >>to the MIP lifetime. >> >>FIX: Do nothing and wait for interop problems before fixing which I assume >>no-one wants. >> >>---------------------- >> >>A Personal Opinion >> >>So I am generally troubled by RFC3344bis going ahead with interpretation= 1, >>given that it defines an incomplete entity lifecycle for a commercially >>valuable entity. >>I also feel that the default lifetime in RFC3344bis (MIP lifetime v >>UNDEFINED) should be representative of the major usage case, with future= work >>adding refinements via extensions such as HALR/HALG, and other non-MIP >>mechanisms. I know of a significant requirement for dynamic address= lifetimes >>that are tied to the MIP session duration, because operators want to >>statistically multiplex the address block across the MN population, and to= be >>able to recover addresses on MN failures (after MIP time-out). >>Personally, I cannot envisage a substantial requirement for dynamic= address >>allocation with UNDEFINED (static) lifetimes, given the dominant need for >>statistical reallocation. However, if we do have a significant installed= base >>of, or requirement for, interpretation 1 in RFC3344bis, then I guess the= wg >>needs to consider this (info/views?), and then maybe we have to rely on >>HALR/HALG type stuff even for the common case of address lifetime=3Dbindin= g >>lifetime. >> >>Alan. >> >> >>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D >>This email may contain confidential and privileged material for the sole >>use of the intended recipient. Any review or distribution by other is=20 >>strictly prohibited. If you are not the inteded recipient please contact >>the sender and delete all copies. >>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D >> >> >> > > >-- >Mip4 mailing list: Mip4@ietf.org > Web interface: https://www.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html >Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Tue Mar 30 03:28:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07603 for ; Tue, 30 Mar 2004 03:28:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8EbS-0000qR-UM for mip4-archive@odin.ietf.org; Tue, 30 Mar 2004 03:28:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2U8SASi003244 for mip4-archive@odin.ietf.org; Tue, 30 Mar 2004 03:28:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8EbS-0000qF-D4 for mip4-web-archive@optimus.ietf.org; Tue, 30 Mar 2004 03:28:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07585 for ; Tue, 30 Mar 2004 03:28:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8EbQ-0001x0-00 for mip4-web-archive@ietf.org; Tue, 30 Mar 2004 03:28:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8EaQ-0001nj-00 for mip4-web-archive@ietf.org; Tue, 30 Mar 2004 03:27:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B8EZP-0001eS-00 for mip4-web-archive@ietf.org; Tue, 30 Mar 2004 03:26:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8EZO-0000aF-Ve; Tue, 30 Mar 2004 03:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8EYq-0000Z8-8S for mip4@optimus.ietf.org; Tue, 30 Mar 2004 03:25:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07489 for ; Tue, 30 Mar 2004 03:25:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8EYn-0001Wp-00 for mip4@ietf.org; Tue, 30 Mar 2004 03:25:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8EXk-0001NJ-00 for mip4@ietf.org; Tue, 30 Mar 2004 03:24:21 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B8EXC-0001Ci-00 for mip4@ietf.org; Tue, 30 Mar 2004 03:23:46 -0500 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 30 Mar 2004 03:23:12 -0500 Content-Class: urn:content-classes:message Subject: RE: [Mip4] NAI-based dynamic home address assignment draft Date: Tue, 30 Mar 2004 03:23:14 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: [Mip4] NAI-based dynamic home address assignment draft X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcQS1+JUo689cTGhQIShDNKA6a0+LQDSe90w From: "O'Neill Alan" To: X-OriginalArrivalTime: 30 Mar 2004 08:23:12.0093 (UTC) FILETIME=[3D9988D0:01C41630] Content-Transfer-Encoding: quoted-printable Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Naveen, Kent. So I read the draft and think the HA processing is great given present circumstances. One aspect of the model I didn't like was having both a = Static and Dynamic MN Capability. I would rather we had one Dynamic MN = Capability, that distances us from RFC2794 and RFC3344. This then leaves knowledge = of the addressing policy for each MN on the HA, eliminates some error cases, = and enables static and dynamic addresses to converge as a dynamic address = with a lease-time between; =20 0(address release)...X(dynamic)...infinity(static). The impact of this direction on your model is shown in the converged = table below, where D1-7 are your dynamic cases from section 6.1, and S1-3 are = the static cases from section 6.2. The table is a slight rearrangement of = those in the draft so that binding state and addressing state in the HA are = clearly separated. Note that I modified S2/D2 cases so that the HoA is described = as being assigned to a different NAI rather than a different MN, due to the potentially multiplicity of mappings between MNs and NAIs).=20 In this table, if there is a binding (NAI,HoA) then by definition the = HoA is assigned to that NAI for some lease-time (not shown) which for present implementations is equal to either the binding lifetime (dynamic) or = infinity (static). I hope this table shows how the two models come together = nicely. +----------+----------------+---------------------------+------+=20 | MIP RREQ |HA Binding State|HA Address Management State| Case | +----------+----------------+---------------------------+------+=20 | | | RREQ(HoA) is Unassigned | D1 |=20 | | +---------------------------+------+=20 | | | RREQ(HoA) Not Allowed | |=20 | | | OR | D2 |=20 | | No Binding | RREQ(HoA) is assigned to | S2 |=20 | | for RRQ(NAI) | a different NAI | |=20 | | +---------------------------+------| |RREQ(NAI, | | RREQ(HoA) is | S1 | | HoA) | | assigned to RREQ(NAI) | | | +----------------+---------------------------+------+=20 | |RRQ(NAI,HoA) =3D=3D | RREQ(HoA) is | D3 = |=20 | |Binding(NAI,HoA)| assigned to RREQ(NAI) | S1 |=20 | +----------------+---------------------------+------+=20 | | RRQ(NAI) =3D=3D | RRQ(HoA) is Unassigned | D4 = |=20 | | Binding(NAI) | | S2 | | | && +---------------------------+------+=20 | | RRQ(HoA) !=3D | RREQ(HoA) Not Allowed | | | | Binding(HoA) | OR | D5 | | | | RRQ(HoA) is assigned to | S2 |=20 | | | a different NAI | |=20 +----------+----------------+---------------------------+------+ | | | A HoA is | D6 |=20 | | No Binding | assigned to RREQ(NAI) | S3 |=20 | | for RRQ(NAI) +---------------------------+------| | | | No HoA is | D6 | |RREQ(NAI, | | assigned to RREQ(NAI) | S3 |=20 | 0.0.0.0) +----------------+---------------------------+----- +=20 | | RRQ(NAI) =3D=3D | | = | | | Binding(NAI) | Binding(HoA) is | D7 | | | with | assigned to RREQ(NAI) | S3 | | | Binding(HoA) | | | +----------+----------------+---------------------------+------+ In particular, note that S3 still crops up in all cases of RREQ(0.0.0.0) = when the MN is able to include the Static MN Capability as per the existing = draft. Now I would suggest we get the following benefits with a single Dynamic = MN Capability, as shown in the following table extract update, which also = aligns quite nicely with being 'liberal in what you receive'. It is assumed = here that we are replacing the static procedure (S1-S3) with the equivalent dynamic procedure | | | A HoA is | D6 |=20 | | No Binding | assigned to RREQ(NAI) | |=20 | | for RRQ(NAI) +---------------------------+------| | | | No HoA is | D6 | |RREQ(NAI, | | assigned to RREQ(NAI) | |=20 | 0.0.0.0) +----------------+---------------------------+----- +=20 | | RRQ(NAI) =3D=3D | | = | | | Binding(NAI) | Binding(HoA) is | D7 | | | with | assigned to RREQ(NAI) | | | | Binding(HoA) | | | +----------+----------------+---------------------------+------+=20 We can now get the MN connected by resorting to S1=3D=3DD6 behaviour = instead of S3 behaviour, if a HoA is assigned (ie MN should have sent RREQ(HoA)). Similarly, we can get the MN connected by resorting to D6/D7 instead of = S3, if no HoA is assigned (because with no Static MN Capability, the RREQ(0.0.0.0) is always valid and we rely on the HA policy to merely = control the lease-time granted. Essentially, we have stripped out a number of = error cases in the merge because now the parameters in the RREQ() can now = never internally conflict, and are less likely to conflict with the HA address management state/policy. In the case of the lease-time =3D binding lifetime (ie no HALG = extension), then the MN knows it got a dynamic address. With a HALG included, the MN gets = to know that it has a lease-time greater than the MIP binding, potentially including an infinite lifetime (static), and could also be told how to release the static address (ie HALR) and how to maintain the address on returning home (ie DHCP v HALR v etc). Having the distinction made in = the downlink rather than uplink signaling is preferable on wireless links = due to the asymmetry, and avoiding RREQ() refusals is also generally preferable = to avoid connectivity delays and wasted air-link resources. I am still checking the impact on all your signaling cases to make sure = I haven't lost something important, so if you can see them more quickly = then please save me the effort. But I would appreciate your thoughts on the = model ? Alan. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is=20 strictly prohibited. If you are not the intended recipient please = contact the sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Tue Mar 30 03:29:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07672 for ; Tue, 30 Mar 2004 03:29:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8EcL-0000si-Jf for mip4-archive@odin.ietf.org; Tue, 30 Mar 2004 03:29:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2U8T5FB003382 for mip4-archive@odin.ietf.org; Tue, 30 Mar 2004 03:29:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8EcL-0000sT-FU for mip4-web-archive@optimus.ietf.org; Tue, 30 Mar 2004 03:29:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07621 for ; Tue, 30 Mar 2004 03:29:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8EcJ-00025p-00 for mip4-web-archive@ietf.org; Tue, 30 Mar 2004 03:29:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8EbI-0001w2-00 for mip4-web-archive@ietf.org; Tue, 30 Mar 2004 03:28:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B8EaJ-0001m8-00 for mip4-web-archive@ietf.org; Tue, 30 Mar 2004 03:26:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8EaL-0000fe-JQ; Tue, 30 Mar 2004 03:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8EZZ-0000bF-Dn for mip4@optimus.ietf.org; Tue, 30 Mar 2004 03:26:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07510 for ; Tue, 30 Mar 2004 03:26:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8EZX-0001fh-00 for mip4@ietf.org; Tue, 30 Mar 2004 03:26:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8EYq-0001XH-00 for mip4@ietf.org; Tue, 30 Mar 2004 03:25:28 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B8EY2-0001LQ-00 for mip4@ietf.org; Tue, 30 Mar 2004 03:24:38 -0500 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 30 Mar 2004 03:24:06 -0500 Content-Class: urn:content-classes:message Subject: RE: [Mip4] RFC3344biz Dynamic HoA bug ? Date: Tue, 30 Mar 2004 03:24:09 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: [Mip4] RFC3344biz Dynamic HoA bug ? X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcQV6Y1Xg/d0PT5MTRKMiWrf3pTEyQAP6/Gw From: "O'Neill Alan" To: X-OriginalArrivalTime: 30 Mar 2004 08:24:06.0483 (UTC) FILETIME=[5E04CA30:01C41630] Content-Transfer-Encoding: quoted-printable Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable -----Original Message----- From: mip4-admin@ietf.org [mailto:mip4-admin@ietf.org] On Behalf Of Kent Leung Sent: Tuesday, March 30, 2004 9:24 AM To: Hans Sj=F6strand Cc: O'Neill Alan; mip4@ietf.org Subject: Re: [Mip4] RFC3344biz Dynamic HoA bug ? Here are my 2 cents .. :) AWO> Fine with that. I think since specification does not cover how address management works, = it shouldn't be required to cover what's wrong with it. AWO> So it sounds like your saying option 3 for now wrt RFC3344, and we define address management in another doc, along the lines of the new = draft. I am fine with that, possibly with a bit of warning text in RFC3344bis = that says it does not include address management? To support an address management function, here are some common = scenarios. AWO> Happy with the options. Unfortunately, we had written our draft awhile back and didn't cover the = return home scenario as it's not common. For Enterprise, DHCP using = existing draft would work. Typically SPs don't need to have MNs return home. =20 AWO> Understood. We welcome inputs for ideas such as HALR/HALG for solutions there. :) AWO> Well we have bits of it already, and I'll submit the rest once we = have a better idea of how it fits with the new draft. Kent =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is=20 strictly prohibited. If you are not the intended recipient please = contact the sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Tue Mar 30 03:30:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07713 for ; Tue, 30 Mar 2004 03:30:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8EdK-0000vi-RB for mip4-archive@odin.ietf.org; Tue, 30 Mar 2004 03:30:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2U8U60j003568 for mip4-archive@odin.ietf.org; Tue, 30 Mar 2004 03:30:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8EdK-0000vT-NN for mip4-web-archive@optimus.ietf.org; Tue, 30 Mar 2004 03:30:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07693 for ; Tue, 30 Mar 2004 03:30:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8EdI-0002ED-00 for mip4-web-archive@ietf.org; Tue, 30 Mar 2004 03:30:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8EcH-00025h-00 for mip4-web-archive@ietf.org; Tue, 30 Mar 2004 03:29:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B8EbH-0001sm-00 for mip4-web-archive@ietf.org; Tue, 30 Mar 2004 03:27:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8EbI-0000ln-Jf; Tue, 30 Mar 2004 03:28:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Eac-0000ja-Bg for mip4@optimus.ietf.org; Tue, 30 Mar 2004 03:27:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07560 for ; Tue, 30 Mar 2004 03:27:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8Eaa-0001p3-00 for mip4@ietf.org; Tue, 30 Mar 2004 03:27:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8EZY-0001g0-00 for mip4@ietf.org; Tue, 30 Mar 2004 03:26:13 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B8EZ3-0001Ur-00 for mip4@ietf.org; Tue, 30 Mar 2004 03:25:41 -0500 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 30 Mar 2004 03:25:12 -0500 Content-Class: urn:content-classes:message Subject: RE: [Mip4] RFC3344biz Dynamic HoA bug ? Date: Tue, 30 Mar 2004 03:25:15 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: [Mip4] RFC3344biz Dynamic HoA bug ? X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcQV6Y1Xg/d0PT5MTRKMiWrf3pTEyQAQJybQ From: "O'Neill Alan" To: X-OriginalArrivalTime: 30 Mar 2004 08:25:12.0874 (UTC) FILETIME=[859740A0:01C41630] Content-Transfer-Encoding: quoted-printable Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Hans, I certainly didn't mean to imply in any way that MIP is broken for all = the reasons you state. My comments are specifically related to the dynamic address assignment text in RFC3344bis. At 11:50 AM 3/29/2004 +0200, Hans Sj=F6strand wrote: >Alan, > >=CD agree that there might in some scenarios be nive to add address=20 >allocation lifetimes to Home Agent implementations, especially in the=20 >cases where the home agent for some reason maintain an address pool. In = >these scenarious it might be whise to do a extension to mobile IP to=20 >perform address management. This is best started with a draft and then = the=20 >WG will decide if it's worthwhile work to take on. > >But to state saying that 3344 or even worse, Mobiel IP, is broken = because=20 >there are no address lifetime management specified is going to far. I=20 >tried to explain that how the home agent allocates a address to the MN = as=20 >the MN home address is not at all a business for the Mobilr IP = protocool. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is=20 strictly prohibited. If you are not the intended recipient please = contact the sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Tue Mar 30 17:41:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19024 for ; Tue, 30 Mar 2004 17:41:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rjk-0006WI-0A for mip4-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IFRwJZ004243 for mip4-archive@odin.ietf.org; Wed, 18 Feb 2004 10:27:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTc9-00010B-Nh for mip4-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 10:27:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20728 for ; Wed, 18 Feb 2004 10:27:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtTbo-0001ZT-00 for mip4-web-archive@ietf.org; Wed, 18 Feb 2004 10:27:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtTat-0001Qp-00 for mip4-web-archive@ietf.org; Wed, 18 Feb 2004 10:26:36 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AtTa5-0001I8-00 for mip4-web-archive@ietf.org; Wed, 18 Feb 2004 10:25:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AtTZs-0005p8-JE for mip4-web-archive@ietf.org; Wed, 18 Feb 2004 10:25:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTZS-0008Ma-G8; Wed, 18 Feb 2004 10:25:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTZJ-0008Iq-CO for mip4@optimus.ietf.org; Wed, 18 Feb 2004 10:24:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20259 for ; Wed, 18 Feb 2004 10:24:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtTZH-0001B2-00 for mip4@ietf.org; Wed, 18 Feb 2004 10:24:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtTYC-0000xt-00 for mip4@ietf.org; Wed, 18 Feb 2004 10:23:48 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AtTX3-0000kd-00 for mip4@ietf.org; Wed, 18 Feb 2004 10:22:37 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i1IFMRGv020843; Thu, 19 Feb 2004 00:22:27 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i1IFMRTJ027661; Thu, 19 Feb 2004 00:22:27 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id AAA27660 ; Thu, 19 Feb 2004 00:22:27 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id AAA19331; Thu, 19 Feb 2004 00:22:26 +0900 (JST) Received: by toshiba.co.jp id AAA28994; Thu, 19 Feb 2004 00:22:25 +0900 (JST) Message-Id: <200402181522.AAA28994@toshiba.co.jp> Date: Thu, 19 Feb 2004 00:22:16 +0900 From: Yoshiyuki Tsuda Subject: Re: [Mip4] WG Last call on draft-ietf-mip4-dynamic-assignment-00.txt (SECOND REQUEST) To: Henrik Levkowetz Cc: Pete McCann , Alpesh , mip4@ietf.org Organization: Corporate R&D Center, Toshiba Corporation In-Reply-To: <20040218145035.38e8c877.henrik@levkowetz.com> References: <20040213193509.16ac6bd4.henrik@levkowetz.com> <16433.18709.548019.259179@gargle.gargle.HOWL> <20040217015137.0eb79e44.henrik@levkowetz.com> <16434.19604.320288.837012@gargle.gargle.HOWL> <20040218145035.38e8c877.henrik@levkowetz.com> X-Mailer: Datula version 1.51.08.01 for Windows Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hello Henrik, Here, I have just one comment: at Wed, 18 Feb 2004 14:50:35 +0100 Henrik Levkowetz wrote: >Yes. What with the NAI having its own extension, I don't have any >example right now which I'd want to promote ... unless maybe the >home network prefix. That really belongs with dynamic home address >assignment rather than dynamic ha assignment, but it's part of the >same area of functionality; and we don't have a way today to inform >the MN of the appropriate netmask - or alternatively the private-side >HA interface address - or whatever other way of identifying the home >network people have implemented. About the netmask, an MN can extract the home subnet prefix by the following way: - Mobility Agents are assumed to advertise correct subnet prefix to their connected subnets. - An MN with dynamic home address compares it with the current subnet address and prefix. If the home address is within the current subnet, the MN can extract that the home prefix is the current prefix. - Before the MN encounters its home subnet, the MN should assume its home prefix is 32. Our MN has the above function, and is working. :) Thanks. -Yoshi -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Mar 30 17:56:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21732 for ; Tue, 30 Mar 2004 17:56:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rjd-0006ZK-Bk for mip4-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CLQe6C007730 for mip4-archive@odin.ietf.org; Fri, 12 Mar 2004 16:26:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1uAy-00020b-Be for mip4-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 16:26:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19384 for ; Fri, 12 Mar 2004 16:26:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1uAw-0000Hh-00 for mip4-web-archive@ietf.org; Fri, 12 Mar 2004 16:26:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1u9i-00003L-00 for mip4-web-archive@ietf.org; Fri, 12 Mar 2004 16:25:24 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B1u8r-0007fj-00 for mip4-web-archive@ietf.org; Fri, 12 Mar 2004 16:24:29 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B1u8r-00089y-P8 for mip4-web-archive@ietf.org; Fri, 12 Mar 2004 16:24:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1u8i-0000of-UV; Fri, 12 Mar 2004 16:24:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1twX-0000IB-97 for mip4@optimus.ietf.org; Fri, 12 Mar 2004 16:11:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18704 for ; Fri, 12 Mar 2004 16:11:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1twV-0006VU-00 for mip4@ietf.org; Fri, 12 Mar 2004 16:11:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1tvf-0006OZ-00 for mip4@ietf.org; Fri, 12 Mar 2004 16:10:52 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1B1tuo-000672-00 for mip4@ietf.org; Fri, 12 Mar 2004 16:09:58 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i2CL9EK04078; Fri, 12 Mar 2004 13:09:14 -0800 X-mProtect: <200403122109> Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdBXzxiD; Fri, 12 Mar 2004 13:09:12 PST Message-ID: <405226EE.BB7EB769@iprg.nokia.com> Date: Fri, 12 Mar 2004 13:09:02 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Pete McCann CC: mip4@ietf.org Subject: Re: [Mip4] [Issue 20] Missing description - FA rejection code whenMN-HA auth.ext.invalid References: <401834B5.B0438217@iprg.nokia.com> <16414.57643.587441.82950@gargle.gargle.HOWL> <401EE6DA.4030103@iprg.nokia.com> <16414.59273.36441.23322@gargle.gargle.HOWL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello folks, I am in the process of attending to all remaining comments for the rfc3344bis document, so that I can go ahead and send in the new draft. With the submission of the "faerr" document, draft-perkins-mip4-faerr-00.txt I propose that this issue be marked as "closed". The only remaining point is whether or not the "faerr" document should be mentioned within rfc3344bis. Overall, it seems to me that it should be as a normative reference, but then that introduces a dependency which may be unwanted. Regards, Charlie P. Pete McCann wrote: > > Hi, Charlie, > > Charles E. Perkins writes: > > > > Hello Pete, > > > > There are two separate issues that could be discussed: > > > > - What happens if the FA _knows_ that the Registration Request > > is guaranteed to be rejected because there isn't any MN-HA > > extension? > > I agree this aspect should be rejected. We should not have the FA > checking extensions for which it is not responsible. > > > - What happens when the FA wants to insert an error code into > > a Registration Reply? > > > > The latter question should be answered by the FA error extension > > draft which is, I think, basically about done and ready to be > > disseminated as a new Internet Draft. > > Yup. > > -Pete > > > Regards, > > Charlie P. > > > > > > Pete McCann wrote: > > > > >I re-read the issue and I don't understand what it is saying. I think > > >it may have been mistakenly attributed to me or incorrectly > > >transcribed. > > > > > >I think it is fine to reject this, barring a more cogent statement of > > >the issue. Maybe it had something to do with the FA modifying > > >rejection codes, interfering with the MN-HA authentication extension, > > >which is the topic of the new draft you are working on. > > > > > >-Pete > > > > > > > > >Charles E. Perkins writes: > > > > > > > > Hello folks, > > > > > > > > Please refer to previous discussion at the following URL: > > > > http://www.mip4.org/issues/tracker/mip4/issue20 > > > > as necessary. > > > > > > > > The suggestion was to mandate some action on the part of > > > > a foreign agent if no MN-HA authentication extension is > > > > present. Presumably, this really means, to reject in case > > > > there is no authorization-enabling extension. But this > > > > should anyway be a rare case, and there is little danger > > > > since the home agent or other authorizing agent will > > > > reject the Request. > > > > > > > > I propose that no action be taken, and that the > > > > suggestion to change the specification be rejected. > > > > > > > > Comments? > > > > > > > > Regards, > > > > Charlie P. > > > > > > > > -- > > > > Mip4 mailing list > > > > Mip4@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mip4 > > > > > > > > > > > > > > > > -- > Mip4 mailing list > Mip4@ietf.org > https://www.ietf.org/mailman/listinfo/mip4 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Tue Mar 30 17:59:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22698 for ; Tue, 30 Mar 2004 17:59:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rjb-0006a4-J3 for mip4-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MMc00g003188 for mip4-archive@odin.ietf.org; Mon, 22 Mar 2004 17:38:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Y3P-0000p1-Jd for mip4-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 17:37:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29870 for ; Mon, 22 Mar 2004 17:37:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5Y3F-0001nd-00 for mip4-web-archive@ietf.org; Mon, 22 Mar 2004 17:37:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5Y2O-0001hd-00 for mip4-web-archive@ietf.org; Mon, 22 Mar 2004 17:36:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5Y1Y-0001bj-00 for mip4-web-archive@ietf.org; Mon, 22 Mar 2004 17:36:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Y1Z-0000Tm-SL; Mon, 22 Mar 2004 17:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Y1T-0000Su-My for mip4@optimus.ietf.org; Mon, 22 Mar 2004 17:35:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29748 for ; Mon, 22 Mar 2004 17:35:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5Y1R-0001aX-00 for mip4@ietf.org; Mon, 22 Mar 2004 17:35:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5Y0Y-0001Tn-00 for mip4@ietf.org; Mon, 22 Mar 2004 17:34:59 -0500 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1B5Xzs-0001KU-00 for mip4@ietf.org; Mon, 22 Mar 2004 17:34:16 -0500 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2MMXMZ27052; Mon, 22 Mar 2004 16:33:23 -0600 (CST) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id i2MMXL312707; Mon, 22 Mar 2004 16:33:21 -0600 (CST) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HV01AF-0001QG-00; Mon, 22 Mar 2004 17:32:39 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16479.27017.343035.61958@gargle.gargle.HOWL> Date: Mon, 22 Mar 2004 16:32:41 -0600 From: Pete McCann To: "O'Neill Alan" Cc: "Kent Leung" , Subject: RE: [Mip4] [issue44] RFC 3344 - Source Address of the RRQ & FHAE issues In-Reply-To: References: X-Mailer: VM 7.14 under 21.5 (beta14) "cassava" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, [sorry about my long absence from the thread; was traveling all last week] Kent, I think your response last week convinced me that ignoring the R bit is not a good idea, and I agree that the HA should check the FHAE, if it is present, and discard the message if it doesn't check. It also seems like the cleanest solution to the NAT traversal problem is to encode the identities of the FA and HA (probably using NAI format) in Mobile IP extensions, and to use these identities to index security associations. There is some precedent for this in the MN-AAA extension, when used with the MN NAI extension and all-zero IP source address. I also agree with Alan that the restriction on the RRQ source IP address made in 3519 is not ideal, and that we shouldn't require this in the base protocol. However, we need to figure out how to get from where we are now to the ideal case. It sounds like there were different opinions on whether a NAT traversal fix of some sort (new extension) should go into the base protocol or into a new document. I tend to come out on the side of a new document, and to let the sleeping dog (NAT traversal) lie for now with the current IP-address-indexed SAs and the band-aid solution given in 3519. This is based on a desire to get 3344 done without too many fundamental changes, although I am not sure that even now we can go directly to Draft Standard with the changes we have made so far. It is also based on my own old-fashioned bias that IP protocols shouldn't have to take NATs into account during their design; rather, it should be the other way around. If someone wants to put together a new document on Mobility Agent Identifier extensions I think that would be a good idea. In that document, we could make changes to the way that SAs are indexed in a way that is robust against all forms of NAT. Does anyone feel really strongly that we need to make this change now in the 3344bis document? -Pete O'Neill Alan writes: > Hi Kent, > > -----Original Message----- > From: Kent Leung [mailto:kleung@cisco.com] > > What is meant by "signed"? Implying FHAE protected or some > FA signature in the extension? A bit more clarification would help. > > AWO> Yes - FHAE protected was the assumption if one exists. > > Let's say there is no pre-existing SA between FA and HA. How > is the extension protected? > > AWO> Thinking as I write (which is often inadvisable at 8.30pm), it may well > be, that in principle, given that this extension is only used in a comparison > with the unprotected packet source address, that it might be ok to leave > unsigned because whilst a fraudulent delta could be created by a MiTM by > modifying the extension, they could just as easily create that delta with a > signed version, simply by changing the unprotected packet source address. We > should think about that aspect a lot more though I agree. > > It's a good idea. But I assumed that this was not used because the > FA cannot add extensions without FHAE to protect the message? > So as long as we have a method to protect this new extension, I'm > fine with it since it meets our requirement for an FA identifier for the > FHAE authentication. > > AWO> Ok - that's good. > > Though using FA NAI has the advantage of minimizing SA entries on > HA. There would be one SA for FA, regardless how many CoA or > source IP addresses used in the registration request. I'm sure not > everyone will agree that it's a good thing. :) > > AWO> I was primarily keen to push back on the FA CoA nailing, and an FHAE > identification solution potentially falls out as well. However, I can > certainly see the benefit of your scheme for the FHAE issue. > > Alan -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Tue Mar 30 18:01:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23205 for ; Tue, 30 Mar 2004 18:01:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rja-0006a4-I4 for mip4-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CLQmM3007765 for mip4-archive@odin.ietf.org; Fri, 12 Mar 2004 16:26:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1uB6-00021A-Fv for mip4-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 16:26:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19404 for ; Fri, 12 Mar 2004 16:26:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1uB4-0000JJ-00 for mip4-web-archive@ietf.org; Fri, 12 Mar 2004 16:26:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1u9o-00004V-00 for mip4-web-archive@ietf.org; Fri, 12 Mar 2004 16:25:30 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B1u8t-0007gD-00 for mip4-web-archive@ietf.org; Fri, 12 Mar 2004 16:24:32 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B1u8t-00089z-Hz for mip4-web-archive@ietf.org; Fri, 12 Mar 2004 16:24:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1u8h-0000oI-IZ; Fri, 12 Mar 2004 16:24:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1tls-000880-NR for mip4@optimus.ietf.org; Fri, 12 Mar 2004 16:00:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18267 for ; Fri, 12 Mar 2004 16:00:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1tlr-00055C-00 for mip4@ietf.org; Fri, 12 Mar 2004 16:00:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1tku-0004zH-00 for mip4@ietf.org; Fri, 12 Mar 2004 15:59:45 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1B1tke-0004tL-00 for mip4@ietf.org; Fri, 12 Mar 2004 15:59:28 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i2CKwFn16807; Fri, 12 Mar 2004 12:58:15 -0800 X-mProtect: <200403122058> Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdEFyu0h; Fri, 12 Mar 2004 12:58:11 PST Message-ID: <40522457.A2FEA127@iprg.nokia.com> Date: Fri, 12 Mar 2004 12:57:59 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Henrik Levkowetz , Pete McCann CC: mip4@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip4] Request to onsider "faerr" specification as a working group document Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello folks, I have submitted the following document, "Foreign Agent Error Extension for Mobile IPv4", draft-perkins-mip4-faerr-00.txt, previous to the last IETF as a proposal for solving some problems raised in issues 9, 18, and 20 (see http://www.mip4.org/issues/tracker/mip4/). I would like to request that this document be considered as a working group document. Regards, Charlie P. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Tue Mar 30 18:13:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26650 for ; Tue, 30 Mar 2004 18:13:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjU-0006ZK-5l for mip4-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PEAPXs028283 for mip4-archive@odin.ietf.org; Thu, 25 Mar 2004 09:10:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VYu-0007Lp-Qz for mip4-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 09:10:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21739 for ; Thu, 25 Mar 2004 09:10:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6VYt-0006IA-00 for mip4-web-archive@ietf.org; Thu, 25 Mar 2004 09:10:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6VXj-000650-00 for mip4-web-archive@ietf.org; Thu, 25 Mar 2004 09:09:12 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6VWr-0005xA-00 for mip4-web-archive@ietf.org; Thu, 25 Mar 2004 09:08:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VWo-0006Fw-G5; Thu, 25 Mar 2004 09:08:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Rn5-0007n0-Qe for mip4@optimus.ietf.org; Thu, 25 Mar 2004 05:08:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12412 for ; Thu, 25 Mar 2004 05:08:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Rn2-0005XR-00 for mip4@ietf.org; Thu, 25 Mar 2004 05:08:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Rm7-0005Px-00 for mip4@ietf.org; Thu, 25 Mar 2004 05:07:48 -0500 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 1B6RlF-0005Fv-00 for mip4@ietf.org; Thu, 25 Mar 2004 05:06:53 -0500 Received: from ipunplugged.com (c40.local.ipunplugged.com [192.168.4.239]) by mailgw.local.ipunplugged.com (8.12.8/8.12.3) with ESMTP id i2PA6mvO006534; Thu, 25 Mar 2004 11:06:48 +0100 Message-ID: <4062AE89.4010607@ipunplugged.com> Date: Thu, 25 Mar 2004 11:03:53 +0100 From: =?ISO-8859-1?Q?Hans_Sj=F6strand?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: sv, en-us, en, ja MIME-Version: 1.0 To: "O'Neill Alan" CC: mip4@ietf.org Subject: Re: [Mip4] RFC3344biz Dynamic HoA bug ? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamd / ClamAV version 0.70rc, clamav-milter version 0.70 Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alan, I do agree that you have spotted a corner case and it's quite possibly are a worthwhile area to have a complementary RFC to describe a solution to. Also, your proposal sounds like a good starting point for such a draft. But I would like to add an alternative in terms of RFC3344bis progression since I think that this problem is not neccesarily linked into what 3344 should describe. The problem is more linked into how the HA allocates the home address for the MN. This is outside the scope 3344 since it may be a multitude of ways that all are deployment specific. E.g. DHCP server, WINS server, Radius Server, Active Directory or a local address pool, just to mention a some. It might be beneficial to add a explanatory text in some section that clarifies that the HA, in order to maintain the MN sessions in handovers to the home network, should allocate an address that the MN will maintain also when deregistered in the home network. Of course, the text should be written by someone more verbal and with better English than me. I believe your alternative 1 and 2 are destructive, since they break whats already are working out there, namely compliant implementations that handle roaming to the home network. Alternative 3 are a bad choice since it precludes the proper problem investigation and solution that a real draft would address. My suggested alternative is to do nothing to 3344bis, possibly with some explanatory text along the lines with the proposal in the previous section. Best regards /// Hasse O'Neill Alan wrote: >Wg, > >I think I may have discovered a hole / corner case in RFC3344biz, but I >thought a bit of discussion might be beneficial before putting it into the >tracker. > >A MN places 0.0.0.0 into the Home Address field of the RREQ to trigger >assignment by the Home Agent. The address allocation lifetime is assumed to >be the MIP binding lifetime because no other information exists, and >permanent allocations are of course not good. However, what then happens when >the MN returns home ? > >The MN cancels the binding, and according to the spec ceases to use MIP >signaling. However, if the address lifetime is tied to the binding lifetime >then the MN just lost its address. I assume this might not have been spotted >before because we are mostly focusing on cellular systems where the MN has a >virtual home network, and hence cannot ever get home, but given the scope of >RFC3344 this 'hole', if people concur, needs to be filled. The following >options spring to mind. > >a) We define a Home Address Lease Grant (HALG) Extension which is optionally >returned by the HA in addition to the binding lifetime. The extension >specifies an allocation lifetime that is greater than the binding lifetime >(clearly cannot be less, and there is no point using it, if it is equal). A >MN that returns home is then able to cancel its binding, but can maintain the >use of the home address to avoid session disruption. Specifically, one can >imagine the HA adding this extension during that deregistration. Note also >that this separation of binding lifetime from address allocation lifetime >also enables a MN to terminate MIP bindings in a foreign network (ie for >efficiency) yet still maintain the home address at the HA, so that it can >later restart MIP with the same HoA and HA. > >b) We might also want to consider defining a Home Address Lease Request >(HALR) Extension, with the MN requesting a lease-time and the HA reducing it >to an acceptable value, with lease termination being signaled by requesting a >zero lease-time (by analogy with binding lifetime processing). > >c) The MN could then continue to use MIP to refresh this home address lease >by periodically resending RREQs with binding CoA=HoA and lifetime=0, such >that the HA can then return a new lease. Alternatively, the MN can report, >and then maintain, the home address via DHCP (assuming some HA/DHCP back-end >link), with these two options (and maybe others) being distinguished by flags >in the HALG. > > > Now in terms of RFC3344biz progression, as a first alternative we >could minimally add clarification text that states that a MN that has been >dynamically assigned a Home Address via MIP, will explicitly lose that >address when it deregisters. This means that deregistered MNs that return >home cannot maintain sessions, and must then go to DHCP (or whatever) to get >a new address for local connectivity. Whilst non-ideal technically, it at >least lets RFC3344biz progress with clarity. We could then define HALG, HALR >and associated processing in a new document. > > The second alternative is to remove dynamic home address allocation >from RFC3344biz, and put that into the new doc along with the HALG and HALR >work, so that RFC3344biz does not go forward with the corner case of >returning home. > > The third option is to wrap the HALG, and minimal associated >processing, into RFC3344biz to support the MN returning home, and hence to >fix the corner case. The HALR can then be left to the new doc. > > The fourth option is of course that I am mistaken about the corner >case and we can all sleep soundly. > > >Thoughts ? > >Alan > > > > > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Tue Mar 30 18:27:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00519 for ; Tue, 30 Mar 2004 18:27:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjN-0006WI-Ad for mip4-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKGFABt020381 for mip4-archive@odin.ietf.org; Thu, 20 Nov 2003 11:15:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMrSW-0005F8-Fu for mip4-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 11:15:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11238 for ; Thu, 20 Nov 2003 11:14:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMrST-0005Ku-00 for mip4-web-archive@ietf.org; Thu, 20 Nov 2003 11:15:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMrST-0005Kr-00 for mip4-web-archive@ietf.org; Thu, 20 Nov 2003 11:15:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMrST-0005CV-4B; Thu, 20 Nov 2003 11:15:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMrS7-000593-C5 for mip4@optimus.ietf.org; Thu, 20 Nov 2003 11:14:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11220; Thu, 20 Nov 2003 11:14:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMrS6-0005KO-00; Thu, 20 Nov 2003 11:14:42 -0500 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 1AMrS5-0005Jm-00; Thu, 20 Nov 2003 11:14:41 -0500 Received: from zinfandel.local.ipunplugged.com (chardonnay.local.ipunplugged.com [192.168.4.44]) by mailgw.local.ipunplugged.com (8.12.8/8.12.3) with SMTP id hAKGE5EY032539; Thu, 20 Nov 2003 17:14:05 +0100 Date: Thu, 20 Nov 2003 17:14:04 +0100 From: Henrik Levkowetz To: Pete McCann Cc: , Subject: Re: [Mip6] RE: [Mip4] tying flow movement to MIP RE: [Mipshop] Minutes of Multiple Lin k Flows BAR BOF Message-Id: <20031120171404.42b90179.henrik@levkowetz.com> In-Reply-To: <16315.41760.686515.201908@gargle.gargle.HOWL> References: <9E3BA3946476AD4EB94672712B12A85F041FFC@ftmail.lab.flarion.com> <16312.64202.769515.896944@gargle.gargle.HOWL> <047301c3ad5e$285fe490$956015ac@dclkempt40> <20031118010124.4d89dabe.henrik@levkowetz.com> <16315.41760.686515.201908@gargle.gargle.HOWL> X-Mailer: Sylpheed version 0.9.5claws28 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Signature=_Thu__20_Nov_2003_17_14_04_+0100_Rf9e3aLmZ6B0nWkH" X-RAVMilter-Version: 8.4.4(snapshot 20030410) (mailgw.local.ipunplugged.com) Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , --Signature=_Thu__20_Nov_2003_17_14_04_+0100_Rf9e3aLmZ6B0nWkH Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit On Wednesday, 19 Nov 2003, Pete wrote: [...] > > > > I'm not at all sure that the reasoning about IPv4 address scarcity > > holds water. MIPv4 works with both HoAs and CoAs being private, behind > > NATs (even if we don't like'em... :) > > Yes, but we may need to solve this problem for public IPv4 addresses, > depending on the deployment scenarios. True. [...] > > > > I don't think we can assume neither that the same service provder is > > providing service on all CoAs, nor that there is only one HA. If public > > WLAN hotspots vs. cellular vs. corporate WLAN is a typical scenario, > > I'd say it's actually quite unlikely. > > I wasn't thinking of multiple service providers, I was just trying to > find a cheap and easy way to support multiple sessions even on a > single HA. The problem with a single NAI is that it becomes > impossible to distinguish a retransmission from a request for a new > session (IP home address). So we need something like a session ID, or > a convention for multiple sessions within the NAI namespace. Agreed. > Such a technique would also allow each flow to be homed on a different > home agent, as you point out, which might be needed for additional > flexibility. However, all the subsequent posts about HA redundancy, > etc, have gotten way off topic and are missing my point entirely. Yup. Henrik --Signature=_Thu__20_Nov_2003_17_14_04_+0100_Rf9e3aLmZ6B0nWkH Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/vOhMeVhrtTJkXCMRAjs8AKDr4Gz671Zy4MYgcju2Jux1UzXnaQCcCu/G PGwvY9awrT9KGctPPd8xcSM= =2cUO -----END PGP SIGNATURE----- --Signature=_Thu__20_Nov_2003_17_14_04_+0100_Rf9e3aLmZ6B0nWkH-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Mar 30 18:32:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01705 for ; Tue, 30 Mar 2004 18:32:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjH-0006a4-OX for mip4-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i259Pda8028664 for mip4-archive@odin.ietf.org; Fri, 5 Mar 2004 04:25:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzBaK-0007RN-IY for mip4-web-archive@optimus.ietf.org; Fri, 05 Mar 2004 04:25:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27682 for ; Fri, 5 Mar 2004 04:25:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzBa2-000192-00 for mip4-web-archive@ietf.org; Fri, 05 Mar 2004 04:25:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzBZ3-0000wA-00 for mip4-web-archive@ietf.org; Fri, 05 Mar 2004 04:24:18 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AzBYP-0000mN-00 for mip4-web-archive@ietf.org; Fri, 05 Mar 2004 04:23:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzBYP-0006xP-EX; Fri, 05 Mar 2004 04:23:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzAQT-0000De-UI for mip4@optimus.ietf.org; Fri, 05 Mar 2004 03:11:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25233 for ; Fri, 5 Mar 2004 03:11:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzAQP-0001pf-00 for mip4@ietf.org; Fri, 05 Mar 2004 03:11:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzAPS-0001fQ-00 for mip4@ietf.org; Fri, 05 Mar 2004 03:10:18 -0500 Received: from [147.6.42.145] (helo=filter1.kt.co.kr) by ietf-mx with esmtp (Exim 4.12) id 1AzAOm-0001Lg-00 for mip4@ietf.org; Fri, 05 Mar 2004 03:09:36 -0500 Received: from external ([147.6.24.123]) by filter1 (1.0) id i2588Xb62867; Fri, 05 Mar 2004 17:08:33 +0900 Message-ID: <006f01c40289$1ecd1b70$7b180693@yjtcha> From: "Yongjoo Tcha" To: Date: Fri, 5 Mar 2004 17:09:02 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006C_01C402D4.8EAD9780" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Mip4] Posting to mip4 mailing list Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.2 required=5.0 tests=AWL,HTML_50_60,HTML_MESSAGE, MIME_BASE64_TEXT autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_006C_01C402D4.8EAD9780 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SSB3YW50IHRvIHBvc3QgdG8gbWFpbGluZyBsaXN0Lg0KSSBhbHJlYWR5IHN1YnNjcmliZWQgdG8g bWlwNCBXRy4NCg0KY29uZmlybSA3NzM1NzkNCg0KVGhhbmsgeW91Lg0K ------=_NextPart_000_006C_01C402D4.8EAD9780 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA2LjAwLjI4MDAuMTQwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPkkgd2FudCB0 byBwb3N0IHRvIG1haWxpbmcgbGlzdC48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5J IGFscmVhZHkgc3Vic2NyaWJlZCB0byBtaXA0IFdHLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQg c2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+Y29uZmlybSA3NzM1Nzk8QlI+PC9ESVY+ DQo8RElWPjxGT05UIHNpemU9Mj5UaGFuayB5b3UuPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8 L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_006C_01C402D4.8EAD9780-- -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Tue Mar 30 18:41:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04193 for ; Tue, 30 Mar 2004 18:41:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rj9-0006WI-QB for mip4-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAIBa6qx024222 for mip4-archive@odin.ietf.org; Tue, 18 Nov 2003 06:36:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM49O-0006Ib-8H for mip4-web-archive@optimus.ietf.org; Tue, 18 Nov 2003 06:36:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16765 for ; Tue, 18 Nov 2003 06:35:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM49K-0003Fh-00 for mip4-web-archive@ietf.org; Tue, 18 Nov 2003 06:36:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AM49J-0003Fd-00 for mip4-web-archive@ietf.org; Tue, 18 Nov 2003 06:36:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM49K-0006HR-8j; Tue, 18 Nov 2003 06:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM497-0006Dr-It for mip4@optimus.ietf.org; Tue, 18 Nov 2003 06:35:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16722; Tue, 18 Nov 2003 06:35:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM493-0003Et-00; Tue, 18 Nov 2003 06:35:45 -0500 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=chardonnay) by ietf-mx with esmtp (Exim 4.12) id 1AM492-0003Ep-00; Tue, 18 Nov 2003 06:35:45 -0500 Received: from chardonnay ([127.0.0.1]) by chardonnay with smtp (Exim 3.36 #1 (Debian)) id 1AM45x-0000BC-00; Tue, 18 Nov 2003 12:32:33 +0100 Date: Tue, 18 Nov 2003 12:32:15 +0100 From: Henrik Levkowetz To: Soliman Hesham Cc: mip4@ietf.org, mip6@ietf.org Subject: Re: [Mip4] tying flow movement to MIP RE: [Mipshop] Minutes of Multiple Lin k Flows BAR BOF Message-Id: <20031118123215.37b8b7bc.henrik@levkowetz.com> In-Reply-To: <9E3BA3946476AD4EB94672712B12A85F041FFE@ftmail.lab.flarion.com> References: <9E3BA3946476AD4EB94672712B12A85F041FFE@ftmail.lab.flarion.com> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Signature=_Tue__18_Nov_2003_12_32_15_+0100_eqVtAg0_vzwl9R/." Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , --Signature=_Tue__18_Nov_2003_12_32_15_+0100_eqVtAg0_vzwl9R/. Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Monday 17 November 2003, Hesham wrote: > => Sure, I'm not sure what "less general" means though. I was refering back to what I wrote earlier in this thread: "The cost of this solution is in having to do re-registration of multiple sessions when you move, but such a cost is already implicit in the fact that with multiple connections through different connection media you have to be able to handle each media individually, whether it is by separate sessions or by filter adaptations. But I believe completely separate sessions will adapt better to any other non-movement-specific solution to multihoming that may appear." Henrik --Signature=_Tue__18_Nov_2003_12_32_15_+0100_eqVtAg0_vzwl9R/. Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/ugNNeVhrtTJkXCMRAmUGAJ9fAy/PtZRYbsZIwolA0Lksz03WagCfVWeJ pmULHS/dMexwvrUAc+Fcpfo= =aMyL -----END PGP SIGNATURE----- --Signature=_Tue__18_Nov_2003_12_32_15_+0100_eqVtAg0_vzwl9R/.-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Mar 30 18:42:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04321 for ; Tue, 30 Mar 2004 18:42:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rj7-0006ZK-3i for mip4-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKDLEgN000910 for mip4-archive@odin.ietf.org; Thu, 20 Nov 2003 08:21:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMokE-0000Eb-L7 for mip4-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 08:21:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03163 for ; Thu, 20 Nov 2003 08:21:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMokD-0002hv-00 for mip4-web-archive@ietf.org; Thu, 20 Nov 2003 08:21:13 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMokD-0002hr-00 for mip4-web-archive@ietf.org; Thu, 20 Nov 2003 08:21:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMok8-0000Du-MZ; Thu, 20 Nov 2003 08:21:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMoj5-0008O2-Nx for mip4@optimus.ietf.org; Thu, 20 Nov 2003 08:20:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03107 for ; Thu, 20 Nov 2003 08:19:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMoj4-0002gc-00 for mip4@ietf.org; Thu, 20 Nov 2003 08:20:02 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AMoj3-0002gY-00 for mip4@ietf.org; Thu, 20 Nov 2003 08:20:02 -0500 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAKDJxSs017927; Thu, 20 Nov 2003 14:20:00 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Thu, 20 Nov 2003 14:19:59 +0100 Message-ID: <37FB7AA6F5F9814FB634A7BF4C35A6F5639938@ESEALNT442.al.sw.ericsson.se> From: "Karim El-Malki (HF/EAB)" To: "'Pete McCann'" , mip4@ietf.org, "'Basavaraj.Patil@nokia.com'" Subject: RE: [Mip4] Draft minutes from IETF58 Date: Thu, 20 Nov 2003 14:19:30 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Hi A comment on the minutes: > draft-ietf-mobileip-lowlatency-handoffs-07 > - waiting for writeup, then to iesg The draft was resubmitted before IETF (since for some reason it disappeared from the archives): http://www.ietf.org/internet-drafts/draft-ietf-mobileip-lowlatency-handoffs-v4-07.txt So the writeup was out and should have been sent off to IESG already. Raj has it been sent to IESG? /Karim -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Mar 30 18:43:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04612 for ; Tue, 30 Mar 2004 18:43:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rj4-0006WI-Un for mip4-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2H66Sr013962 for mip4-archive@odin.ietf.org; Tue, 2 Dec 2003 12:06:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDyQ-0003cy-42 for mip4-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 12:06:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27643 for ; Tue, 2 Dec 2003 12:05:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARDyO-0004Ua-00 for mip4-web-archive@ietf.org; Tue, 02 Dec 2003 12:06:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARDyO-0004UV-00 for mip4-web-archive@ietf.org; Tue, 02 Dec 2003 12:06:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDyO-0003cD-49; Tue, 02 Dec 2003 12:06:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDxh-0003Rn-7n for mip4@optimus.ietf.org; Tue, 02 Dec 2003 12:05:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27571 for ; Tue, 2 Dec 2003 12:04:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARDxV-0004Se-00 for mip4@ietf.org; Tue, 02 Dec 2003 12:05:09 -0500 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=chardonnay) by ietf-mx with esmtp (Exim 4.12) id 1ARDxV-0004ST-00 for mip4@ietf.org; Tue, 02 Dec 2003 12:05:09 -0500 Received: from chardonnay ([127.0.0.1]) by chardonnay with smtp (Exim 3.36 #1 (Debian)) id 1ARDxP-0000Cw-00; Tue, 02 Dec 2003 18:05:03 +0100 Date: Tue, 2 Dec 2003 18:05:02 +0100 From: Henrik Levkowetz To: sami.vaarala@iki.fi Cc: mip4@ietf.org Subject: Re: [Mip4] Comments on draft-ietf-dhc-mipadvert-opt-01.txt Message-Id: <20031202180502.778c51a7.henrik@levkowetz.com> In-Reply-To: <1070306050.3fcb93020d799@webmail2.hut.fi> References: <1070306050.3fcb93020d799@webmail2.hut.fi> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Sami, Thanks for the response. Some questions inline: Monday 1 December 2003, sami.vaarala@iki.fi wrote: > Overall: I support the acceptance of this document, it seems to > provide a useful mechanism that may be relevant in more complicated > foreign agent scenarios (e.g. multi-provider environment). > > On the details, a few comments: > > - If possible, the duplication of agent advertisement format > from RFC 3344 to this document should be avoided, as it > introduces a dependency and does not make it clear is the > format updated if the corresponding ICMP format is updated > (although the flags field is discussed separately, but > other changes to the format may at least theoretically > happen :-). Ok, so we would need to refer to 3344 or successor as the authoritative source for the advertisement format not only for the flag but overall. Would this be acceptable? > One concrete suggestion for Section 3.3: > > - Specify the extension as having exactly one agent > advertisement (for simplicity, personal preference), > the extension beginning with Mobility Agent IP Address. Elaborating on this suggestion, we have the following choices: 1. This sub-option may have only one agent advertisement, and may occur only one time. 2. This sub-option may have only one agent advertisement, but the sub-option itself may occur multiple times. 3. This sub-option may have multiple agent advertisements, but may itself occur only one time. 4. This sub-option may have multiple agent advertisements, and the sub-option itself may occur multiple times. Alternative 4 does not really make any sense to me; the question is, is it too limiting to adopt alternative 1, or do we want to go with alternatives 2 or 3 ? And if so which one? > - Keep the extension format otherwise as-is, but > instead of re-specifying the extension, refer to > RFC 3344 Section 2.1.1. Expand the current flags > discussion to cover other fields of the advertisement > as well. Ok, no problem. > - An alternative would be to provide the MN with only the > FA IP addresses, but this does not seem to work well with > ICMP router solicitation (the router is allowed to answer > with multicast which might confuse other MNs in the > network). Was this alternative considered (and rejected) ? Yes, this seemed like a less complete solution; if one wanted to cleanly separate different service options, this alternative would still permit information to 'leak'. > - Nit: RFC 3220 references should be changed to RFC 3344 references. Absolutely. This draft has been on the road for a while :-) Best regards, Henrik -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Mar 31 02:58:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04070 for ; Wed, 31 Mar 2004 02:58:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8acE-0005ZZ-ST for mip4-archive@odin.ietf.org; Wed, 31 Mar 2004 02:58:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2V7wQmS021417 for mip4-archive@odin.ietf.org; Wed, 31 Mar 2004 02:58:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8acE-0005ZG-Js for mip4-web-archive@optimus.ietf.org; Wed, 31 Mar 2004 02:58:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04019 for ; Wed, 31 Mar 2004 02:58:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8acA-0004qg-00 for mip4-web-archive@ietf.org; Wed, 31 Mar 2004 02:58:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8aZo-0004X3-00 for mip4-web-archive@ietf.org; Wed, 31 Mar 2004 02:56:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B8aXx-0004Bd-00 for mip4-web-archive@ietf.org; Wed, 31 Mar 2004 02:54:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8aXz-0005H5-2Z; Wed, 31 Mar 2004 02:54:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8aXh-0005FE-KY for mip4@optimus.ietf.org; Wed, 31 Mar 2004 02:53:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03679 for ; Wed, 31 Mar 2004 02:53:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8aXd-00046c-00 for mip4@ietf.org; Wed, 31 Mar 2004 02:53:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8aVP-0003jj-00 for mip4@ietf.org; Wed, 31 Mar 2004 02:51:24 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B8aU7-0003ZR-00 for mip4@ietf.org; Wed, 31 Mar 2004 02:50:03 -0500 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 31 Mar 2004 02:49:27 -0500 content-class: urn:content-classes:message Subject: RE: [Mip4] NAI-based dynamic home address assignment draft Date: Wed, 31 Mar 2004 02:49:30 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: [Mip4] NAI-based dynamic home address assignment draft X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Index: AcQWN2f61LxlpZB2Qf64T6hdJDIRagAs4Wfg From: "O'Neill Alan" To: X-OriginalArrivalTime: 31 Mar 2004 07:49:27.0614 (UTC) FILETIME=[B1544DE0:01C416F4] Content-Transfer-Encoding: quoted-printable Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Kent/Naveen, I checked through the tables and processing thoroughly and think they = are all ok. I also noted the following points / benefits. i) For case D2/S2, instead of needing to respond with S2 when the MN = signals static capability RREQ(HoA) for an HoA that is not allowed, the MN just = sends dynamic capability and the HA processing just defaults to D2. In = addition, if the MN has a static HoA which is different to the RREQ(HoA), then rather = than using the S2 response, it is clearly better if we instead return the = static HoA to the MN via D2 processing. If the MN does not have a static HoA, = then a dynamic address is assigned via D1 or D2 depending on the availability = of the RREQ(HoA). These seamless transitions between static and dynamic models = is made possible with the converged MN Capability. ii) For case D7, the binding (HoA) is preferred given a RREQ(0.0.0.0), = so we should do similarly for case D5, where the existence of a binding(HoA) = should cause the HA to return the binding(HoA) to the MN. iii) To reduce the chances of case D2 occurring, an address should not = be returned to the unassigned pool until after a short reboot safety timer = has expired, following binding deletion. A MN sending RREQ(NAI,HoA) is then = much more likely to avoid the HA having assigned RREQ(HoA) to another NAI = during the HA reboot. This model of course assumes that address state survives reboot (persistent storage and/or outside HA) and only binding state is = lost. Regards, Alan. -----Original Message----- From: mip4-admin@ietf.org [mailto:mip4-admin@ietf.org] On Behalf Of = O'Neill Alan Sent: Tuesday, March 30, 2004 5:53 PM To: mip4@ietf.org Subject: RE: [Mip4] NAI-based dynamic home address assignment draft Hi Naveen, Kent. So I read the draft and think the HA processing is great given present circumstances. One aspect of the model I didn't like was having both a = Static and Dynamic MN Capability. I would rather we had one Dynamic MN = Capability, that distances us from RFC2794 and RFC3344. This then leaves knowledge = of the addressing policy for each MN on the HA, eliminates some error cases, = and enables static and dynamic addresses to converge as a dynamic address = with a lease-time between; =20 0(address release)...X(dynamic)...infinity(static). The impact of this direction on your model is shown in the converged = table below, where D1-7 are your dynamic cases from section 6.1, and S1-3 are = the static cases from section 6.2. The table is a slight rearrangement of = those in the draft so that binding state and addressing state in the HA are = clearly separated. Note that I modified S2/D2 cases so that the HoA is described = as being assigned to a different NAI rather than a different MN, due to the potentially multiplicity of mappings between MNs and NAIs).=20 In this table, if there is a binding (NAI,HoA) then by definition the = HoA is assigned to that NAI for some lease-time (not shown) which for present implementations is equal to either the binding lifetime (dynamic) or = infinity (static). I hope this table shows how the two models come together = nicely. +----------+----------------+---------------------------+------+=20 | MIP RREQ |HA Binding State|HA Address Management State| Case | +----------+----------------+---------------------------+------+=20 | | | RREQ(HoA) is Unassigned | D1 |=20 | | +---------------------------+------+=20 | | | RREQ(HoA) Not Allowed | |=20 | | | OR | D2 |=20 | | No Binding | RREQ(HoA) is assigned to | S2 |=20 | | for RRQ(NAI) | a different NAI | |=20 | | +---------------------------+------| |RREQ(NAI, | | RREQ(HoA) is | S1 | | HoA) | | assigned to RREQ(NAI) | | | +----------------+---------------------------+------+=20 | |RRQ(NAI,HoA) =3D=3D | RREQ(HoA) is | D3 = |=20 | |Binding(NAI,HoA)| assigned to RREQ(NAI) | S1 |=20 | +----------------+---------------------------+------+=20 | | RRQ(NAI) =3D=3D | RRQ(HoA) is Unassigned | D4 = |=20 | | Binding(NAI) | | S2 | | | && +---------------------------+------+=20 | | RRQ(HoA) !=3D | RREQ(HoA) Not Allowed | | | | Binding(HoA) | OR | D5 | | | | RRQ(HoA) is assigned to | S2 |=20 | | | a different NAI | |=20 +----------+----------------+---------------------------+------+ | | | A HoA is | D6 |=20 | | No Binding | assigned to RREQ(NAI) | S3 |=20 | | for RRQ(NAI) +---------------------------+------| | | | No HoA is | D6 | |RREQ(NAI, | | assigned to RREQ(NAI) | S3 |=20 | 0.0.0.0) +----------------+---------------------------+----- +=20 | | RRQ(NAI) =3D=3D | | = | | | Binding(NAI) | Binding(HoA) is | D7 | | | with | assigned to RREQ(NAI) | S3 | | | Binding(HoA) | | | +----------+----------------+---------------------------+------+ In particular, note that S3 still crops up in all cases of RREQ(0.0.0.0) = when the MN is able to include the Static MN Capability as per the existing = draft. Now I would suggest we get the following benefits with a single Dynamic = MN Capability, as shown in the following table extract update, which also = aligns quite nicely with being 'liberal in what you receive'. It is assumed = here that we are replacing the static procedure (S1-S3) with the equivalent dynamic procedure | | | A HoA is | D6 |=20 | | No Binding | assigned to RREQ(NAI) | |=20 | | for RRQ(NAI) +---------------------------+------| | | | No HoA is | D6 | |RREQ(NAI, | | assigned to RREQ(NAI) | |=20 | 0.0.0.0) +----------------+---------------------------+----- +=20 | | RRQ(NAI) =3D=3D | | = | | | Binding(NAI) | Binding(HoA) is | D7 | | | with | assigned to RREQ(NAI) | | | | Binding(HoA) | | | +----------+----------------+---------------------------+------+=20 We can now get the MN connected by resorting to S1=3D=3DD6 behaviour = instead of S3 behaviour, if a HoA is assigned (ie MN should have sent RREQ(HoA)). Similarly, we can get the MN connected by resorting to D6/D7 instead of = S3, if no HoA is assigned (because with no Static MN Capability, the RREQ(0.0.0.0) is always valid and we rely on the HA policy to merely = control the lease-time granted. Essentially, we have stripped out a number of = error cases in the merge because now the parameters in the RREQ() can now = never internally conflict, and are less likely to conflict with the HA address management state/policy. In the case of the lease-time =3D binding lifetime (ie no HALG = extension), then the MN knows it got a dynamic address. With a HALG included, the MN gets = to know that it has a lease-time greater than the MIP binding, potentially including an infinite lifetime (static), and could also be told how to release the static address (ie HALR) and how to maintain the address on returning home (ie DHCP v HALR v etc). Having the distinction made in = the downlink rather than uplink signaling is preferable on wireless links = due to the asymmetry, and avoiding RREQ() refusals is also generally preferable = to avoid connectivity delays and wasted air-link resources. I am still checking the impact on all your signaling cases to make sure = I haven't lost something important, so if you can see them more quickly = then please save me the effort. But I would appreciate your thoughts on the = model ? Alan. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is=20 strictly prohibited. If you are not the intended recipient please = contact the sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D --=20 Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Wed Mar 31 12:11:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02142 for ; Wed, 31 Mar 2004 12:11:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8jFG-0003TP-Oz for mip4-archive@odin.ietf.org; Wed, 31 Mar 2004 12:11:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2VHBIfp013351 for mip4-archive@odin.ietf.org; Wed, 31 Mar 2004 12:11:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8jFG-0003TG-Hi for mip4-web-archive@optimus.ietf.org; Wed, 31 Mar 2004 12:11:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02139 for ; Wed, 31 Mar 2004 12:11:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8jFF-0004YX-00 for mip4-web-archive@ietf.org; Wed, 31 Mar 2004 12:11:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8jEL-0004Wd-00 for mip4-web-archive@ietf.org; Wed, 31 Mar 2004 12:10:22 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B8jE2-0004UC-00 for mip4-web-archive@ietf.org; Wed, 31 Mar 2004 12:10:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8jE2-0003La-P7; Wed, 31 Mar 2004 12:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8jDC-0003IS-Eq for mip4@optimus.ietf.org; Wed, 31 Mar 2004 12:09:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02054 for ; Wed, 31 Mar 2004 12:09:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8jDB-0004QJ-00 for mip4@ietf.org; Wed, 31 Mar 2004 12:09:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8jCL-0004OL-00 for mip4@ietf.org; Wed, 31 Mar 2004 12:08:18 -0500 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1B8jBo-0004KD-00 for mip4@ietf.org; Wed, 31 Mar 2004 12:07:44 -0500 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2VH7Bc19459 for ; Wed, 31 Mar 2004 11:07:11 -0600 (CST) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id i2VH7A105382; Wed, 31 Mar 2004 11:07:10 -0600 (CST) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HVGA7R-0001DO-00 for mip4@ietf.org; Wed, 31 Mar 2004 12:07:03 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nDf3GdjecX" Content-Transfer-Encoding: 7bit Message-ID: <16490.64182.49425.585575@gargle.gargle.HOWL> Date: Wed, 31 Mar 2004 11:07:02 -0600 From: Pete McCann To: mip4@ietf.org X-Mailer: VM 7.14 under 21.5 (beta14) "cassava" XEmacs Lucid Subject: [Mip4] Meeting Minutes for mip4 at IETF59 Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.2 required=5.0 tests=AWL,NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 --nDf3GdjecX Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit Hi, It's taken a bit longer than expected to put these together, and, unfortunately, the submission deadline is almost upon us (this Friday). But, here are the draft meeting minutes for your review. Please send any comments or updates to the list by tomorrow so we can include them in the final minutes for the proceedings. Many thanks to Jayshree Bharatia and Pascal Thubert for taking notes during the meeting. -Pete --nDf3GdjecX Content-Type: text/plain Content-Disposition: inline; filename="minutes.txt" Content-Transfer-Encoding: 7bit MIP4 WG Minutes (Monday, March 1, 2004, 1930-2200) ================================================== 1. Topic: Document status by WG Chair aaa-nai => In RFC editor Queue aaa-key => Publication requested lowlatency-handoffs => Publication requested vpn-problem-statement => Under IESG evaluation reg-tunnel => Chair writeup needed rfc3012bis => Await resolution of one issue dynamic-assignment => Require one more revision experimental-messages => Await resolution of one issue vpn-problem-solution => Review needed rfc3344bis => Issues resolved but the draft is not published. 2006 => Need mib doctor ------------------ 2. Topic: Update on 3012bis Issue by Pete McCann Couple of options were presented in last meeting to resolve issue on indicating an error to the MN by the FA upon receipt of the Registration request from the HA. These options are whether to overwrite the HA's error code or to insert a new error code extension at the FA. The later option was preferred in last IETF meeting which also introduces a dependency on perkins-faerr... Charlie clarified that this was the reason MIP4 working group decided to have the new draft (perkins-faerr) so this dependency is justified. This implies that a new reference document need to be added to the RFC3012bis draft. The issue and proposal will be posted on the mailing list soon. ------------------ 3. Topic: Experimental-messages issue by Alpesh Patel There is one issue unresolved for this draft at this time. The issue is whether to define an experimental sub-type. Adding new sub type provides advantage such as implementation will need minimal code change from experimentation to standardization. If this subtype is not defined then the same functionality will be achieved using experimental extensions. It introduces a disadvantage of reserving sub-type number from allocated numbers. Comments: It was clarified that the format of the extension are already defined in 3344. Pete pointed out that it doesn't make sense to do at this time. It should be done case by case basis. Conclusion: It was agreed not to define experimental sub-type. This was determined by the humm in the meeting. 4. Topic: Dynamic Assignment By Alpesh Patel Issues: 1. Add subtype field in Redirected HA Address Extension. This issue is resolved and the solution will be added in the next version. 2. To align the HA address at 4-byte world boundary. This issue is resolved and will appear in the next version. 3. The current scheme does not allow dynamic HA registration (AZOA HA address) beyond first registration. The response of this issue was that it makes sense to use AZOA as HA address while dynamic assignment is in progress. 4. An issue was related to using RRQ with unicast HA address for dynamic assignment. The response of this issue was that for Dynamic HA assignment, unicast HA address will not be used. 5. In addition to AZOA HA address, provide an extension for additional information to distinguish different cases of dynamic HA assignment. It seems authors require further clarification on this issue. 6. Editorial issues will fix in the next version of the draft. Comments: This draft is diverting from 3GPP2 requirements so authors like to know the input on the implication on 3GPP2. Pete mentioned that most of the changes are still essential. It is up to other standards to decide whether they want to adopt the current changes. 5. Topic: Optimized Mobile IPv4 UDP Encapsulations By Farid Adrangi Motivation is to minimize MIPv4 data packet overhead when UDP encapsulation is used and most of mobile node's data traffic is destined to one particular correspondent node. The applicability is on MIP/VPN or basic IPSec-over-MIP4 and also VoIP over MIP. The idea is to specify an extension to be used in congestion with RFC 3519 to enable overhead extension. A scenario was explained with extension "Preferred-CN". In this draft, a new state "preferred" CN is defined in mobility binding apart from the new extension. A new flag is also defined in MIP Tunnel data Message header indicating optimized UDP encapsulation in use. Examples of how packet processing works (inbound and outbound) were discussed in brief. The author asked working group opinion on whether this is something which can be standalone or it is viewed as an extension of RFC3519. Comments: - If we take on this, need a charter change. - This defines an adhoc header compressoin for IP header. For VOIP, there are multiple schemes that exist and save more, such as ROHC. - ROCH, CRTP, etc also apply to any number of flows. TCP, UDP and RTP compression at the same time. Would be useful to look at the whole architecture. Which are the points where header compression can be used? Endpoints? Middelboxes? - The Limit is up to 2 layers for the compression using ROHC. Need to look at specific cases. But more generic solution is preferable. - For the question, why only one CN was picked in the draft, the author clarified that it is still for further study. The chair mentioned that the same question was also raised earlier on the mailing list. Conclusion: The charter needs to be changed if it is decided to accept this draft. Further discussion is require on this topic. ----------------- 6. Topic: Fragmentation MTU Extension by Farid Adrangi Large packets sometimes dropped by routers. This seems like a realistic deployment issue. Solution is to define an extension with preferred MTU for reception. MN and HA sends MTU independently. Applies to both IP-IP and IP-over-UDP. This work may be proceed as a stand-alone or an extension to RFC3519. This draft focuses only on the tunnel between the HA-MN. Comment: It was question on the use of solving only one leg of the route. It seems solving this cases would solve majority of the cases according to the author. Conclusion: It seems not many people have read the draft. Further discussion will be on the mailing list. The charter may need to be changed if adopted as a WG draft. ------------------ 7. Topic: FA Error Extension by Charlie Perkins This draft was written to solve the problem of RFC3012bis but the problem is generic. The problem is that the FA doesn't have any way of indicating the error to the mobile node in the successful Registration received from the HA. For this, a new faerr extension has been defined. This extension is added to the Registration Reply whenever there is a need to indicate an error. This draft is very short and going to WGLC as soon as it appears in the Internet Draft repository. this draft will be referenced by RFC3012bis. ------------------- 8. Topic: mobility+IPv4/v6 interworking Experiments being carried out to support MIPv4 nodes roaming in IPv6 networks and MIPv6 nodes roaming in IPv4 networks. Several proposals for how to do this exist. Henrik proposes a (non-)bar BOF to discuss the need for it. ------------------- --nDf3GdjecX-- -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/