From mip6-bounces@ietf.org Tue Apr 03 00:54:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYb2A-000227-3P; Tue, 03 Apr 2007 00:54:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYb28-000221-Km for mip6@ietf.org; Tue, 03 Apr 2007 00:54:16 -0400 Received: from otm-mgo01.iij.ad.jp ([210.138.20.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYb27-0000pe-0X for mip6@ietf.org; Tue, 03 Apr 2007 00:54:16 -0400 Received: OTM-MO(otm-mgo01) id l334rhUX098639; Tue, 3 Apr 2007 13:53:43 +0900 (JST) Received: OTM-MIX(otm-mix00) id l334rgVn055812; Tue, 3 Apr 2007 13:53:42 +0900 (JST) Received: from [127.0.0.1] (keiichi00-4.osaka.iij.ad.jp [192.168.64.45]) by rsmtp.iij.ad.jp (OTM-MR/rsmtp00) id l334rfZJ002692 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 3 Apr 2007 13:53:42 +0900 (JST) In-Reply-To: <20070330101553.OLRE14698.oaamta04ps.mx.bigpond.com@PC20005> References: <20070330101553.OLRE14698.oaamta04ps.mx.bigpond.com@PC20005> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <21D4DBFA-E29F-4415-8066-6FDD477BC985@iijlab.net> Content-Transfer-Encoding: 7bit From: Keiichi SHIMA Subject: Re: [Mip6] RE: concensus on [issue94] fixing encapsulation mechanism in IPv4 network Date: Tue, 3 Apr 2007 13:53:43 +0900 To: Hesham Soliman X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: mip6@ietf.org, Keiichi SHIMA X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hello Hesham, Since the consensus call ends Tuesday, maybe this is my last chance to make myself clear. On 2007/03/30, at 19:15, Hesham Soliman wrote: >>> => Yes there is, I explained it during our discussion and on the >>> mailing >>> list. Others also explained it on the list. I'm attaching >> one of my >>> emails >>> again. The idea that you can only support one tunnelling protocol >>> is *not* >>> technically possible as you request it. Please read my email >>> attached again. >> >> I think you are explaining the reason why we can allow IP-in-IP >> tunnel mode. I have never said to disallow IP-in-IP mode. Your >> implementation can still use both IP-in-IP, IP-in-UDP of course. >> >> What I was asking was the technical reason why you want to >> reject UDP >> tunnel only mode. > > => I'm not sure how those two conclusions were made. Your initial > suggestion > was to > remove IP in IP, Yes. > which we won't go over again, now your own compromise > approach was to allow the MN to request UDP only. Yes. > I'm not sure what I'm > allowing or disallowing but this is a WG concensus call. I requested the possibility to operate DSMPv6 with UDP tunnel mode only to allow a mobile node that implements UDP tunnel mode only. However, the option A in your mail for consensus call said that the HA can reply the mobile node with a BA message to indicating IP tunnel mode. This is the point I don't understand whether my idea is understood correctly or not. >> As I said, introducing the 'U' flag (or in other words, >> RFC3519 style >> 'F' flag) allows some limited implementation (UDP only >> implementation). Such implementations are still interoperable with >> full (both IP tunnel and UDP tunnel) implementations. > > => Quoting your comments to Henrik: > The 'F' flag in RFC3519 is a flag sent from a mobile node to request > its home agent to use UDP tunneling mode. If the home agent > understand the RFC3519 'F' flag, then it either 'accepts the UDP > tunnel' or 'rejects the binding update'. > > If you want option A to suggest that the HA rejects the BU instead of > Accepting it and telling the MN to use IP in IP, I don't have an > opinion on > that. But neither this modification, nor option A as I sent it > before will > guarantee that the MN will always use UDP *only* because they both > depend on > the HA's acceptance. So what is it that you are suggesting we do? > and why? OK, let me explain what is the difference between the above two cases. case 1) - assumption - MN operates UDP tunnel mode - HA decides tunneling mode (UDP or IP) - operation case 1 1-1. MN sends a BU with the 'U' flag. 1-2. HA returns a BA by accepting the 'U' flag. 1-3. DSMIPv6 is operated with UDP tunnel. - operation case 2 2-1. MN sends a BU with the 'U' flag. 2-2. HA returns a BA by suggesting IP tunnel mode. 2-3. MN stops its operation. The BC entry is left because the HA cannot know that MN has stopped its operation. case 2) - assumption - MN operates UDP tunnel mode - HA decides accepts or rejects its request - operation case 1 1-1. MN sends a BU with the 'U' flag. 1-2. HA returns a BA by accepting the 'U' flag. 1-3. DSMIPv6 is operated with UDP tunnel. - operation case 2 2-1. MN sends a BU with the 'U' flag. 2-2. HA returns a BA with error code. 2-3. MN stops its operation. HA stops its operation for the MN. The difference between case 1 and 2 is that, in the case 1, the unnecessary BC entry is left for a while. >> I simply don't understand why we cannot allow such implementation. > > => Please explain how your suggestion above makes any difference to > the MN. I hope I could explain the difference in the above paragraph... > If the MN only implements UDP then in both cases (whether the BU is > rejected > or the HA forces IP in IP) the MN will not be able to communicate > with the > HA. Please explain clearly what you're trying to do. No the MN cannot communicate with the HA if UDP tunnel request is rejected. But I think there is difference in the ways of how to reject the request. Your proposal is 'reject UDP tunnel mode and suggest IP tunnel mode.' My proposal is 'reject the UDP tunnel mode and reject the binding message.' Since we are talking about the implementation that provides UDP tunnel only mode, the former is not useful. > I think there is an > issue with trying to fit the standard around a particular > implementation > here.... I'm not sure I was asked a question or not in the above sentence... Anyway, I think the issue here is if we allow a limited operation scenario (UDP tunnel mode only) or not. The option A, you proposed in the initial consensus call mail, may allow the operation, but as I explained in the above message, I think it is better to simply accept or reject the MN's UDP tunnel request rather than asking the MN to use IP tunnel mode. Regards, --- Keiichi SHIMA IIJ Research Laboratory WIDE Project _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 03 00:58:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYb6H-0004sF-5E; Tue, 03 Apr 2007 00:58:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYb6F-0004rp-CS for mip6@ietf.org; Tue, 03 Apr 2007 00:58:31 -0400 Received: from otm-mgo00.iij.ad.jp ([210.138.20.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYb6C-0001hZ-QD for mip6@ietf.org; Tue, 03 Apr 2007 00:58:31 -0400 Received: OTM-MO(otm-mgo00) id l334wR7V098604; Tue, 3 Apr 2007 13:58:27 +0900 (JST) Received: OTM-MIX(otm-mix01) id l334wQnt018035; Tue, 3 Apr 2007 13:58:27 +0900 (JST) Received: from [127.0.0.1] (keiichi00-4.osaka.iij.ad.jp [192.168.64.45]) by rsmtp.iij.ad.jp (OTM-MR/rsmtp00) id l334wQIX002768 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 3 Apr 2007 13:58:26 +0900 (JST) In-Reply-To: <460CF3E1.1040201@levkowetz.com> References: <20070328073355.B105DFB956@sh1.iijlab.net> <3738B0C4-E0BE-4BE3-93BB-50FAD8D9CFED@iijlab.net> <460A9D8D.2010302@levkowetz.com> <56834D20-93BA-4020-8EA6-6ECA4AFCE446@iijlab.net> <460CF3E1.1040201@levkowetz.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: Keiichi SHIMA Subject: Re: [Mip6] Re: concensus on [issue94] fixing encapsulation mechanism in IPv4 network Date: Tue, 3 Apr 2007 13:58:25 +0900 To: Henrik Levkowetz X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: mip6@ietf.org, Keiichi SHIMA X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2115747627==" Errors-To: mip6-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============2115747627== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-1--299390176" Content-Transfer-Encoding: 7bit This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-1--299390176 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hello Henrik, On 2007/03/30, at 20:26, Henrik Levkowetz wrote: >> The 'F' flag in RFC3519 is a flag sent from a mobile node to request >> its home agent to use UDP tunneling mode. If the home agent >> understand the RFC3519 'F' flag, then it either 'accepts the UDP >> tunnel' or 'rejects the binding update'. >> >> Is my understanding correct? > > Seems so, yes. But as it also says in the text, if the HA knows > how to do UDP tunnelling, it SHOULD accept it, unless it has been > administratively prohibited (configured to not use it). OK. I agree with the above operation and hope DSMIPv6 allows this kind of operation. >> I think the action is different from the Hesham's proposal. His >> proposal allows to override the RFC3519 style 'F' flag at the HA. >> Thus, the HA may accept the BU message with the RFC3519 style 'F' >> flag even the HA doesn't allow UDP tunnel. Since the mobile node is >> forcing UDP tunnel, replying with a BA message requesting not to use >> UDP is not correct way I think. (Rejecting the request is >> understandable as described in RFC3519) >> >> So let me rephrase the option A. >> >> A. Add a flag that allows the MN to request UDP tunnelling interface >> (independently of the presence of a NAT) from the HA, when sending >> the BU. If the HA accepts the request then the HA replies the BU >> with a BA with the 'F (Force UDP)' flag. Otherwise the HA rejects >> the BU with status code "administratively prohibited". > > This is the understanding I already had of the meaning of Hesham's > proposal A. > > I don't however, understand why we have to use different flag logic > in MIPv4 and MIPv6 -- why not let the BU have a 'Force' flag and the > BA be flag-less and either accept or reject the BU? Because the HA may want to suggest UDP tunneling mode, in case that the MN doesn't specify its tunnel mode preference. If the MN supports both IP tunnel and UDP tunnel mode, the MN will not set the flag. If the HA detects necessity of UDP tunneling in this case, it needs a method to notify the MN of using UDP tunnel mode. This is my understanding. Regards, --- Keiichi SHIMA IIJ Research Laboratory WIDE Project --Apple-Mail-1--299390176 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: =?ISO-2022-JP?B?GyRCJDMkbCRPJUclOCU/JWs9cEw+JDUkbCQ/JWElQyU7GyhC?= =?ISO-2022-JP?B?GyRCITwlOCROSXRKLCRHJDkbKEI=?= content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFGEd7xijJXttJUUzgRAmgMAJ97yeyIFVAlHXx5eHrRamq8Y0A8QACfUUrS bH9mgGLrsI5ZV2/491aclrA= =khZs -----END PGP SIGNATURE----- --Apple-Mail-1--299390176-- --===============2115747627== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============2115747627==-- From mip6-bounces@ietf.org Tue Apr 03 01:08:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYbFf-00033x-SE; Tue, 03 Apr 2007 01:08:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYbFd-00032V-Vo for mip6@ietf.org; Tue, 03 Apr 2007 01:08:13 -0400 Received: from omta05ps.mx.bigpond.com ([144.140.83.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYbFZ-0005dJ-UE for mip6@ietf.org; Tue, 03 Apr 2007 01:08:13 -0400 Received: from oaamta07ps.mx.bigpond.com ([124.191.178.123]) by omta05ps.mx.bigpond.com with ESMTP id <20070403050804.DDIU23363.omta05ps.mx.bigpond.com@oaamta07ps.mx.bigpond.com>; Tue, 3 Apr 2007 05:08:04 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta07ps.mx.bigpond.com with ESMTP id <20070403050803.FCWD27562.oaamta07ps.mx.bigpond.com@PC20005>; Tue, 3 Apr 2007 05:08:03 +0000 From: "Hesham Soliman" To: "'Keiichi SHIMA'" Subject: RE: [Mip6] RE: concensus on [issue94] fixing encapsulation mechanism in IPv4 network Date: Tue, 3 Apr 2007 15:07:59 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <21D4DBFA-E29F-4415-8066-6FDD477BC985@iijlab.net> Thread-Index: Acd1rBYpbLjA56evTDKkhmGaNMZifAAAXcxg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Message-Id: <20070403050803.FCWD27562.oaamta07ps.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > OK, let me explain what is the difference between the above > two cases. > > case 1) > - assumption > - MN operates UDP tunnel mode > - HA decides tunneling mode (UDP or IP) > - operation case 1 > 1-1. MN sends a BU with the 'U' flag. > 1-2. HA returns a BA by accepting the 'U' flag. > 1-3. DSMIPv6 is operated with UDP tunnel. > - operation case 2 > 2-1. MN sends a BU with the 'U' flag. > 2-2. HA returns a BA by suggesting IP tunnel mode. > 2-3. MN stops its operation. > The BC entry is left because the HA cannot know > that MN has stopped its operation. > > case 2) > - assumption > - MN operates UDP tunnel mode > - HA decides accepts or rejects its request > - operation case 1 > 1-1. MN sends a BU with the 'U' flag. > 1-2. HA returns a BA by accepting the 'U' flag. > 1-3. DSMIPv6 is operated with UDP tunnel. > - operation case 2 > 2-1. MN sends a BU with the 'U' flag. > 2-2. HA returns a BA with error code. > 2-3. MN stops its operation. > HA stops its operation for the MN. > > The difference between case 1 and 2 is that, in the case 1, the > unnecessary BC entry is left for a while. => Right, in another words, there is no difference for the MN and in both cases it can't get connectivity. I have no problems with rejecting the BU instead of replying with an error code, this is a side issue. My point is that this has no bearing on whether UDP only is used because all cases will lead to no connectivity if the HA doesn't accept the request. Hesham _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 03 01:30:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYbam-0001f5-Q6; Tue, 03 Apr 2007 01:30:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYbal-0001et-Gl for mip6@ietf.org; Tue, 03 Apr 2007 01:30:03 -0400 Received: from otm-mgo00.iij.ad.jp ([210.138.20.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYbai-00081V-TA for mip6@ietf.org; Tue, 03 Apr 2007 01:30:03 -0400 Received: OTM-MO(otm-mgo00) id l335Tmo4099919; Tue, 3 Apr 2007 14:29:48 +0900 (JST) Received: OTM-MIX(otm-mix01) id l335Tl7q022656; Tue, 3 Apr 2007 14:29:47 +0900 (JST) Received: from [127.0.0.1] (keiichi00-4.osaka.iij.ad.jp [192.168.64.45]) by rsmtp.iij.ad.jp (OTM-MR/rsmtp01) id l335ShcU013247 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 3 Apr 2007 14:28:44 +0900 (JST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <53A5C954-D6E9-433F-84C4-F4A9443DCFBB@iijlab.net> Content-Transfer-Encoding: 7bit From: Keiichi SHIMA Subject: Re: [Mip6] RE: concensus on [issue94] fixing encapsulation mechanism in IPv4 network Date: Tue, 3 Apr 2007 14:29:51 +0900 To: Basavaraj Patil X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: mip6@ietf.org, Keiichi SHIMA X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hello Basavaraj, On 2007/03/31, at 5:28, Basavaraj Patil wrote: >> I think you are explaining the reason why we can allow IP-in-IP >> tunnel mode. I have never said to disallow IP-in-IP mode. Your >> implementation can still use both IP-in-IP, IP-in-UDP of course. > > Okay... So you agree that depending on the scenario you could use > either > IP-in-IP or IP-in-UDP, right? My idea is that UDP tunnel mode can be used in all the cases, but in some cases, we can use IP tunnel mode that consumes less bits. >> What I was asking was the technical reason why you want to reject UDP >> tunnel only mode. > > UDP tunnel only mode is less optimal than IP-in-IP. > The MN should (or MUST) be able to support both tunnelling schemes. > Why > would you restrict the MN to only using IP-in-UDP in all cases? I think there is pros and cons. UDP tunnel consumes more bits, I agree. But it can be operated in some environment where IP tunnel mode cannot be used. I think UDP tunnel mode can cover all the environment that IP tunnel mode covers. So in the sense of the cove area, UDP tunnel mode is a superset of IP tunnel mode. Considering that, I think it is not so strange that there is a request that wants to implement UDP tunnel only mode. >> As I said, introducing the 'U' flag (or in other words, RFC3519 style >> 'F' flag) allows some limited implementation (UDP only >> implementation). Such implementations are still interoperable with >> full (both IP tunnel and UDP tunnel) implementations. > > And so far at least the consensus from what I can tell is to have > the HA > decide what encapsulation mode to use. Hence if you have an MN that > only > implements IP-in-UDP and the HA rejects such encapsulation mode, > the MN is > pretty much out-of-luck. And as has been mentioned the MN cannot > command the > HA to honor its request for IP-in-UDP encapsulation. The decision > point is > the HA and lets stick with that design approach. Rejecting UDP tunnel mode is one choice of the business operation choices. I don't oppose that some operators take the choice. But if they accept MNs that implements UDP tunnel only mode, then they will get more customers. >> I simply don't understand why we cannot allow such implementation. >> I'm proposing to keep the current functions completely, and >> requesting to allow some limited implementation which is still >> interoperable. > > What you are requesting is that if the MN were to request IP-in-UDP > encapsulation, the HA MUST honor it. Otherwise there is no > interoperability > with the HA since the MN does not implement IP-in-IP encapsulation. I think this is the point that we don't understand each other. You think all operators and MN vendors want to use IP tunnel mode for saving bits. I think some operators and MN vendors may want all UDP tunnel mode. > What is your main argument about or use-case/scenario where you > have this > limited implementation (IP-in-UDP only encapsulation) MN? Implementation can be simpler. 1) MN can have only two tunneling functions, one is IPv*-in-IPv6 and IPv* in UDPv4, rather than having IPv*-in-IPv4, IPv*-in-IPv6 and IPv*- in-UDPv4. As Romain Kuntz reported in other mail, having more tunneling mechanisms may not be a big work in Linux, but there is a system it is. 2) MN can only provide switching between only two tunneling methods rather than switching between the three mechanisms. > I guess you do actually have limited interoperability because if > the MN > requests IP-in-UDP encapsulation you have a 0.5 probability that > the HA will > accept it. So you have interoperability possibility 50% of the time > and when > the HA rejects it, well... No connectivity. Can't we do the similar approach that RFC3519 does? That is, the HA basically accepts the UDP tunnel request. Since the HA can accept MNs that don't request any tunneling preference, it will not lose any existing MNs. In addition to this, the HA can have more MNs that have limited tunneling function. Regards, --- Keiichi SHIMA IIJ Research Laboratory WIDE Project _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 03 03:50:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYdlD-0002YV-RL; Tue, 03 Apr 2007 03:48:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYdlC-0002X6-8O for mip6@ietf.org; Tue, 03 Apr 2007 03:48:58 -0400 Received: from av9-2-sn2.hy.skanova.net ([81.228.8.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYdlA-0003rM-RR for mip6@ietf.org; Tue, 03 Apr 2007 03:48:58 -0400 Received: by av9-2-sn2.hy.skanova.net (Postfix, from userid 502) id AF83A384B7; Tue, 3 Apr 2007 09:48:53 +0200 (CEST) Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av9-2-sn2.hy.skanova.net (Postfix) with ESMTP id 911EE384A3; Tue, 3 Apr 2007 09:48:53 +0200 (CEST) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id 6444837E5A; Tue, 3 Apr 2007 09:48:52 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.63) (envelope-from ) id 1HYdl5-0001PI-R2; Tue, 03 Apr 2007 09:48:51 +0200 Message-ID: <461206EB.9080006@levkowetz.com> Date: Tue, 03 Apr 2007 09:48:59 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Keiichi SHIMA Subject: Re: [Mip6] Re: concensus on [issue94] fixing encapsulation mechanism in IPv4 network References: <20070328073355.B105DFB956@sh1.iijlab.net> <3738B0C4-E0BE-4BE3-93BB-50FAD8D9CFED@iijlab.net> <460A9D8D.2010302@levkowetz.com> <56834D20-93BA-4020-8EA6-6ECA4AFCE446@iijlab.net> <460CF3E1.1040201@levkowetz.com> In-Reply-To: X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: keiichi@iijlab.net, mip6@ietf.org, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Keiichi, on 2007-04-03 06:58 Keiichi SHIMA said the following: [snip] >>> So let me rephrase the option A. >>> >>> A. Add a flag that allows the MN to request UDP tunnelling interface >>> (independently of the presence of a NAT) from the HA, when sending >>> the BU. If the HA accepts the request then the HA replies the BU >>> with a BA with the 'F (Force UDP)' flag. Otherwise the HA rejects >>> the BU with status code "administratively prohibited". >> >> This is the understanding I already had of the meaning of Hesham's >> proposal A. >> >> I don't however, understand why we have to use different flag logic >> in MIPv4 and MIPv6 -- why not let the BU have a 'Force' flag and the >> BA be flag-less and either accept or reject the BU? > > Because the HA may want to suggest UDP tunneling mode, in case that > the MN doesn't specify its tunnel mode preference. > > If the MN supports both IP tunnel and UDP tunnel mode, the MN will > not set the flag. If the HA detects necessity of UDP tunneling in > this case, it needs a method to notify the MN of using UDP tunnel > mode. This is my understanding. This doesn't make sense to me. If the MN can manage to get through to the HA, I don't see any reason why the HA should specify tunnelling -- only in cases where there is trouble getting a BU through to the HA without tunnelling does tunnelling make sense, no? So this has to start at the MN end. Henrik _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 03 05:56:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYfjp-0006Y0-Gh; Tue, 03 Apr 2007 05:55:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYfjo-0006WQ-E3 for mip6@ietf.org; Tue, 03 Apr 2007 05:55:40 -0400 Received: from xanthe.lunarpages.com ([216.193.207.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYfjn-0006Qu-35 for mip6@ietf.org; Tue, 03 Apr 2007 05:55:40 -0400 Received: from active5 by xanthe.lunarpages.com with local (Exim 4.63) (envelope-from ) id 1HYfjn-0001Qv-M0 for mip6@ietf.org; Tue, 03 Apr 2007 02:55:39 -0700 To: mip6@ietf.org Date: Tue, 3 Apr 2007 02:55:39 -0700 From: "E. Segura" Message-ID: X-Priority: 3 X-Mailer: PHPMailer [version 1.73] X-Mailer: phplist v2.10.4 X-MessageID: 21 X-ListMember: mip6@ietf.org Precedence: bulk MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="UTF-8" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - xanthe.lunarpages.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [32011 509] / [47 12] X-AntiAbuse: Sender Address Domain - xanthe.lunarpages.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Subject: [Mip6] CFP - 2nd IEEE International Workshop Towards Stable and Adaptable Software Architectures (SASA 2007) X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org The 2nd IEEE International Workshop Towards Stable and Adaptable Software Architectures SASA 2007 Invitation Las Vegas, USA, August 13-15, 2007 (in conjunction with IEEE IRI 2007) http://www.sis.pitt.edu/~iri07/ (IEEE IRI 2007 Link) http://www.sis.pitt.edu/~iri07/wkshpCFP2.html (Workshop Link 1) http://www.engr.sjsu.edu/~fayad/workshops/SASA07 (Workshop Link 2) http://www.vrlsoft.com/workshops/SASA07 (Workshop Link 3) Greetings, I would like to invite you to participate in The 2nd IEEE International Workshop Towards Stable and Adaptable Software Architectures (SASA 2007)" In conjunction with The 2007 IEEE International Conference on Information Reuse and Integration (http://www.sis.pitt.edu/~iri07/), which will take place in Las Vegas, Nevada, August 13-15, 2OO7 by submitting a paper or two before or on April 15, 2007. A call of papers for the workshop is enclosed and it can be found at: http://www.sis.pitt.edu/~iri07/wkshpCFP2.html (Workshop Link 1) http://www.engr.sjsu.edu/~fayad/workshops/SASA07 (Workshop Link 2) http://www.vrlsoft.com/workshops/SASA07 (Workshop Link 3) Accepted papers will be published in the proceedings (EI Index) of the The 2007 IEEE International Conference on Information Reuse and Integration (IEEE IRI 2007). The workshop selected best papers will be published in online Journal of International Journal Of Patterns (IJOP). Looking forward to your submission and participation in the workshop! All the best, Cheers, Dr. M.E. Fayad (Chair) Dr. Rami Bahsoon (Co-Chair) Dr. Tarek Helmy (Co-Chair) Eduardo M. Segura (Co-Chair) -- ijop.org -- Powered by PHPlist, www.phplist.com -- _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 03 06:53:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYgdP-0007nT-3P; Tue, 03 Apr 2007 06:53:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYgdN-0007nA-PY for mip6@ietf.org; Tue, 03 Apr 2007 06:53:05 -0400 Received: from xanthe.lunarpages.com ([216.193.207.187]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HYgdJ-0004pJ-5D for mip6@ietf.org; Tue, 03 Apr 2007 06:53:05 -0400 Received: from active5 by xanthe.lunarpages.com with local (Exim 4.63) (envelope-from ) id 1HYgdG-000291-W2 for mip6@ietf.org; Tue, 03 Apr 2007 03:52:59 -0700 To: mip6@ietf.org Date: Tue, 3 Apr 2007 03:52:58 -0700 From: "E.Segura" Message-ID: X-Priority: 3 X-Mailer: PHPMailer [version 1.73] X-Mailer: phplist v2.10.4 X-MessageID: 22 X-ListMember: mip6@ietf.org Precedence: bulk MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="UTF-8" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - xanthe.lunarpages.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [32011 509] / [47 12] X-AntiAbuse: Sender Address Domain - xanthe.lunarpages.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Subject: [Mip6] 2nd IEEE International Workshop on Software Stability at Work (SSW 2007) X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org The 2nd IEEE International Workshop on Software Stability at Work SSW 2007 Invitation Las Vegas, USA, August 13-15, 2007 (in conjunction with IEEE IRI 2007) http://www.sis.pitt.edu/~iri07/ (IEEE IRI 2007 Link) http://www.sis.pitt.edu/~iri07/wkshpCFP3.html (Main Link) http://www.engr.sjsu.edu/~fayad/workshops/IRI07-SSW (Workshop Link 2) http://www.vrlsoft.com/workshops/SSW07 (Workshop Link 3) Greetings, I would like to invite you to participate in The 2nd IEEE International Workshop on Software Stability at Work. (SSW 2007)" In conjunction with The 2007 IEEE International Conference on Information Reuse and Integration (http://www.sis.pitt.edu/~iri07/), which will take place in Las Vegas, Nevada, August 13-15, 2OO7 by submitting a paper or two before or on April 15, 2007. A call of papers for the workshop is enclosed and it can be found at: http://www.sis.pitt.edu/~iri07/wkshpCFP3.html (Main Link) http://www.engr.sjsu.edu/~fayad/workshops/IRI07-SSW (Workshop Link 2) http://www.vrlsoft.com/workshops/SSW07 (Workshop Link 3) Accepted papers will be published in the proceedings (EI Index) of the The 2007 IEEE International Conference on Information Reuse and Integration (IEEE IRI 2007). The workshop selected best papers will be published in online Journal of International Journal Of Patterns (IJOP). Looking forward to your submission and participation in the workshop! All the best, Cheers, Dr. M.E. Fayad (Chair) Dr. Rami Bahsoon (Co-Chair) Dr. Chia-Chu Chiang (Co-Chair) Dr. Shasha Wu (Co-Chair) -- ijop.org -- Powered by PHPlist, www.phplist.com -- _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 03 07:34:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYhGZ-0000Pp-Dh; Tue, 03 Apr 2007 07:33:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYhGV-0000KG-4M for mip6@ietf.org; Tue, 03 Apr 2007 07:33:31 -0400 Received: from mail42.messagelabs.com ([216.82.244.163]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HYhGQ-0008BN-Qz for mip6@ietf.org; Tue, 03 Apr 2007 07:33:31 -0400 X-VirusChecked: Checked X-Env-Sender: Anurag.Uxa@lntinfotech.com X-Msg-Ref: server-9.tower-42.messagelabs.com!1175600003!26997064!1 X-StarScan-Version: 5.5.10.7.1; banners=lntinfotech.com,-,- X-Originating-IP: [203.101.96.4] Received: (qmail 6304 invoked from network); 3 Apr 2007 11:33:24 -0000 Received: from bangaloresmtp.lntinfotech.com (HELO Bangaloresmtp.lntinfotech.com) (203.101.96.4) by server-9.tower-42.messagelabs.com with SMTP; 3 Apr 2007 11:33:24 -0000 Received: from Bangalore.lntinfotech.com ([172.28.0.3]) by Bangaloresmtp.lntinfotech.com (Lotus Domino Release 6.5.4) with ESMTP id 2007040317041112-73763 ; Tue, 3 Apr 2007 17:04:11 +0530 To: Vijay Devarapalli , Rajeev Koodli , Yoshihiro Ohba , Basavaraj.Patil@nokia.com, Francis Dupont , "'mip6@ietf.org'" , STDS-802-21@listserv.ieee.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.3 September 14, 2004 Message-ID: From: Anurag Uxa Date: Tue, 3 Apr 2007 17:04:12 +0530 X-MIMETrack: Serialize by Router on BANGALORE/LNTINFOTECH(Release 6.5.5|November 30, 2005) at 04/03/2007 05:04:13 PM, Serialize complete at 04/03/2007 05:04:13 PM, Itemize by SMTP Server on BANGALORESMTP/LNTINFOTECH(Release 6.5.4|March 27, 2005) at 04/03/2007 05:04:11 PM, Serialize by Router on BANGALORESMTP/LNTINFOTECH(Release 6.5.4|March 27, 2005) at 04/03/2007 05:04:12 PM, Serialize complete at 04/03/2007 05:04:12 PM X-Spam-Score: 0.3 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: Subject: [Mip6] Home Address X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1082405973==" Errors-To: mip6-bounces@ietf.org This is a multipart message in MIME format. --===============1082405973== Content-Type: multipart/alternative; boundary="=_alternative 003F8C27652572B2_=" This is a multipart message in MIME format. --=_alternative 003F8C27652572B2_= Content-Type: text/plain; charset="US-ASCII" Dear All, Greetings. This is regarding multiple home address for a single end held device. I have read few drafts on Analysis of Multihoming and issues also. Couldn't catch up all the discussion at Mip6 mailing list regarding that too. I would like to know, What is the solution we have taken up for HoA (Home Address) for multiple Interfaces of a single device. I would like to know if any thing come as a standard? As implementation wise there is no issue to keep one address as HoA for All the interfaces of Multi interface device. If there is no std. till now, I still feel keeping multiple Home address for a single device is not a wise idea? --Pls comment on this?? Regards ---------------------------------------------------------------------- Anurag Uxa Communication & Embedded systems Larsen & Toubro Infotech Limited # Plot No.25 - 30 EPIP 1st Phase Industrial Area, Whitefield,Bangalore - 560066 Direct No: 080 - 55242030 GSM: 9886751340 Email Id : anurag.uxa@lntinfotech.com www.lntinfotech.com ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ ( ) L&T Infotech Proprietary & Confidential (+) L&T Infotech Confidential ( ) L&T Infotech Internal Use only ( ) General Business Information ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ ______________________________________________________________________ --=_alternative 003F8C27652572B2_= Content-Type: text/html; charset="US-ASCII"
Dear All,

Greetings.

This is regarding multiple home address for a single end held device. I have read few drafts on Analysis of Multihoming and issues also. Couldn't catch up all the discussion at Mip6 mailing list  regarding that too. I would like to know, What is the solution we have taken up for HoA (Home Address) for multiple Interfaces of a single device.
I would like to know if any thing come as a standard? As implementation wise there is no issue to keep one address as HoA for All the interfaces of Multi interface device. If there is no std. till now, I still feel keeping multiple Home address for a single device is not a wise idea? --Pls comment on this??

Regards
----------------------------------------------------------------------
Anurag Uxa
Communication & Embedded systems
Larsen & Toubro Infotech Limited
# Plot No.25 - 30 EPIP 1st Phase Industrial Area,
Whitefield,Bangalore - 560066
Direct No: 080 - 55242030
GSM: 9886751340
Email Id : anurag.uxa@lntinfotech.com
www.lntinfotech.com
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
( ) L&T Infotech Proprietary & Confidential
(+) L&T Infotech Confidential
( ) L&T Infotech Internal Use only
( ) General Business Information
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
______________________________________________________________________
--=_alternative 003F8C27652572B2_=-- --===============1082405973== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1082405973==-- From mip6-bounces@ietf.org Tue Apr 03 07:37:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYhKW-0003Km-Vs; Tue, 03 Apr 2007 07:37:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYhKV-0003Ij-8B for mip6@ietf.org; Tue, 03 Apr 2007 07:37:39 -0400 Received: from py-out-1112.google.com ([64.233.166.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYhKQ-0000R9-UC for mip6@ietf.org; Tue, 03 Apr 2007 07:37:39 -0400 Received: by py-out-1112.google.com with SMTP id f31so202860pyh for ; Tue, 03 Apr 2007 04:37:34 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=f0cQZRyJP5gNjDaj9bC6cs7WiFEA7jNJXOUJhcQLDWa9KqEqmD5XwyhYPSXokSsNpLF9QYVLr4oXeKhEWkHmb0HRI0GoGWcWMd8nM9UfXvCKWfjrtHYzAI4rUETQA0Z4e62CstNtI0lcJoSjd4lPckcTtBHaufR/sdQFQqVHLKw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=Y/wakJV529+wOguJm6CS6ohL5pyPX5JKSh4YHYpFcYGSEQ1Nu3f2yxas//UTmRdYDMMTZc0YWqKUhwWtXnHgyl1ONX8IZDro3McJ/Yhee2l4oLIf3VGyboDNURdjPgM6bvk83Jq+7LSJSJa70YHJfOOW0oS0kBYfgj61XY3wzic= Received: by 10.35.50.5 with SMTP id c5mr11171835pyk.1175600254517; Tue, 03 Apr 2007 04:37:34 -0700 (PDT) Received: from ?203.178.139.237? ( [203.178.139.237]) by mx.google.com with ESMTP id w43sm9208759pyg.2007.04.03.04.37.32; Tue, 03 Apr 2007 04:37:33 -0700 (PDT) In-Reply-To: <460A4448.1050507@azairenet.com> References: <20070328073355.B105DFB956@sh1.iijlab.net> <3738B0C4-E0BE-4BE3-93BB-50FAD8D9CFED@iijlab.net> <460A4448.1050507@azairenet.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4C0B4410-5782-46DE-9EAB-279F2F67F232@gmail.com> Content-Transfer-Encoding: 7bit From: RYUJI WAKIKAWA Subject: Re: [Mip6] Re: concensus on [issue94] fixing encapsulation mechanism in IPv4 network Date: Tue, 3 Apr 2007 20:37:27 +0900 To: Vijay Devarapalli X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: mip6@ietf.org, Keiichi SHIMA X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi I prefer A, but i want one clarification. When a HA receives a BU setting the flag, how it can override the flag? I want to know whether HA just accepts the BU or not. As keiichi mentioned, if mobile nodes supporting only UDP-tunnel are available, It will be a problem if HA simply accepts the BU and overrides it by BA. Even if the BU is accepted, the MN cannot establish a tunnel with the HA. The HA will keep the garbage binding status during the active lifetime if the MN just gives up IP-in-IP. The HA should rejects the BU and notifies its preference to the MN by the BA. The MN can re-try the new BU with the HA. MN should accept this burden since it requests the preference to the HA. regards, ryuji On 2007/03/28, at 19:32, Vijay Devarapalli wrote: > Keiichi SHIMA wrote: >> Hello Hesham, >> I think the text explaining the option 'A' is not exactly what I >> proposed in my previous mail. Please let me clarify the text >> about the option 'A'. >> On 2007/03/28, at 16:33, Hesham Soliman wrote: >>> A. Add a flag that allows the MN to request UDP tunnelling interface >>> (independently of the presence of a NAT) from the HA, when >>> sending the BU. >>> The HA can override the MN's request. Or, >> The idea is to introduce a new flag for MN to request the UDP >> tunnel mode. Let's call it as the 'U (requesting UDP tunnel)' >> flag. If the MN doesn't specify the 'U' flag, the behavior is >> exactly the same as the current specification. The HA can decide >> what kind of tunneling mechanism (IP-in-IP or UDP-in-IP). >> When the MN sets the 'U' flag on, the HA always replies with the >> 'F (Force UDP tunnel)' flag. This is a new behavior what I want >> to propose. > > We would also need to mention when the MN would be setting this > flag. Is it when it wants to use UDP encapsulation due to > implementation related considerations? I guess you want to use > the 'U' flag for this. > > But there are others who have expressed that this flag can be > used for firewall traversal. Since the MN wouldn't know if > there is a firewall on the path, it would end up setting the > 'U' flag all the time. If the HA can't override it, then > providing a NAT detection mechanism is useless, IMO. > Vijay > >> The HA shouldn't override the 'U' flag. If we allow overriding >> the 'U' flag, then there is no difference between the option 'A' >> and 'B'. >> Regards, >> --- >> Keiichi SHIMA >> IIJ Research Laboratory >> WIDE Project >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 03 11:07:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYkaq-00073F-RI; Tue, 03 Apr 2007 11:06:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYkao-0006z2-T0 for mip6@ietf.org; Tue, 03 Apr 2007 11:06:42 -0400 Received: from discorde.inria.fr ([192.93.2.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYkaf-0000lU-5h for mip6@ietf.org; Tue, 03 Apr 2007 11:06:42 -0400 Received: from iseran.local (dhcp-rocq-244.inria.fr [128.93.62.244]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l33F6PCW021207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Apr 2007 17:06:26 +0200 Date: Tue, 3 Apr 2007 17:06:25 +0200 From: Thierry Ernst To: "E.Segura" Subject: Re: [Mip6] 2nd IEEE International Workshop on Software Stability at Work (SSW 2007) Message-Id: <20070403170625.370c3164.thierry.ernst@inria.fr> In-Reply-To: References: Organization: INRIA X-Mailer: Sylpheed version 2.2.3 (GTK+ 2.10.6; powerpc-apple-darwin8.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Miltered: at discorde with ID 46126D71.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam-Score: 0.1 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org I'm not against seeing CFP for conferences and workshops when there is a direct link with the work being done by the IETF WG where it is posted, but otherwise I'm assuming this as spam. So, please refrain using IETF mailing lists for such out of focus announces. Thanks, Thierry. On Tue, 3 Apr 2007 03:52:58 -0700 "E.Segura" wrote: > > >The 2nd IEEE International Workshop on > >Software Stability at Work > >SSW 2007 > >Invitation > >Las Vegas, USA, August 13-15, 2007 > >(in conjunction with IEEE IRI 2007) > >http://www.sis.pitt.edu/~iri07/ (IEEE IRI 2007 Link) > >http://www.sis.pitt.edu/~iri07/wkshpCFP3.html (Main Link) > >http://www.engr.sjsu.edu/~fayad/workshops/IRI07-SSW (Workshop Link 2) > >http://www.vrlsoft.com/workshops/SSW07 (Workshop Link 3) > >Greetings, > >I would like to invite you to participate in The 2nd IEEE >International Workshop on Software Stability at Work. (SSW 2007)" In >conjunction with The 2007 IEEE International Conference on >Information Reuse and Integration (http://www.sis.pitt.edu/~iri07/), >which will take place in Las Vegas, Nevada, August 13-15, 2OO7 by >submitting a paper or two before or on April 15, 2007. A call of >papers for the workshop is enclosed and it can be found at: > >http://www.sis.pitt.edu/~iri07/wkshpCFP3.html (Main Link) > >http://www.engr.sjsu.edu/~fayad/workshops/IRI07-SSW (Workshop Link 2) > >http://www.vrlsoft.com/workshops/SSW07 (Workshop Link 3) > >Accepted papers will be published in the proceedings (EI Index) of >the The 2007 IEEE International Conference on Information Reuse and >Integration (IEEE IRI 2007). The workshop selected best papers will >be published in online Journal of International Journal Of Patterns >(IJOP). > >Looking forward to your submission and participation in the workshop! > >All the best, > >Cheers, > >Dr. M.E. Fayad (Chair) > >Dr. Rami Bahsoon (Co-Chair) > >Dr. Chia-Chu Chiang (Co-Chair) > >Dr. Shasha Wu (Co-Chair) > > > >-- >ijop.org > > >-- >Powered by PHPlist, www.phplist.com -- > > > >_______________________________________________ >Mip6 mailing list >Mip6@ietf.org >https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Apr 04 02:35:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYz3X-0004Wn-Mn; Wed, 04 Apr 2007 02:33:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYz3V-0004Sk-JH for mip6@ietf.org; Wed, 04 Apr 2007 02:33:17 -0400 Received: from omta03ps.mx.bigpond.com ([144.140.82.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYz3R-0006Wr-0W for mip6@ietf.org; Wed, 04 Apr 2007 02:33:17 -0400 Received: from oaamta03ps.mx.bigpond.com ([124.191.178.123]) by omta03ps.mx.bigpond.com with ESMTP id <20070404063300.ISMY8709.omta03ps.mx.bigpond.com@oaamta03ps.mx.bigpond.com> for ; Wed, 4 Apr 2007 06:33:00 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta03ps.mx.bigpond.com with ESMTP id <20070404063300.INGO24764.oaamta03ps.mx.bigpond.com@PC20005> for ; Wed, 4 Apr 2007 06:33:00 +0000 From: "Hesham Soliman" To: Subject: RE: [Mip6] concensus on [issue94] fixing encapsulation mechanism inIPv4 network Date: Wed, 4 Apr 2007 16:32:56 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 thread-index: Acdvp4ir24juDDX7T/W2EI/t8u6K5AAHI6bAAFGVW+ABXgog8A== Message-Id: <20070404063300.INGO24764.oaamta03ps.mx.bigpond.com@PC20005> X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Ok, I don't think it's Tuesday anywhere in the world now, so it's time to declare concensus for Option A. This means that the spec will allow the MN to request UDP tunnelling in the BU. If the HA does not accept the UDP tunnelling request it will reject the BU with a new error code. I think this reflects the concensus of the WG on this issue. Obviously, all of this applies to the case where the MN is in a network that does not support IPv6. I will send detailed text changes in a separate email. Thanks, Hesham > -----Original Message----- > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > Sent: Wednesday, March 28, 2007 5:33 PM > To: 'Keiichi SHIMA' > Cc: mip6@ietf.org > Subject: [Mip6] concensus on [issue94] fixing encapsulation > mechanism inIPv4 network > > Kiichi, all, > > I think we've seen the different angles of this issue now > and it's time to > close it. > So I suggest that we choose one of the two options listed below. > > Folks, > > The "new" issue is about whether or not the MN can request > one form of > tunnelling (i.e. UDP) when sending a BU to the HA. The two > choices we have > are: > > A. Add a flag that allows the MN to request UDP tunnelling interface > (independently of the presence of a NAT) from the HA, when > sending the BU. > The HA can override the MN's request. Or, > > B. Do nothing. I.e. the MN sends the BU as described in the > spec today and > the HA tells the MN in the BA whether it should use UDP > tunnelling or IP in > IP. > > Please express your preference for one of the options above. > Let's not make > things complicated and get into negotiating the tunnelling > mechanism, one of > the two above will suffice. > > I'll leave it open till next Tuesday. > > Thanks, > Hesham > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Apr 04 02:35:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYz46-0004q1-8T; Wed, 04 Apr 2007 02:33:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYz45-0004oK-9P for mip6@ietf.org; Wed, 04 Apr 2007 02:33:53 -0400 Received: from omta03ps.mx.bigpond.com ([144.140.82.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYz43-0006cE-32 for mip6@ietf.org; Wed, 04 Apr 2007 02:33:53 -0400 Received: from oaamta03ps.mx.bigpond.com ([124.191.178.123]) by omta03ps.mx.bigpond.com with ESMTP id <20070404063349.ITFT8709.omta03ps.mx.bigpond.com@oaamta03ps.mx.bigpond.com>; Wed, 4 Apr 2007 06:33:49 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta03ps.mx.bigpond.com with ESMTP id <20070404063348.INPC24764.oaamta03ps.mx.bigpond.com@PC20005>; Wed, 4 Apr 2007 06:33:48 +0000 From: "Hesham Soliman" To: "'Mip6 issue tracker'" , Date: Wed, 4 Apr 2007 16:33:46 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 thread-index: AcdthSMURGWmZPbsQ+KWVHV73j689QDusETQAVDQNpA= Message-Id: <20070404063348.INPC24764.oaamta03ps.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: Subject: [Mip6] RE: Concensus on text for [issue95] Mention DHCPv6 based Home Agent discoverymechanism in section X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Folks, This issue is also closed. Thanks, Hesham > -----Original Message----- > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > Sent: Wednesday, March 28, 2007 11:58 PM > To: 'Mip6 issue tracker'; 'mip6@ietf.org' > Subject: Concensus on text for [issue95] Mention DHCPv6 > based Home Agent discoverymechanism in section > > > Folks, > > This is a straighforward issue that needs a small editorial > change. Please see Kuntal's issue text and my suggestion below: > > > This issue has been discussed on the list. The current text > > in section 2.1 needs > > to cover cases when DHCPv6 can be used to discover Home > > Agent information. The > > email thread on this issue: > > > > http://www1.ietf.org/mail-archive/web/mip6/current/msg05877.html > > > > Proposed text: > > ------------- > > Current: > > > > "....If a mobile > > node is located in an IPv4-only foreign network, it > cannot rely on > > native IPv6 routing. The preferred solution for > > discovering the home > > agent's IPv4 address is through the Domain Name System (DNS). > > " > > > > New: > > > > If a mobile node is located in an IPv4-only foreign network, > > it cannot rely on > > native IPv6 routing. In this scenario, the solution for > > discovering the home > > agent's IPv4 address is through the Domain Name System (DNS). > > > > Also add the following in this section: > > > > If the MN is attached to an IPv6-only or it is attached to > > an IPv6 and IPv4 Dual > > stack foreign network, it shall use procedures defined in > > draft-ietf-mip6-bootstrapping-integrated-dhc-02.txt [add > > this reference] to > > discover Home Agent information. > > > I suggest modifying the text above to: > > If a mobile node is located in an IPv4-only foreign network, > it cannot rely on native IPv6 routing. In this scenario, the > solution for > discovering the home agent's IPv4 address is through the > Domain Name System (DNS). If the MN is attached to an > IPv6-only or dual stack network, it may also use procedures > defined in [INTBOOT] to discover Home Agent information. > Note that the use of [INTBOOT] cannot give the mobile node > information that allows it to continue to communicate with > the Home Agent if, for example, the mobile node moved from > an IPv6-enabled network to an IPv4-only network. In such > scenario, the mobile node would need to discover the IPv4 > address of its home agent through the DNS. > > > > [INTBOOT] draft-ietf-mip6-bootstrapping-integrated-dhc-02.txt > > > I think it's important to make sure that the consequences of > the choice are clear to the implementer, that's why I added > the last two sentences. > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Apr 05 17:29:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZZV5-0004bd-Td; Thu, 05 Apr 2007 17:28:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZZV4-0004bX-CU for mip6@ietf.org; Thu, 05 Apr 2007 17:28:10 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZZV2-0005N0-GK for mip6@ietf.org; Thu, 05 Apr 2007 17:28:10 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l35LRq8Y031230 for ; Fri, 6 Apr 2007 00:28:05 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Apr 2007 00:28:01 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Apr 2007 16:27:56 -0500 Received: from 172.19.244.111 ([172.19.244.111]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Thu, 5 Apr 2007 21:27:56 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Thu, 05 Apr 2007 16:28:19 -0500 From: Basavaraj Patil To: Mobile IPv6 Mailing List Message-ID: Thread-Topic: Consensus call on DS-MIP6 issue 73 (IPv4 CoA in the BU) Thread-Index: Acd3yVRPktVpm+O8EduKwAARJNUNiA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 05 Apr 2007 21:27:56.0911 (UTC) FILETIME=[472557F0:01C777C9] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Mip6] Consensus call on DS-MIP6 issue 73 (IPv4 CoA in the BU) X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hello, I would like to get consensus from the WG on another DS-MIP6 issue which is pending resolution. The issue is about how to include the IPv4 CoA of the MN in the binding update. The choices are: 1. Keep the IPv4 mapped address in the source address field when sending the BU 2. Remove the IPv4 mapped address from the src address of the BU and replace it with the Home address. The IPv4 care-of address will be included in a new IPv4 alt-CoA option. Please express your opinion and preference (a brief justification of why would be useful but not required) by Thursday, April 12th 07. The issue has been noted and is in the tracker at: http://www.mip4.org/issues/tracker/mip6/issue73 -Basavaraj _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Apr 05 18:07:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZa6M-0005XY-Tt; Thu, 05 Apr 2007 18:06:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZa6L-0005X7-2a for mip6@ietf.org; Thu, 05 Apr 2007 18:06:41 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HZa6J-0006VL-JC for mip6@ietf.org; Thu, 05 Apr 2007 18:06:40 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l35M6TJ7026824 for ; Fri, 6 Apr 2007 01:06:34 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Apr 2007 01:06:29 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Apr 2007 17:06:20 -0500 Received: from 172.19.244.111 ([172.19.244.111]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Thu, 5 Apr 2007 22:06:20 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Thu, 05 Apr 2007 17:06:43 -0500 From: Basavaraj Patil To: Mobile IPv6 Mailing List Message-ID: Thread-Topic: Dynamic HoA assignment Thread-Index: Acd3zrGa7+A1ruPBEduKwAARJNUNiA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 05 Apr 2007 22:06:20.0687 (UTC) FILETIME=[A44DA9F0:01C777CE] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Mip6] Dynamic HoA assignment X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hello, Currently the I-D draft-ietf-mip6-hiopt proposes the MN obtain the HoA as well in addition to the HA address and prefix via DHCP. I think the MN should obtain the minimal information required to bootstrap. It is better to have the HA assign the MN an HoA. To do this we would require capability similar to MIP4 wherein the BU can be sent with an unspecified HoA. This is currently not possible as per RFC3775. Should we consider allowing the MN sending a BU with the unspecified HoA and obtain an HoA (assigned by the HA) in the BAck? I-D: draft-devarapalli-mip6-authprotocol-bootstrap proposes such capability. Also do we need to consider standardizing the bootstrapping mechanism for the auth protocol (RFC 4285)? -Basavaraj _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Apr 05 18:44:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZagP-0002yj-F6; Thu, 05 Apr 2007 18:43:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZagN-0002ye-Cy for mip6@ietf.org; Thu, 05 Apr 2007 18:43:55 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZagM-0006v9-2o for mip6@ietf.org; Thu, 05 Apr 2007 18:43:55 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Apr 2007 15:43:49 -0700 Message-ID: <46157BA1.2030500@azairenet.com> Date: Thu, 05 Apr 2007 15:43:45 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Basavaraj Patil Subject: Re: [Mip6] Consensus call on DS-MIP6 issue 73 (IPv4 CoA in the BU) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Apr 2007 22:43:49.0465 (UTC) FILETIME=[E0ADF490:01C777D3] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Raj, Can't we conclude on this issue based on the discussion so far on Issue 73? There has already been a lot of discussion on this issue. This seems to be yet another consensus call on this subject. Vijay Basavaraj Patil wrote: > Hello, > > I would like to get consensus from the WG on another DS-MIP6 issue > which is pending resolution. > > The issue is about how to include the IPv4 CoA of the MN in the > binding update. > > The choices are: > > 1. Keep the IPv4 mapped address in the source address field when > sending the BU > > 2. Remove the IPv4 mapped address from the src address of the BU and > replace it with the Home address. The IPv4 care-of address will be > included in a new IPv4 alt-CoA option. > > Please express your opinion and preference (a brief justification of > why would be useful but not required) by Thursday, April 12th 07. > > The issue has been noted and is in the tracker at: > http://www.mip4.org/issues/tracker/mip6/issue73 > > -Basavaraj > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 06 03:40:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZj2T-0007tb-PZ; Fri, 06 Apr 2007 03:39:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZj2S-0007tT-AT for mip6@ietf.org; Fri, 06 Apr 2007 03:39:16 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZj2M-0003gZ-TM for mip6@ietf.org; Fri, 06 Apr 2007 03:39:16 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 06 Apr 2007 09:39:10 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l367dA2Z022235; Fri, 6 Apr 2007 09:39:10 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l367dAlZ022340; Fri, 6 Apr 2007 07:39:10 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Apr 2007 09:39:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Consensus call on DS-MIP6 issue 73 (IPv4 CoA in the BU) Date: Fri, 6 Apr 2007 09:39:02 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC03BEE375@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Consensus call on DS-MIP6 issue 73 (IPv4 CoA in the BU) Thread-Index: Acd3yVRPktVpm+O8EduKwAARJNUNiAAVFX5A References: From: "Pascal Thubert \(pthubert\)" To: "Basavaraj Patil" , "Mobile IPv6 Mailing List" X-OriginalArrivalTime: 06 Apr 2007 07:39:10.0157 (UTC) FILETIME=[AA1A97D0:01C7781E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1696; t=1175845150; x=1176709150; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20\(pthubert\)=22=20 |Subject:=20RE=3A=20[Mip6]=20Consensus=20call=20on=20DS-MIP6=20issue=2073 =20(IPv4=20CoA=20in=20the=20BU) |Sender:=20; bh=kmhiRjlUN2sWhAQ3UQ9qOwoFzPE/mJGdpflU/PxHR7I=; b=gzLlXoABamolt0L7U1YNrGAXEreogdjgGASjFvnomDye7w0KxHEOn7muz2sxbO3duMceXrzx ivYsT3RNTpBP4ia68E7WQsrIHUpwoD6/FYKwCoca3l/g5RY4lly1U2s7; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Raj: My vote is 1, keep the IPv4 mapped address. Some time ago, the design team elected Hesham's draft as base and that was one of its main features. I do not see a value in changing anything at this point. When I implemented an early draft of ipv4 traversal, I found that the mapped address allowed me to limit the changes in the base HA code. OTOH, adding a new option is new code and new test on existing implementations, and we have to describe (and code for) the cohabitation of options which might not be compatible.=20 Pascal >-----Original Message----- >From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] >Sent: Thursday, April 05, 2007 11:28 PM >To: Mobile IPv6 Mailing List >Subject: [Mip6] Consensus call on DS-MIP6 issue 73 (IPv4 CoA in the BU) > > >Hello, > >I would like to get consensus from the WG on another DS-MIP6 issue >which is pending resolution. > >The issue is about how to include the IPv4 CoA of the MN in the >binding update. > >The choices are: > >1. Keep the IPv4 mapped address in the source address field when > sending the BU > >2. Remove the IPv4 mapped address from the src address of the BU and > replace it with the Home address. The IPv4 care-of address will be > included in a new IPv4 alt-CoA option. > >Please express your opinion and preference (a brief justification of >why would be useful but not required) by Thursday, April 12th 07. > >The issue has been noted and is in the tracker at: >http://www.mip4.org/issues/tracker/mip6/issue73 > >-Basavaraj > > >_______________________________________________ >Mip6 mailing list >Mip6@ietf.org >https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 06 04:53:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZkBa-0004sS-JG; Fri, 06 Apr 2007 04:52:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZkBY-0004q9-48 for mip6@ietf.org; Fri, 06 Apr 2007 04:52:44 -0400 Received: from ug-out-1314.google.com ([66.249.92.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZkBW-0001Bb-PL for mip6@ietf.org; Fri, 06 Apr 2007 04:52:44 -0400 Received: by ug-out-1314.google.com with SMTP id 72so1099998ugd for ; Fri, 06 Apr 2007 01:52:42 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=eGFFP7Xry6J2hJXPx8nPDGkauKSXpB/V+IkZY+PJ+pqwZ44kQo4VfwChi9dbjjzraHraXENCRr0zd5WccN7GyWzvZnhSeK2oa74aDTMAoHRK/200ShhQXPSiRKf9yHD+Woa7pHVmlFQWfvJqKwRvR9oMcQibf4B/0BXqHTCBpUc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=gu3fy3MbJQc1i+ekdeP8FnSbNa0UE6z0icVIlzAdLJ0gZjszRXvnRrDDZgCIXCmLfUTbJuLe2MAUK8zVZHn4bDWDn3x+9ZJ3UyP3yD443G1Oz5/DlzW1cLQO5GIanI2xTpExWkywXv3cxFjMjvLf7YkrBby7TGtRkuWNJtnwLQM= Received: by 10.67.50.7 with SMTP id c7mr2845960ugk.1175849562021; Fri, 06 Apr 2007 01:52:42 -0700 (PDT) Received: by 10.66.238.9 with HTTP; Fri, 6 Apr 2007 01:52:41 -0700 (PDT) Message-ID: Date: Fri, 6 Apr 2007 10:52:41 +0200 From: "Gerardo Giaretta" To: "Basavaraj Patil" Subject: Re: [Mip6] Dynamic HoA assignment In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Raj, > Hello, > > Currently the I-D draft-ietf-mip6-hiopt proposes the MN obtain the HoA as > well in addition to the HA address and prefix via DHCP. > > I think the MN should obtain the minimal information required to bootstrap. > It is better to have the HA assign the MN an HoA. I fully agree. The HA is the node in the better position to assign the HoA. This is the rationale behind the choices made by the bootstrapping DT two years ago. > To do this we would > require capability similar to MIP4 wherein the BU can be sent with an > unspecified HoA. This is currently not possible as per RFC3775. > I guess you are talking about rfc4285 (auth protocol). If IPsec is used, IKEv2 can be used to assign the HoA, as specified in draft-ietf-mip6-bootstrapping-split > Should we consider allowing the MN sending a BU with the unspecified HoA and > obtain an HoA (assigned by the HA) in the BAck? > Again this would be needed only for auth protocol. No need for this if IPsec is used. > I-D: draft-devarapalli-mip6-authprotocol-bootstrap proposes such capability. > Also do we need to consider standardizing the bootstrapping mechanism for > the auth protocol (RFC 4285)? > Some SDOs use rfc4285 authentication for MIPv6, but as far as I know, they have already defined their own bootstrapping solution. What would be the role of an IETF solution with regards to those? --Gerardo > -Basavaraj > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 06 10:27:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZpOj-0003HR-9V; Fri, 06 Apr 2007 10:26:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZpOi-0003HL-S9 for mip6@ietf.org; Fri, 06 Apr 2007 10:26:40 -0400 Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZpOg-0006DZ-EG for mip6@ietf.org; Fri, 06 Apr 2007 10:26:40 -0400 Received: from lor-maknavic3.int-evry.fr (lor-maknavic3.int-evry.fr [157.159.103.217]) by smtp2.int-evry.fr (Postfix) with ESMTP id 0CEAF2FF63; Fri, 6 Apr 2007 16:26:31 +0200 (CEST) Subject: Re: [Mip6] Dynamic HoA assignment From: Pars Mutaf To: Basavaraj Patil In-Reply-To: References: Content-Type: text/plain Organization: INT Evry Date: Fri, 06 Apr 2007 16:26:59 +0200 Message-Id: <1175869619.28166.52.camel@lor-maknavic3.int-evry.fr> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-MCPCheck: X-INT-MailScanner-SpamCheck: X-INT-MailScanner-From: pars.mutaf@int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pars.mutaf@int-evry.fr List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hello, I'm probably offside but I think this is a great idea. I would fully encourage any technique for dynamically generating HoAs (IKEv2 CONFIG_PAYLOAD or MIPv6 BU/BACK). I think that sharing the Same HoA with all correspondents is really a bad idea. Assuming that a mobile host will be reachable via a public phone directory (or DNS, or alike) is also unrealistic. This model was left by cellular users longtime ago. Users share private reachability information (phone number currently) in a manner that is under their control. I suspect that a mobile user will need (and will prefer having) as many as 100 or 200 home addresses (for example) that are configured/removed dynamically by the mobile host upon user request, and distributed under user control. IPv6 space is not as precious as IPv4 space. A different HoA will be distributed to each known mobile host. Details are local policy issues. http://www.ietf.org/internet-drafts/draft-mutaf-dhoa-00.txt (note: the I-D needs a lot of work but the home addresses I'm talking about in this I-D have nothing new, I'm rather proposing a novel MIPv6 usage model) I seriously hope that this usage model is possible. Best regards, On Thu, 2007-04-05 at 17:06 -0500, Basavaraj Patil wrote: > Hello, > > Currently the I-D draft-ietf-mip6-hiopt proposes the MN obtain the HoA as > well in addition to the HA address and prefix via DHCP. > > I think the MN should obtain the minimal information required to bootstrap. > It is better to have the HA assign the MN an HoA. To do this we would > require capability similar to MIP4 wherein the BU can be sent with an > unspecified HoA. This is currently not possible as per RFC3775. > > Should we consider allowing the MN sending a BU with the unspecified HoA and > obtain an HoA (assigned by the HA) in the BAck? > > I-D: draft-devarapalli-mip6-authprotocol-bootstrap proposes such capability. > Also do we need to consider standardizing the bootstrapping mechanism for > the auth protocol (RFC 4285)? > > -Basavaraj > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 06 11:40:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZqXV-0007Jd-0G; Fri, 06 Apr 2007 11:39:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZqXT-0007JY-Ss for mip6@ietf.org; Fri, 06 Apr 2007 11:39:47 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZqXQ-0001Oe-CG for mip6@ietf.org; Fri, 06 Apr 2007 11:39:47 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 8989E9000E for ; Fri, 6 Apr 2007 11:39:40 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11788-05 for ; Fri, 6 Apr 2007 11:39:35 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Fri, 6 Apr 2007 11:39:35 -0400 (EDT) Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Apr 2007 11:39:35 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Dynamic HoA assignment Date: Fri, 6 Apr 2007 11:39:35 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D7024D9DDF@exchtewks2.starentnetworks.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Dynamic HoA assignment Thread-Index: Acd4KTL8NsN3pb1ZT361m3HioT2u+wAN0EHA From: "Chowdhury, Kuntal" To: "Gerardo Giaretta" , "Basavaraj Patil" X-OriginalArrivalTime: 06 Apr 2007 15:39:35.0509 (UTC) FILETIME=[C75A4050:01C77861] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org HI Gerardo, Raj, > -----Original Message----- > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > Sent: Friday, April 06, 2007 3:53 AM > To: Basavaraj Patil > Cc: Mobile IPv6 Mailing List > Subject: Re: [Mip6] Dynamic HoA assignment >=20 > Hi Raj, >=20 > > Hello, > > > > Currently the I-D draft-ietf-mip6-hiopt proposes the MN obtain the HoA > as > > well in addition to the HA address and prefix via DHCP. > > > > I think the MN should obtain the minimal information required to > bootstrap. > > It is better to have the HA assign the MN an HoA. >=20 > I fully agree. The HA is the node in the better position to assign the > HoA. This is the rationale behind the choices made by the > bootstrapping DT two years ago. >=20 [KC>] We are talking about basic DHCP capability as defined in draft-ietf-mip6-hiopt. We are NOT talking about the MIP6 bootstrapping solutions that came out of the DT. The inclusion of HoA in draft-ietf-mip6-bootstrapping-integrated-02.txt was debated over the ML and in Prague meeting. At this time, we have decided to NOT include HoA in draft-ietf-mip6-bootstrapping-integrated-02.txt. However, this should not be linked with what can be done in DHCP. If someone wants to assign HoA via DHCP regardless of which mip6 bootstrapping solution is used or not used, it should be allowed, IMHO. BTW, it was added in the draft-ietf-mip6-hiopt because SDOs like WiMAX forum needed such info in DHCP. > > To do this we would > > require capability similar to MIP4 wherein the BU can be sent with an > > unspecified HoA. This is currently not possible as per RFC3775. > > >=20 > I guess you are talking about rfc4285 (auth protocol). If IPsec is > used, IKEv2 can be used to assign the HoA, as specified in > draft-ietf-mip6-bootstrapping-split >=20 [KC>] Again, regardless of IKEv2, we should allow the dynamic HoA assignment via mip6 BU/BA. People may like to do HoA (address) management based on MIP6 _authorization_ and NOT IKEv2 _authentication_. > > Should we consider allowing the MN sending a BU with the unspecified HoA > and > > obtain an HoA (assigned by the HA) in the BAck? > > >=20 > Again this would be needed only for auth protocol. No need for this if > IPsec is used. >=20 [KC>] Nope, we should allow it via BU/BA as well. > > I-D: draft-devarapalli-mip6-authprotocol-bootstrap proposes such > capability. > > Also do we need to consider standardizing the bootstrapping mechanism > for > > the auth protocol (RFC 4285)? > > >=20 > Some SDOs use rfc4285 authentication for MIPv6, but as far as I know, > they have already defined their own bootstrapping solution. What would > be the role of an IETF solution with regards to those? >=20 [KC>] role of IETF is to define an IETF way to provide dynamic HoA allocation capability via mip6 BU/BA. We don't have that today. Also, you are forgetting the per-Node SA model that is used in PMIP6. We need this capability for PMIP6 also. > --Gerardo >=20 > > -Basavaraj > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 06 17:40:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZwAP-0007pF-IS; Fri, 06 Apr 2007 17:40:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZwAO-0007p0-D0 for mip6@ietf.org; Fri, 06 Apr 2007 17:40:20 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZwAM-00060e-9k for mip6@ietf.org; Fri, 06 Apr 2007 17:40:20 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l36Ldxas015797; Sat, 7 Apr 2007 00:40:16 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 7 Apr 2007 00:40:10 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Apr 2007 16:40:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Dynamic HoA assignment Date: Fri, 6 Apr 2007 16:36:44 -0500 Message-ID: <456943D540CFC14A8D7138E64843F85304499C50@daebe101.NOE.Nokia.com> In-Reply-To: <1175869619.28166.52.camel@lor-maknavic3.int-evry.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Dynamic HoA assignment Thread-Index: Acd4V/JwbqOi89RsT6u1aHcqAyOlxgAOwbKg References: <1175869619.28166.52.camel@lor-maknavic3.int-evry.fr> From: To: X-OriginalArrivalTime: 06 Apr 2007 21:40:07.0121 (UTC) FILETIME=[24CC4C10:01C77894] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070407004016-3C302BB0-1BC1A859/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Pars, I think we may be talking past each other in the context of dynamic HoA assignment. What I was proposing was to simply have a mechanism for=20 bootstrapping in which the HoA is assigned by the HA via the BAck. Your proposal of using different HoAs with different CNs is not what I had in mind. I think your idea may have more relevance in the monami6 WG. At the moment MIP6 (RFC3775) only=20 allows a single primary HoA binding for an MN at the HA.=20 -Raj >-----Original Message----- >From: ext Pars Mutaf [mailto:pars.mutaf@int-evry.fr]=20 >Sent: Friday, April 06, 2007 9:27 AM >To: Patil Basavaraj (NSN US/Irving) >Cc: Mobile IPv6 Mailing List >Subject: Re: [Mip6] Dynamic HoA assignment > >Hello,=20 > >I'm probably offside but I think this is a great=20 >idea. I would fully encourage any technique for=20 >dynamically generating HoAs (IKEv2 CONFIG_PAYLOAD or=20 >MIPv6 BU/BACK).=20 > >I think that sharing the Same HoA with all correspondents=20 >is really a bad idea. Assuming that a mobile host will=20 >be reachable via a public phone directory (or DNS, or >alike) is also unrealistic. This model was left by >cellular users longtime ago. Users share private=20 >reachability information (phone number currently) >in a manner that is under their control. > >I suspect that a mobile user will need=20 >(and will prefer having) as many as 100 or 200 home=20 >addresses (for example) that are configured/removed=20 >dynamically by the mobile host upon user request, and >distributed under user control.=20 >IPv6 space is not as precious as IPv4 space. > >A different HoA will be distributed to each known=20 >mobile host. Details are local policy issues. > >http://www.ietf.org/internet-drafts/draft-mutaf-dhoa-00.txt > >(note: the I-D needs a lot of work but=20 >the home addresses I'm talking about in this I-D >have nothing new, I'm rather proposing a novel MIPv6=20 >usage model) > >I seriously hope that this usage model is possible. > >Best regards, > > > > >On Thu, 2007-04-05 at 17:06 -0500, Basavaraj Patil wrote: >> Hello, >>=20 >> Currently the I-D draft-ietf-mip6-hiopt proposes the MN=20 >obtain the HoA as >> well in addition to the HA address and prefix via DHCP. >>=20 >> I think the MN should obtain the minimal information=20 >required to bootstrap. >> It is better to have the HA assign the MN an HoA. To do this we would >> require capability similar to MIP4 wherein the BU can be sent with an >> unspecified HoA. This is currently not possible as per RFC3775. >>=20 >> Should we consider allowing the MN sending a BU with the=20 >unspecified HoA and >> obtain an HoA (assigned by the HA) in the BAck? >>=20 >> I-D: draft-devarapalli-mip6-authprotocol-bootstrap proposes=20 >such capability. >> Also do we need to consider standardizing the bootstrapping=20 >mechanism for >> the auth protocol (RFC 4285)? >>=20 >> -Basavaraj >>=20 >>=20 >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 > > >_______________________________________________ >Mip6 mailing list >Mip6@ietf.org >https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 06 17:40:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZwAN-0007ov-8s; Fri, 06 Apr 2007 17:40:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZwAM-0007on-Aw for mip6@ietf.org; Fri, 06 Apr 2007 17:40:18 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZwAI-00060P-SI for mip6@ietf.org; Fri, 06 Apr 2007 17:40:18 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l36Ldxam015797; Sat, 7 Apr 2007 00:40:11 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 7 Apr 2007 00:40:09 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Apr 2007 16:40:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Dynamic HoA assignment Date: Fri, 6 Apr 2007 16:40:06 -0500 Message-ID: <456943D540CFC14A8D7138E64843F85304499C4F@daebe101.NOE.Nokia.com> In-Reply-To: <7CCD07160348804497EF29E9EA5560D7024D9DDF$0001@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Dynamic HoA assignment Thread-Index: Acd4KTL8NsN3pb1ZT361m3HioT2u+wAN0EHAAAw60dA= References: <7CCD07160348804497EF29E9EA5560D7024D9DDF$0001@exchtewks2.starentnetworks.com> From: To: , X-OriginalArrivalTime: 06 Apr 2007 21:40:06.0902 (UTC) FILETIME=[24AAE160:01C77894] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070407004012-3C302BB0-1F75FDE4/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Inline:=20 >-----Original Message----- >From: ext Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com]=20 >Sent: Friday, April 06, 2007 10:40 AM >To: Gerardo Giaretta; Patil Basavaraj (NSN US/Irving) >Cc: Mobile IPv6 Mailing List >Subject: RE: [Mip6] Dynamic HoA assignment > >HI Gerardo, Raj, > >> -----Original Message----- >> From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] >> Sent: Friday, April 06, 2007 3:53 AM >> To: Basavaraj Patil >> Cc: Mobile IPv6 Mailing List >> Subject: Re: [Mip6] Dynamic HoA assignment >>=20 >> Hi Raj, >>=20 >> > Hello, >> > >> > Currently the I-D draft-ietf-mip6-hiopt proposes the MN obtain the >HoA >> as >> > well in addition to the HA address and prefix via DHCP. >> > >> > I think the MN should obtain the minimal information required to >> bootstrap. >> > It is better to have the HA assign the MN an HoA. >>=20 >> I fully agree. The HA is the node in the better position to=20 >assign the >> HoA. This is the rationale behind the choices made by the >> bootstrapping DT two years ago. >>=20 >[KC>] We are talking about basic DHCP capability as defined in >draft-ietf-mip6-hiopt. We are NOT talking about the MIP6 bootstrapping >solutions that came out of the DT. The inclusion of HoA in >draft-ietf-mip6-bootstrapping-integrated-02.txt was debated over the ML >and in Prague meeting. At this time, we have decided to NOT include HoA >in draft-ietf-mip6-bootstrapping-integrated-02.txt. However,=20 >this should >not be linked with what can be done in DHCP. If someone wants to assign >HoA via DHCP regardless of which mip6 bootstrapping solution is used or >not used, it should be allowed, IMHO. BTW, it was added in the >draft-ietf-mip6-hiopt because SDOs like WiMAX forum needed such info in >DHCP. > Raj> Having multiple ways to assign the MN an HoA via the bootstrap process is not a good idea. At the moment the bootstrapping mechanisms suggest: 1. HoA assignment via IKEv2 2. HoA assignment via DHCP Now we are discussing the possibility of the HA assigning the MN an HoA in the BAck.=20 I think it would be best to recommend a single method. And from that perspective assigning the HoA in the BAck is more attractive since the HA is the one doing the address assignment. So if we were to recommend only a single way for HoA assignment, we=20 could consider not having the HoA option in the hiopt I-D.=20 > >> > To do this we would >> > require capability similar to MIP4 wherein the BU can be sent with >an >> > unspecified HoA. This is currently not possible as per RFC3775. >> > >>=20 >> I guess you are talking about rfc4285 (auth protocol). If IPsec is >> used, IKEv2 can be used to assign the HoA, as specified in >> draft-ietf-mip6-bootstrapping-split >>=20 >[KC>] Again, regardless of IKEv2, we should allow the dynamic HoA >assignment via mip6 BU/BA. People may like to do HoA (address) >management based on MIP6 _authorization_ and NOT IKEv2=20 >_authentication_. > Raj> Yes. I think that even in the case of bootstrapping with IKEv2, we should still have the HoA assigned by the HA. Is there a reason=20 why this would not work? Is there an issue with the IPsec SA establishment in case the HoA assignment has to be delayed until the MN sends the BU? Or can the SA be modified to reflect the HoA assigned by the HA? >> > Should we consider allowing the MN sending a BU with the=20 >unspecified >HoA >> and >> > obtain an HoA (assigned by the HA) in the BAck? >> > >>=20 >> Again this would be needed only for auth protocol. No need=20 >for this if >> IPsec is used. >>=20 >[KC>] Nope, we should allow it via BU/BA as well. Raj> I agree... Note the comment above.=20 > >> > I-D: draft-devarapalli-mip6-authprotocol-bootstrap proposes such >> capability. >> > Also do we need to consider standardizing the bootstrapping >mechanism >> for >> > the auth protocol (RFC 4285)? >> > >>=20 >> Some SDOs use rfc4285 authentication for MIPv6, but as far as I know, >> they have already defined their own bootstrapping solution.=20 >What would >> be the role of an IETF solution with regards to those? >>=20 >[KC>] role of IETF is to define an IETF way to provide dynamic HoA >allocation capability via mip6 BU/BA. We don't have that today. Also, >you are forgetting the per-Node SA model that is used in PMIP6. We need >this capability for PMIP6 also. > Raj> I think it makes sense for the MIP6 WG to define bootstrapping which covers all the cases. Having a solution for bootstrapping in the IETF would enable other SDOs to use it instead of defining their own specific methods. -Raj > > >> --Gerardo >>=20 >> > -Basavaraj >> > >> > >> > _______________________________________________ >> > Mip6 mailing list >> > Mip6@ietf.org >> > https://www1.ietf.org/mailman/listinfo/mip6 >> > >>=20 >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 > > >"This email message and any attachments are confidential=20 >information of Starent Networks, Corp. The information=20 >transmitted may not be used to create or change any=20 >contractual obligations of Starent Networks, Corp. Any=20 >review, retransmission, dissemination or other use of, or=20 >taking of any action in reliance upon this e-mail and its=20 >attachments by persons or entities other than the intended=20 >recipient is prohibited. If you are not the intended=20 >recipient, please notify the sender immediately -- by replying=20 >to this message or by sending an email to=20 >postmaster@starentnetworks.com -- and destroy all copies of=20 >this message and any attachments without reading or disclosing=20 >their contents. Thank you." > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Apr 08 02:47:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaR9n-00024o-7z; Sun, 08 Apr 2007 02:45:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaR9m-00022O-FA for mip6@ietf.org; Sun, 08 Apr 2007 02:45:46 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HaR9b-0008UJ-V1 for mip6@ietf.org; Sun, 08 Apr 2007 02:45:46 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id DD41F20F26; Sun, 8 Apr 2007 08:45:20 +0200 (CEST) X-AuditID: c1b4fb3e-ae9ecbb0000061ca-06-46188f8001b6 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C7CBD20076; Sun, 8 Apr 2007 08:45:20 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 8 Apr 2007 08:45:20 +0200 Received: from [153.88.254.38] ([153.88.254.38]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 8 Apr 2007 08:45:20 +0200 Message-ID: <46188F80.8090106@ericsson.com> Date: Sun, 08 Apr 2007 08:45:20 +0200 From: Conny Larsson User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Basavaraj Patil Subject: Re: [Mip6] Consensus call on DS-MIP6 issue 73 (IPv4 CoA in the BU) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Apr 2007 06:45:20.0243 (UTC) FILETIME=[79C05430:01C779A9] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Raj: My vote is 1, keep the IPv4 mapped address. I read Hesham's draft when it was submitted and I have then partly followed the discussion about how to include the IPv4 CoA of the MN in the binding update. I believe the original idea is fine. Regards Conny Basavaraj Patil wrote: > Hello, > > I would like to get consensus from the WG on another DS-MIP6 issue > which is pending resolution. > > The issue is about how to include the IPv4 CoA of the MN in the > binding update. > > The choices are: > > 1. Keep the IPv4 mapped address in the source address field when > sending the BU > > 2. Remove the IPv4 mapped address from the src address of the BU and > replace it with the Home address. The IPv4 care-of address will be > included in a new IPv4 alt-CoA option. > > Please express your opinion and preference (a brief justification of > why would be useful but not required) by Thursday, April 12th 07. > > The issue has been noted and is in the tracker at: > http://www.mip4.org/issues/tracker/mip6/issue73 > > -Basavaraj > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Apr 08 05:06:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaTLE-0001V3-MP; Sun, 08 Apr 2007 05:05:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaTLD-0001Ul-GC for mip6@ietf.org; Sun, 08 Apr 2007 05:05:43 -0400 Received: from av12-1-sn2.hy.skanova.net ([81.228.8.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HaTLB-00041P-Pa for mip6@ietf.org; Sun, 08 Apr 2007 05:05:43 -0400 Received: by av12-1-sn2.hy.skanova.net (Postfix, from userid 502) id C794838501; Sun, 8 Apr 2007 11:05:38 +0200 (CEST) Received: from smtp4-2-sn2.hy.skanova.net (smtp4-2-sn2.hy.skanova.net [81.228.8.93]) by av12-1-sn2.hy.skanova.net (Postfix) with ESMTP id 782F4384E4; Sun, 8 Apr 2007 11:05:38 +0200 (CEST) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp4-2-sn2.hy.skanova.net (Postfix) with ESMTP id 16ECB37E43; Sun, 8 Apr 2007 11:05:38 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.63) (envelope-from ) id 1HaTL6-0001pN-G9; Sun, 08 Apr 2007 11:05:36 +0200 Message-ID: <4618B05F.2010607@levkowetz.com> Date: Sun, 08 Apr 2007 11:05:35 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 Subject: Re: [Mip6] Consensus call on DS-MIP6 issue 73 (IPv4 CoA in the BU) References: <46188F80.8090106@ericsson.com> In-Reply-To: <46188F80.8090106@ericsson.com> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: basavaraj.patil@nsn.com, mip6@ietf.org, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi, I definitely prefer 2. Explicit is better than implicit; we should use an explicit IPv4 address option to carry the IPv4 CoA. (I believe the formulation of 2. confuses things a bit by labelling this an 'alt-CoA' option -- it's simply an IPv4 CoA option.) Henrik on 2007-04-08 08:45 Conny Larsson said the following: > Hi Raj: > > My vote is 1, keep the IPv4 mapped address. I read Hesham's draft > when it was submitted and I have then partly followed the discussion > about how to include the IPv4 CoA of the MN in the binding update. > I believe the original idea is fine. > > Regards > Conny > > > Basavaraj Patil wrote: >> Hello, >> >> I would like to get consensus from the WG on another DS-MIP6 issue >> which is pending resolution. >> >> The issue is about how to include the IPv4 CoA of the MN in the >> binding update. >> >> The choices are: >> >> 1. Keep the IPv4 mapped address in the source address field when >> sending the BU >> >> 2. Remove the IPv4 mapped address from the src address of the BU and >> replace it with the Home address. The IPv4 care-of address will be >> included in a new IPv4 alt-CoA option. >> >> Please express your opinion and preference (a brief justification of >> why would be useful but not required) by Thursday, April 12th 07. >> >> The issue has been noted and is in the tracker at: >> http://www.mip4.org/issues/tracker/mip6/issue73 >> >> -Basavaraj >> >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 >> > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Apr 08 07:36:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaVg4-0000Q7-7N; Sun, 08 Apr 2007 07:35:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaVg3-0000Q2-4l for mip6@ietf.org; Sun, 08 Apr 2007 07:35:23 -0400 Received: from omta02sl.mx.bigpond.com ([144.140.93.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HaVfy-0008ID-6v for mip6@ietf.org; Sun, 08 Apr 2007 07:35:23 -0400 Received: from oaamta02sl.mx.bigpond.com ([124.191.178.123]) by omta02sl.mx.bigpond.com with ESMTP id <20070408113458.KRKG10557.omta02sl.mx.bigpond.com@oaamta02sl.mx.bigpond.com>; Sun, 8 Apr 2007 11:34:58 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta02sl.mx.bigpond.com with ESMTP id <20070408113457.POGZ28205.oaamta02sl.mx.bigpond.com@PC20005>; Sun, 8 Apr 2007 11:34:57 +0000 From: "Hesham Soliman" To: "'Henrik Levkowetz'" Subject: RE: [Mip6] Consensus call on DS-MIP6 issue 73 (IPv4 CoA in the BU) Date: Sun, 8 Apr 2007 21:34:55 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 thread-index: Acd5vWtXwWteJxaZSjSZpbb4biFw2AAE4Nuw In-Reply-To: <4618B05F.2010607@levkowetz.com> Message-Id: <20070408113457.POGZ28205.oaamta02sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: 'Mobile IPv6 Mailing List' X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > (I believe the formulation of 2. confuses things a bit by labelling > this an 'alt-CoA' option -- it's simply an IPv4 CoA option.) => I hope this is only a terminology confusion and not a deeper misunderstanding. But since I heard this comment a couple of times I want to make sure that everyone understands that the sole purpose of this option (in alt 2 below) is to indicate to the receiver that it includes the CoA and therefore the src address MUST NOT be assumed to include the CoA. Because in alt 2 below the src address in the IPv6 packet is the HoA. This is identical to the purpose of the Alt-CoA option. The only difference between the two is that one carries an IPv4 address and the other carries an IPv6 address. I don't care what that option is called as long as the purpose is understood. Hesham > > > Henrik > > on 2007-04-08 08:45 Conny Larsson said the following: > > Hi Raj: > > > > My vote is 1, keep the IPv4 mapped address. I read Hesham's draft > > when it was submitted and I have then partly followed the > discussion > > about how to include the IPv4 CoA of the MN in the binding update. > > I believe the original idea is fine. > > > > Regards > > Conny > > > > > > Basavaraj Patil wrote: > >> Hello, > >> > >> I would like to get consensus from the WG on another DS-MIP6 issue > >> which is pending resolution. > >> > >> The issue is about how to include the IPv4 CoA of the MN in the > >> binding update. > >> > >> The choices are: > >> > >> 1. Keep the IPv4 mapped address in the source address field when > >> sending the BU > >> > >> 2. Remove the IPv4 mapped address from the src address of > the BU and > >> replace it with the Home address. The IPv4 care-of > address will be > >> included in a new IPv4 alt-CoA option. > >> > >> Please express your opinion and preference (a brief > justification of > >> why would be useful but not required) by Thursday, April 12th 07. > >> > >> The issue has been noted and is in the tracker at: > >> http://www.mip4.org/issues/tracker/mip6/issue73 > >> > >> -Basavaraj > >> > >> > >> _______________________________________________ > >> Mip6 mailing list > >> Mip6@ietf.org > >> https://www1.ietf.org/mailman/listinfo/mip6 > >> > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Apr 08 08:05:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaW8Q-0000Bj-MM; Sun, 08 Apr 2007 08:04:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaW8P-0000Ba-2T for mip6@ietf.org; Sun, 08 Apr 2007 08:04:41 -0400 Received: from av8-1-sn3.vrr.skanova.net ([81.228.9.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HaW8N-0006Iv-J0 for mip6@ietf.org; Sun, 08 Apr 2007 08:04:41 -0400 Received: by av8-1-sn3.vrr.skanova.net (Postfix, from userid 502) id D3F17384F9; Sun, 8 Apr 2007 14:04:36 +0200 (CEST) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av8-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 9739C384DE; Sun, 8 Apr 2007 14:04:36 +0200 (CEST) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 7452F37E44; Sun, 8 Apr 2007 14:04:35 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.63) (envelope-from ) id 1HaW8J-0003ND-B2; Sun, 08 Apr 2007 14:04:35 +0200 Message-ID: <4618DA53.2050503@levkowetz.com> Date: Sun, 08 Apr 2007 14:04:35 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Hesham Soliman Subject: Re: [Mip6] Consensus call on DS-MIP6 issue 73 (IPv4 CoA in the BU) References: <20070408113457.POGZ28205.oaamta02sl.mx.bigpond.com@PC20005> In-Reply-To: <20070408113457.POGZ28205.oaamta02sl.mx.bigpond.com@PC20005> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: Hesham@elevatemobile.com, mip6@ietf.org, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: 'Mobile IPv6 Mailing List' X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org on 2007-04-08 13:34 Hesham Soliman said the following: > >> (I believe the formulation of 2. confuses things a bit by labelling >> this an 'alt-CoA' option -- it's simply an IPv4 CoA option.) > > I hope this is only a terminology confusion and not a deeper > misunderstanding. But since I heard this comment a couple of times I want to > make sure that everyone understands that the sole purpose of this option (in > alt 2 below) is to indicate to the receiver that it includes the CoA and > therefore the src address MUST NOT be assumed to include the CoA. Because in > alt 2 below the src address in the IPv6 packet is the HoA. This is identical > to the purpose of the Alt-CoA option. The only difference between the two is > that one carries an IPv4 address and the other carries an IPv6 address. I > don't care what that option is called as long as the purpose is understood. Agreed for the logic. I'd prefer the option to be called something like 'IPv4-CoA'. Henrik > Hesham > >> >> >> Henrik >> >> on 2007-04-08 08:45 Conny Larsson said the following: >> > Hi Raj: >> > >> > My vote is 1, keep the IPv4 mapped address. I read Hesham's draft >> > when it was submitted and I have then partly followed the >> discussion >> > about how to include the IPv4 CoA of the MN in the binding update. >> > I believe the original idea is fine. >> > >> > Regards >> > Conny >> > >> > >> > Basavaraj Patil wrote: >> >> Hello, >> >> >> >> I would like to get consensus from the WG on another DS-MIP6 issue >> >> which is pending resolution. >> >> >> >> The issue is about how to include the IPv4 CoA of the MN in the >> >> binding update. >> >> >> >> The choices are: >> >> >> >> 1. Keep the IPv4 mapped address in the source address field when >> >> sending the BU >> >> >> >> 2. Remove the IPv4 mapped address from the src address of >> the BU and >> >> replace it with the Home address. The IPv4 care-of >> address will be >> >> included in a new IPv4 alt-CoA option. >> >> >> >> Please express your opinion and preference (a brief >> justification of >> >> why would be useful but not required) by Thursday, April 12th 07. >> >> >> >> The issue has been noted and is in the tracker at: >> >> http://www.mip4.org/issues/tracker/mip6/issue73 >> >> >> >> -Basavaraj >> >> >> >> >> >> _______________________________________________ >> >> Mip6 mailing list >> >> Mip6@ietf.org >> >> https://www1.ietf.org/mailman/listinfo/mip6 >> >> >> > >> > _______________________________________________ >> > Mip6 mailing list >> > Mip6@ietf.org >> > https://www1.ietf.org/mailman/listinfo/mip6 >> > >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 >> > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Apr 08 22:51:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HajxL-0002VY-SO; Sun, 08 Apr 2007 22:50:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HajxK-0002PV-Go for mip6@ietf.org; Sun, 08 Apr 2007 22:50:10 -0400 Received: from yskfw1.ysknet.co.jp ([210.169.255.3] helo=ksns.ks.ysknet.co.jp) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HajxF-0005Gw-SA for mip6@ietf.org; Sun, 08 Apr 2007 22:50:10 -0400 Received: (qmail 29315 invoked from network); 9 Apr 2007 11:49:43 +0900 Received: from (HELO MIP6-236) (@) by with SMTP; 9 Apr 2007 11:49:43 +0900 To: mip6@ietf.org, nemo@ietf.org Subject: Re: [Mip6] [TAHI Test Event] Registration for the TAHI event is started! From: "K.Kawaguchi" References: <200703201852.FGE13085.UBJXLBVH@ysknet.co.jp> In-Reply-To: <200703201852.FGE13085.UBJXLBVH@ysknet.co.jp> Message-Id: <200704091149.FAI21846.HBLVBJXU@ysknet.co.jp> X-Mailer: Winbiff [Version 2.43 PL1] X-Accept-Language: ja,en Date: Mon, 9 Apr 2007 11:49:40 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Dear all, # sorry if you received multiple times of this kind of email. Registration for the 9th TAHI IPv6 Interoperability Test event was started. If you are planning to participate to the event, you can register in http://www.tahi.org/inop/9thinterop.html Note : The early registration discount is until 17:00 JST Apr. 16, 2007. The registration deadline is 17:00 JST Apr. 27, 2007. And you can get detailed information about the event in the URL. Summary information of the event. - Venue: Nippon Convention Center (Makuhari Messe), Chiba, Japan. - Date: May 14 - May 18, 2007 - Registration & Information: http://www.tahi.org/inop/9thinterop.html We are waiting for your participation. We are looking forward to see you at 9th TAHI evnet! Best regards, ------------------- Kiyoaki Kawaguchi _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 09 12:09:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HawQm-0007Jj-N9; Mon, 09 Apr 2007 12:09:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HawQm-0007H5-7W for mip6@ietf.org; Mon, 09 Apr 2007 12:09:24 -0400 Received: from web84110.mail.mud.yahoo.com ([68.142.206.197]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HawQT-0004cq-1P for mip6@ietf.org; Mon, 09 Apr 2007 12:09:24 -0400 Received: (qmail 13229 invoked by uid 60001); 9 Apr 2007 16:09:04 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=JZZ5YG9zEU+OlhmBSd1njkW0vSErL4c2ShX6OshtCXgMqRrUNxj6AMYM92rtv255zvAJrdyNcf5/RiX7hPgPtO8G4NszOrzYV+5aAASjmTZHa763z+1S7Vv8gjXEJuRBNRmCDhZ2AK5cNIznzMG08QG0c80cxqooKZDpkVEc5TU=; X-YMail-OSG: vCNXcagVM1mSsXRc4SS.djslmc3v..6RGvQlnnybqFoeA9UfQUrO3ot29AgdRhGkk9Ppg_0RS_erqSGaoU6us3CTcg-- Received: from [206.16.17.212] by web84110.mail.mud.yahoo.com via HTTP; Mon, 09 Apr 2007 09:09:04 PDT X-Mailer: YahooMailRC/476 YahooMailWebService/0.7.41.8 Date: Mon, 9 Apr 2007 09:09:04 -0700 (PDT) From: Behcet Sarikaya Subject: Re: [Mip6] Dynamic HoA assignment To: basavaraj.patil@nsn.com MIME-Version: 1.0 Message-ID: <223653.12480.qm@web84110.mail.mud.yahoo.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Behcet Sarikaya List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0577637447==" Errors-To: mip6-bounces@ietf.org --===============0577637447== Content-Type: multipart/alternative; boundary="0-104603532-1176134944=:12480" --0-104603532-1176134944=:12480 Content-Type: text/plain; charset=ascii Hi Raj, I have a question and a comment: What is nsn ? My comment is the assignment of HoA using BU/BA seems to be against the spirit of RFC 3775. RFC 3775 requires BU to contain HoA destination option. RFC 3775, unlike RFC 3344 does not define a home address parameter in BU. Also I am against to keep bringing Mipv4 aspects into Mipv6, ones wonders what is next? Use UDP signaling? Regards, --behcet ----- Original Message ---- From: "basavaraj.patil@nsn.com" To: kchowdhury@starentnetworks.com; gerardo.giaretta@gmail.com Cc: mip6@ietf.org Sent: Friday, April 6, 2007 4:40:06 PM Subject: RE: [Mip6] Dynamic HoA assignment Inline: >-----Original Message----- >From: ext Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] >Sent: Friday, April 06, 2007 10:40 AM >To: Gerardo Giaretta; Patil Basavaraj (NSN US/Irving) >Cc: Mobile IPv6 Mailing List >Subject: RE: [Mip6] Dynamic HoA assignment > >HI Gerardo, Raj, > >> -----Original Message----- >> From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] >> Sent: Friday, April 06, 2007 3:53 AM >> To: Basavaraj Patil >> Cc: Mobile IPv6 Mailing List >> Subject: Re: [Mip6] Dynamic HoA assignment >> >> Hi Raj, >> >> > Hello, >> > >> > Currently the I-D draft-ietf-mip6-hiopt proposes the MN obtain the >HoA >> as >> > well in addition to the HA address and prefix via DHCP. >> > >> > I think the MN should obtain the minimal information required to >> bootstrap. >> > It is better to have the HA assign the MN an HoA. >> >> I fully agree. The HA is the node in the better position to >assign the >> HoA. This is the rationale behind the choices made by the >> bootstrapping DT two years ago. >> >[KC>] We are talking about basic DHCP capability as defined in >draft-ietf-mip6-hiopt. We are NOT talking about the MIP6 bootstrapping >solutions that came out of the DT. The inclusion of HoA in >draft-ietf-mip6-bootstrapping-integrated-02.txt was debated over the ML >and in Prague meeting. At this time, we have decided to NOT include HoA >in draft-ietf-mip6-bootstrapping-integrated-02.txt. However, >this should >not be linked with what can be done in DHCP. If someone wants to assign >HoA via DHCP regardless of which mip6 bootstrapping solution is used or >not used, it should be allowed, IMHO. BTW, it was added in the >draft-ietf-mip6-hiopt because SDOs like WiMAX forum needed such info in >DHCP. > Raj> Having multiple ways to assign the MN an HoA via the bootstrap process is not a good idea. At the moment the bootstrapping mechanisms suggest: 1. HoA assignment via IKEv2 2. HoA assignment via DHCP Now we are discussing the possibility of the HA assigning the MN an HoA in the BAck. I think it would be best to recommend a single method. And from that perspective assigning the HoA in the BAck is more attractive since the HA is the one doing the address assignment. So if we were to recommend only a single way for HoA assignment, we could consider not having the HoA option in the hiopt I-D. > >> > To do this we would >> > require capability similar to MIP4 wherein the BU can be sent with >an >> > unspecified HoA. This is currently not possible as per RFC3775. >> > >> >> I guess you are talking about rfc4285 (auth protocol). If IPsec is >> used, IKEv2 can be used to assign the HoA, as specified in >> draft-ietf-mip6-bootstrapping-split >> >[KC>] Again, regardless of IKEv2, we should allow the dynamic HoA >assignment via mip6 BU/BA. People may like to do HoA (address) >management based on MIP6 _authorization_ and NOT IKEv2 >_authentication_. > Raj> Yes. I think that even in the case of bootstrapping with IKEv2, we should still have the HoA assigned by the HA. Is there a reason why this would not work? Is there an issue with the IPsec SA establishment in case the HoA assignment has to be delayed until the MN sends the BU? Or can the SA be modified to reflect the HoA assigned by the HA? >> > Should we consider allowing the MN sending a BU with the >unspecified >HoA >> and >> > obtain an HoA (assigned by the HA) in the BAck? >> > >> >> Again this would be needed only for auth protocol. No need >for this if >> IPsec is used. >> >[KC>] Nope, we should allow it via BU/BA as well. Raj> I agree... Note the comment above. > >> > I-D: draft-devarapalli-mip6-authprotocol-bootstrap proposes such >> capability. >> > Also do we need to consider standardizing the bootstrapping >mechanism >> for >> > the auth protocol (RFC 4285)? >> > >> >> Some SDOs use rfc4285 authentication for MIPv6, but as far as I know, >> they have already defined their own bootstrapping solution. >What would >> be the role of an IETF solution with regards to those? >> >[KC>] role of IETF is to define an IETF way to provide dynamic HoA >allocation capability via mip6 BU/BA. We don't have that today. Also, >you are forgetting the per-Node SA model that is used in PMIP6. We need >this capability for PMIP6 also. > Raj> I think it makes sense for the MIP6 WG to define bootstrapping which covers all the cases. Having a solution for bootstrapping in the IETF would enable other SDOs to use it instead of defining their own specific methods. -Raj > > >> --Gerardo >> >> > -Basavaraj >> > >> > >> > _______________________________________________ >> > Mip6 mailing list >> > Mip6@ietf.org >> > https://www1.ietf.org/mailman/listinfo/mip6 >> > >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 > > >"This email message and any attachments are confidential >information of Starent Networks, Corp. The information >transmitted may not be used to create or change any >contractual obligations of Starent Networks, Corp. Any >review, retransmission, dissemination or other use of, or >taking of any action in reliance upon this e-mail and its >attachments by persons or entities other than the intended >recipient is prohibited. If you are not the intended >recipient, please notify the sender immediately -- by replying >to this message or by sending an email to >postmaster@starentnetworks.com -- and destroy all copies of >this message and any attachments without reading or disclosing >their contents. Thank you." > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --0-104603532-1176134944=:12480 Content-Type: text/html; charset=ascii
Hi Raj,
  I have a question and a comment:
 
What is nsn  ?
 
My comment is the assignment of HoA using BU/BA seems to be against the spirit of RFC 3775. RFC 3775 requires BU to contain HoA destination option. RFC 3775, unlike RFC 3344 does not define a home address parameter in BU.
Also I am against to keep bringing Mipv4 aspects into Mipv6, ones wonders what is next? Use UDP signaling?
 
Regards,
 
--behcet

----- Original Message ----
From: "basavaraj.patil@nsn.com" <basavaraj.patil@nsn.com>
To: kchowdhury@starentnetworks.com; gerardo.giaretta@gmail.com
Cc: mip6@ietf.org
Sent: Friday, April 6, 2007 4:40:06 PM
Subject: RE: [Mip6] Dynamic HoA assignment

Inline:

>-----Original Message-----
>From: ext Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com]
>Sent: Friday, April 06, 2007 10:40 AM
>To: Gerardo Giaretta; Patil Basavaraj (NSN US/Irving)
>Cc: Mobile IPv6 Mailing List
>Subject: RE: [Mip6] Dynamic HoA assignment
>
>HI Gerardo, Raj,
>
>> -----Original Message-----
>> From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com]
>> Sent: Friday, April 06, 2007 3:53 AM
>> To: Basavaraj Patil
>> Cc: Mobile IPv6 Mailing List
>> Subject: Re: [Mip6] Dynamic HoA assignment
>>
>> Hi Raj,
>>
>> > Hello,
>> >
>> > Currently the I-D draft-ietf-mip6-hiopt proposes the MN obtain the
>HoA
>> as
>> > well in addition to the HA address and prefix via DHCP.
>> >
>> > I think the MN should obtain the minimal information required to
>> bootstrap.
>> > It is better to have the HA assign the MN an HoA.
>>
>> I fully agree. The HA is the node in the better position to
>assign the
>> HoA. This is the rationale behind the choices made by the
>> bootstrapping DT two years ago.
>>
>[KC>] We are talking about basic DHCP capability as defined in
>draft-ietf-mip6-hiopt. We are NOT talking about the MIP6 bootstrapping
>solutions that came out of the DT. The inclusion of HoA in
>draft-ietf-mip6-bootstrapping-integrated-02.txt was debated over the ML
>and in Prague meeting. At this time, we have decided to NOT include HoA
>in draft-ietf-mip6-bootstrapping-integrated-02.txt. However,
>this should
>not be linked with what can be done in DHCP. If someone wants to assign
>HoA via DHCP regardless of which mip6 bootstrapping solution is used or
>not used, it should be allowed, IMHO. BTW, it was added in the
>draft-ietf-mip6-hiopt because SDOs like WiMAX forum needed such info in
>DHCP.
>

Raj> Having multiple ways to assign the MN an HoA via the bootstrap
process
is not a good idea. At the moment the bootstrapping mechanisms suggest:
1. HoA assignment via IKEv2
2. HoA assignment via DHCP

Now we are discussing the possibility of the HA assigning the MN an HoA
in the BAck.

I think it would be best to recommend a single method. And from that
perspective assigning the HoA in the BAck is more attractive since the
HA is the one doing the address assignment.

So if we were to recommend only a single way for HoA assignment, we
could consider not having the HoA option in the hiopt I-D.

>
>> > To do this we would
>> > require capability similar to MIP4 wherein the BU can be sent with
>an
>> > unspecified HoA. This is currently not possible as per RFC3775.
>> >
>>
>> I guess you are talking about rfc4285 (auth protocol). If IPsec is
>> used, IKEv2 can be used to assign the HoA, as specified in
>> draft-ietf-mip6-bootstrapping-split
>>
>[KC>] Again, regardless of IKEv2, we should allow the dynamic HoA
>assignment via mip6 BU/BA. People may like to do HoA (address)
>management based on MIP6 _authorization_ and NOT IKEv2
>_authentication_.
>

Raj> Yes. I think that even in the case of bootstrapping with IKEv2,
we should still have the HoA assigned by the HA. Is there a reason
why this would not work? Is there an issue with the IPsec SA
establishment
in case the HoA assignment has to be delayed until the MN sends the BU?
Or can the SA be modified to reflect the HoA assigned by the HA?

>> > Should we consider allowing the MN sending a BU with the
>unspecified
>HoA
>> and
>> > obtain an HoA (assigned by the HA) in the BAck?
>> >
>>
>> Again this would be needed only for auth protocol. No need
>for this if
>> IPsec is used.
>>
>[KC>] Nope, we should allow it via BU/BA as well.

Raj> I agree... Note the comment above.

>
>> > I-D: draft-devarapalli-mip6-authprotocol-bootstrap proposes such
>> capability.
>> > Also do we need to consider standardizing the bootstrapping
>mechanism
>> for
>> > the auth protocol (RFC 4285)?
>> >
>>
>> Some SDOs use rfc4285 authentication for MIPv6, but as far as I know,
>> they have already defined their own bootstrapping solution.
>What would
>> be the role of an IETF solution with regards to those?
>>
>[KC>] role of IETF is to define an IETF way to provide dynamic HoA
>allocation capability via mip6 BU/BA. We don't have that today. Also,
>you are forgetting the per-Node SA model that is used in PMIP6. We need
>this capability for PMIP6 also.
>

Raj> I think it makes sense for the MIP6 WG to define bootstrapping
which
covers all the cases. Having a solution for bootstrapping in the IETF
would
enable other SDOs to use it instead of defining their own specific
methods.

-Raj

>
>
>> --Gerardo
>>
>> > -Basavaraj
>> >
>> >
>> > _______________________________________________
>> > Mip6 mailing list
>> > Mip6@ietf.org
>> > https://www1.ietf.org/mailman/listinfo/mip6
>> >
>>
>> _______________________________________________
>> Mip6 mailing list
>> Mip6@ietf.org
>> https://www1.ietf.org/mailman/listinfo/mip6
>
>
>"This email message and any attachments are confidential
>information of Starent Networks, Corp. The information
>transmitted may not be used to create or change any
>contractual obligations of Starent Networks, Corp.  Any
>review, retransmission, dissemination or other use of, or
>taking of any action in reliance upon this e-mail and its
>attachments by persons or entities other than the intended
>recipient is prohibited. If you are not the intended
>recipient, please notify the sender immediately -- by replying
>to this message or by sending an email to
>postmaster@starentnetworks.com -- and destroy all copies of
>this message and any attachments without reading or disclosing
>their contents. Thank you."
>

_______________________________________________
Mip6 mailing list
Mip6@ietf.org
https://www1.ietf.org/mailman/listinfo/mip6

--0-104603532-1176134944=:12480-- --===============0577637447== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0577637447==-- From mip6-bounces@ietf.org Mon Apr 09 22:06:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb5jW-0001JW-5j; Mon, 09 Apr 2007 22:05:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb5jV-0001HG-2T for mip6@ietf.org; Mon, 09 Apr 2007 22:05:21 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hb5es-00058L-CL for mip6@ietf.org; Mon, 09 Apr 2007 22:00:38 -0400 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l3A20Xm1012079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 9 Apr 2007 19:00:33 -0700 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l3A20WX1029793; Mon, 9 Apr 2007 19:00:33 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Apr 2007 19:00:33 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Dynamic HoA assignment Date: Mon, 9 Apr 2007 19:00:29 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Dynamic HoA assignment Thread-Index: Acd3zrGa7+A1ruPBEduKwAARJNUNiADRQdLg References: From: "Narayanan, Vidya" To: "Basavaraj Patil" , "Mobile IPv6 Mailing List" X-OriginalArrivalTime: 10 Apr 2007 02:00:33.0018 (UTC) FILETIME=[05CC35A0:01C77B14] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Raj, I agree that there is no need to define assignment of HoA via DHCP. Assignment of HoA via IKEv2 seems sufficient for normal bootstrapping. I'm not quite sure if we need assignment of HoA through BU/BA - but, that basically depends on whether we are defining Auth protocol based bootstrapping or not. In either case, assignment via DHCP seems unnecessary.=20 Vidya > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com]=20 > Sent: Thursday, April 05, 2007 3:07 PM > To: Mobile IPv6 Mailing List > Subject: [Mip6] Dynamic HoA assignment=20 >=20 >=20 > Hello, >=20 > Currently the I-D draft-ietf-mip6-hiopt proposes the MN=20 > obtain the HoA as well in addition to the HA address and=20 > prefix via DHCP. >=20 > I think the MN should obtain the minimal information required=20 > to bootstrap. > It is better to have the HA assign the MN an HoA. To do this=20 > we would require capability similar to MIP4 wherein the BU=20 > can be sent with an unspecified HoA. This is currently not=20 > possible as per RFC3775. >=20 > Should we consider allowing the MN sending a BU with the=20 > unspecified HoA and obtain an HoA (assigned by the HA) in the BAck? >=20 > I-D: draft-devarapalli-mip6-authprotocol-bootstrap proposes=20 > such capability. > Also do we need to consider standardizing the bootstrapping=20 > mechanism for the auth protocol (RFC 4285)? >=20 > -Basavaraj >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 10 05:06:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbCIQ-0005go-4r; Tue, 10 Apr 2007 05:05:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbCIO-0005gJ-KB for mip6@ietf.org; Tue, 10 Apr 2007 05:05:48 -0400 Received: from ug-out-1314.google.com ([66.249.92.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbCIN-0007fj-8h for mip6@ietf.org; Tue, 10 Apr 2007 05:05:48 -0400 Received: by ug-out-1314.google.com with SMTP id 72so29485ugd for ; Tue, 10 Apr 2007 02:05:46 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=gUTeTHuKR5fufdHG++LBQPTbF9ktiZMuMtY1Mw7reDSKerPGECZeCTGQKplPZegQ5H2DQRe6vbMjv3YlIzssQgqkfqbEi8Zi8Wg/nKS5DvjDKtW4helg9trFdeqPKxLyYeJXpPshlD0cCeUM+I1iRck6mhWBlcRGc5vG8VWto/w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=aaVqMY8SQ341g/k2aghVJGBi4C0MIPR7w+CglIrxQ6yqFOG1m7eW5TTGYeMR18p9g8cC0BoOyPvgjFOEosK7+GEIbysRSyQt/HworYizrGDoTgCAokpUOYjaNojL/74qY45nec7rPg5SsKvhNWp3TN2jp7KS64iIHMe1c24WBDU= Received: by 10.67.101.10 with SMTP id d10mr160158ugm.1176195946169; Tue, 10 Apr 2007 02:05:46 -0700 (PDT) Received: by 10.66.243.11 with HTTP; Tue, 10 Apr 2007 02:05:45 -0700 (PDT) Message-ID: Date: Tue, 10 Apr 2007 11:05:45 +0200 From: "Gerardo Giaretta" To: "Chowdhury, Kuntal" Subject: Re: [Mip6] Dynamic HoA assignment In-Reply-To: <7CCD07160348804497EF29E9EA5560D7024D9DDF$0001@exchtewks2.starentnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7CCD07160348804497EF29E9EA5560D7024D9DDF$0001@exchtewks2.starentnetworks.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Kuntal, some comments inline... On 4/6/07, Chowdhury, Kuntal wrote: > > > > To do this we would > > > require capability similar to MIP4 wherein the BU can be sent with > an > > > unspecified HoA. This is currently not possible as per RFC3775. > > > > > > > I guess you are talking about rfc4285 (auth protocol). If IPsec is > > used, IKEv2 can be used to assign the HoA, as specified in > > draft-ietf-mip6-bootstrapping-split > > > [KC>] Again, regardless of IKEv2, we should allow the dynamic HoA > assignment via mip6 BU/BA. People may like to do HoA (address) > management based on MIP6 _authorization_ and NOT IKEv2 _authentication_. > Can you please clarify? In the Diameter Application we are designing in DIME WG, we are dealing with both authentication and authorization based on the IKEv2 exchange between the MN and the HA. The HoA assignment is done via IKEv2 through the configuration payload: I don't understand why an authorization step is not possible if this HoA assignment method is used. So I don't think that HoA assignment in BA enables authorization and IKEv2 does not. > > > > I-D: draft-devarapalli-mip6-authprotocol-bootstrap proposes such > > capability. > > > Also do we need to consider standardizing the bootstrapping > mechanism > > for > > > the auth protocol (RFC 4285)? > > > > > > > Some SDOs use rfc4285 authentication for MIPv6, but as far as I know, > > they have already defined their own bootstrapping solution. What would > > be the role of an IETF solution with regards to those? > > > [KC>] role of IETF is to define an IETF way to provide dynamic HoA > allocation capability via mip6 BU/BA. We don't have that today. Also, > you are forgetting the per-Node SA model that is used in PMIP6. We need > this capability for PMIP6 also. > I'm still trying to understand why this is needed. Again, if rfc4285 is used, I'm fine. But if IKEv2/IPsec is used, I don't see any reason why such a new mechanism should be defined. --Gerardo > > > > --Gerardo > > > > > -Basavaraj > > > > > > > > > _______________________________________________ > > > Mip6 mailing list > > > Mip6@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > "This email message and any attachments are confidential information of Starent Networks, Corp. The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to postmaster@starentnetworks.com -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you." > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 10 05:20:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbCWY-0003oI-LR; Tue, 10 Apr 2007 05:20:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbCWX-0003o8-3z for mip6@ietf.org; Tue, 10 Apr 2007 05:20:25 -0400 Received: from ug-out-1314.google.com ([66.249.92.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbCWT-0001JQ-Io for mip6@ietf.org; Tue, 10 Apr 2007 05:20:25 -0400 Received: by ug-out-1314.google.com with SMTP id 72so31234ugd for ; Tue, 10 Apr 2007 02:20:21 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=AWfTzH3tXdpO7EvzASmbXLOe+wVgFheMJVxb5mY9KXdLttYqoqIQ8Cbn/00AiIp1/KsVq94PSwoFzIvHJAXeUSICgMCFKFdi25X1+QI0pEvixeHoIhMVpsWlbXsu8UXz421r/XiUFkkj51OZNczG7vaM9pEwTmP91KE9hzg+AOw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=YFfewFU5STOyxs6+jYXDXBW1k10akPv2UmVt35+DsDbqx48HL3Fo0a6SP8stL6bFp5vOH72Re56EI6rVyBJmTol5zkxhPOxKC13dvUJmvyI8gPjlbESY4nHkzFFamIuauviXfTeicb6S6pcPwJ0H3Ykib74r0aF3cRbMRTYOY1I= Received: by 10.67.23.5 with SMTP id a5mr150914ugj.1176196820899; Tue, 10 Apr 2007 02:20:20 -0700 (PDT) Received: by 10.66.243.11 with HTTP; Tue, 10 Apr 2007 02:20:20 -0700 (PDT) Message-ID: Date: Tue, 10 Apr 2007 11:20:20 +0200 From: "Gerardo Giaretta" To: "basavaraj.patil@nsn.com" Subject: Re: [Mip6] Dynamic HoA assignment In-Reply-To: <456943D540CFC14A8D7138E64843F85304499C4F@daebe101.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7CCD07160348804497EF29E9EA5560D7024D9DDF$0001@exchtewks2.starentnetworks.com> <456943D540CFC14A8D7138E64843F85304499C4F@daebe101.NOE.Nokia.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Raj, inline please... On 4/6/07, basavaraj.patil@nsn.com wrote: > >> > > >> > Currently the I-D draft-ietf-mip6-hiopt proposes the MN obtain the > >HoA > >> as > >> > well in addition to the HA address and prefix via DHCP. > >> > > >> > I think the MN should obtain the minimal information required to > >> bootstrap. > >> > It is better to have the HA assign the MN an HoA. > >> > >> I fully agree. The HA is the node in the better position to > >assign the > >> HoA. This is the rationale behind the choices made by the > >> bootstrapping DT two years ago. > >> > >[KC>] We are talking about basic DHCP capability as defined in > >draft-ietf-mip6-hiopt. We are NOT talking about the MIP6 bootstrapping > >solutions that came out of the DT. The inclusion of HoA in > >draft-ietf-mip6-bootstrapping-integrated-02.txt was debated over the ML > >and in Prague meeting. At this time, we have decided to NOT include HoA > >in draft-ietf-mip6-bootstrapping-integrated-02.txt. However, > >this should > >not be linked with what can be done in DHCP. If someone wants to assign > >HoA via DHCP regardless of which mip6 bootstrapping solution is used or > >not used, it should be allowed, IMHO. BTW, it was added in the > >draft-ietf-mip6-hiopt because SDOs like WiMAX forum needed such info in > >DHCP. > > > > Raj> Having multiple ways to assign the MN an HoA via the bootstrap > process > is not a good idea. At the moment the bootstrapping mechanisms suggest: > 1. HoA assignment via IKEv2 > 2. HoA assignment via DHCP > > Now we are discussing the possibility of the HA assigning the MN an HoA > in the BAck. > > I think it would be best to recommend a single method. Are you suggesting to define a single method between DHCP and BAck or are you suggesting to deprecate HoA assignment via IKEv2? > And from that > perspective assigning the HoA in the BAck is more attractive since the > HA is the one doing the address assignment. > I agree, as mentioned earlier. This is why I prefer HoA assignment via BA rather via DHCP if auth protocol is used. If IKEv2/IPsec is used, the HoA assignment is done by the IKEv2 responder, which is the HA. > So if we were to recommend only a single way for HoA assignment, we > could consider not having the HoA option in the hiopt I-D. > > > > >> > To do this we would > >> > require capability similar to MIP4 wherein the BU can be sent with > >an > >> > unspecified HoA. This is currently not possible as per RFC3775. > >> > > >> > >> I guess you are talking about rfc4285 (auth protocol). If IPsec is > >> used, IKEv2 can be used to assign the HoA, as specified in > >> draft-ietf-mip6-bootstrapping-split > >> > >[KC>] Again, regardless of IKEv2, we should allow the dynamic HoA > >assignment via mip6 BU/BA. People may like to do HoA (address) > >management based on MIP6 _authorization_ and NOT IKEv2 > >_authentication_. > > > > Raj> Yes. I think that even in the case of bootstrapping with IKEv2, > we should still have the HoA assigned by the HA. Is there a reason > why this would not work? I see the other way around: is there a reason to introduce a new mechanism, since we have already two WG documents (one in RFC Ed queue and one in AD review status) that suggest doing it through IKEv2? Note that when HoA assignment is done via IKEv2, it is still the HA assigning the HoA. > Is there an issue with the IPsec SA > establishment > in case the HoA assignment has to be delayed until the MN sends the BU? > Or can the SA be modified to reflect the HoA assigned by the HA? > I would leave the floor to Vijay or Francis here. I have some comments/doubts though. Usually the MN specifies the HoA in the TSi payload when setting up the SA for BU/BA. This is replaced with the correct HoA by the HA in the IKEv2 response if dynamic HoA assignment is done via IKEv2. In this case at the end of the IKEv2 exchange, the MN and the HA can update the SPD entries with the corrects TSi (i.e. Home Address). How this can be done if the HoA assignment is done via BA? Which is the TSi in the meanwhile? Just HoA=all zeros? If so, when the HoA is assigned, should the MN update the TSi creating a child SA? It seems to me this is adding unnecessary complexity to the bootstrapping procedure. --Gerardo > >> > Should we consider allowing the MN sending a BU with the > >unspecified > >HoA > >> and > >> > obtain an HoA (assigned by the HA) in the BAck? > >> > > >> > >> Again this would be needed only for auth protocol. No need > >for this if > >> IPsec is used. > >> > >[KC>] Nope, we should allow it via BU/BA as well. > > Raj> I agree... Note the comment above. > > > > >> > I-D: draft-devarapalli-mip6-authprotocol-bootstrap proposes such > >> capability. > >> > Also do we need to consider standardizing the bootstrapping > >mechanism > >> for > >> > the auth protocol (RFC 4285)? > >> > > >> > >> Some SDOs use rfc4285 authentication for MIPv6, but as far as I know, > >> they have already defined their own bootstrapping solution. > >What would > >> be the role of an IETF solution with regards to those? > >> > >[KC>] role of IETF is to define an IETF way to provide dynamic HoA > >allocation capability via mip6 BU/BA. We don't have that today. Also, > >you are forgetting the per-Node SA model that is used in PMIP6. We need > >this capability for PMIP6 also. > > > > Raj> I think it makes sense for the MIP6 WG to define bootstrapping > which > covers all the cases. Having a solution for bootstrapping in the IETF > would > enable other SDOs to use it instead of defining their own specific > methods. > > -Raj > > > > > > >> --Gerardo > >> > >> > -Basavaraj > >> > > >> > > >> > _______________________________________________ > >> > Mip6 mailing list > >> > Mip6@ietf.org > >> > https://www1.ietf.org/mailman/listinfo/mip6 > >> > > >> > >> _______________________________________________ > >> Mip6 mailing list > >> Mip6@ietf.org > >> https://www1.ietf.org/mailman/listinfo/mip6 > > > > > >"This email message and any attachments are confidential > >information of Starent Networks, Corp. The information > >transmitted may not be used to create or change any > >contractual obligations of Starent Networks, Corp. Any > >review, retransmission, dissemination or other use of, or > >taking of any action in reliance upon this e-mail and its > >attachments by persons or entities other than the intended > >recipient is prohibited. If you are not the intended > >recipient, please notify the sender immediately -- by replying > >to this message or by sending an email to > >postmaster@starentnetworks.com -- and destroy all copies of > >this message and any attachments without reading or disclosing > >their contents. Thank you." > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 10 10:40:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbHVq-0007U3-4T; Tue, 10 Apr 2007 10:40:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbHVo-0007Tb-Hh for mip6@ietf.org; Tue, 10 Apr 2007 10:40:00 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbHVn-000570-1n for mip6@ietf.org; Tue, 10 Apr 2007 10:40:00 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id AA61590039 for ; Tue, 10 Apr 2007 10:39:53 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12122-15 for ; Tue, 10 Apr 2007 10:39:47 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Tue, 10 Apr 2007 10:39:47 -0400 (EDT) Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Apr 2007 10:39:47 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Dynamic HoA assignment Date: Tue, 10 Apr 2007 10:39:46 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D7024D9E0E@exchtewks2.starentnetworks.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Dynamic HoA assignment Thread-Index: Acd7T3B1mFDl2WnfT/a8YoobWTEf5gALDb2Q From: "Chowdhury, Kuntal" To: "Gerardo Giaretta" X-OriginalArrivalTime: 10 Apr 2007 14:39:47.0402 (UTC) FILETIME=[165392A0:01C77B7E] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Gerardo,=20 Please see inline... > -----Original Message----- > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > Sent: Tuesday, April 10, 2007 4:06 AM > To: Chowdhury, Kuntal > Cc: Basavaraj Patil; Mobile IPv6 Mailing List > Subject: Re: [Mip6] Dynamic HoA assignment >=20 > Hi Kuntal, >=20 > some comments inline... >=20 > On 4/6/07, Chowdhury, Kuntal wrote: > > > > > > To do this we would > > > > require capability similar to MIP4 wherein the BU can be sent with > > an > > > > unspecified HoA. This is currently not possible as per RFC3775. > > > > > > > > > > I guess you are talking about rfc4285 (auth protocol). If IPsec is > > > used, IKEv2 can be used to assign the HoA, as specified in > > > draft-ietf-mip6-bootstrapping-split > > > > > [KC>] Again, regardless of IKEv2, we should allow the dynamic HoA > > assignment via mip6 BU/BA. People may like to do HoA (address) > > management based on MIP6 _authorization_ and NOT IKEv2 _authentication_. > > >=20 > Can you please clarify? >=20 > In the Diameter Application we are designing in DIME WG, we are > dealing with both authentication and authorization based on the IKEv2 > exchange between the MN and the HA. The HoA assignment is done via > IKEv2 through the configuration payload: I don't understand why an > authorization step is not possible if this HoA assignment method is > used. > So I don't think that HoA assignment in BA enables authorization and > IKEv2 does not. >=20 [KC>] Yes, I am aware of that. However, as I mentioned on the DIME mailing list, authorizing the MN for MIP6 service (HoA assignment) when the MN is just negotiating IKE/IPsec SA is sort of a blind authorization. There is no standard way defined in IKE_AUTH/EAP transactions to indicate that the MN is actually trying to access MIP6 service. One can assume that simply because the MN is setting up an IPsec SA with the HA, it intends to do MIP6. As I have mentioned during the DIME discussion, this assumption won't be true in all cases. So, there will be various ways to figure out MN's intent and authorize the MN accordingly. While this is what you are alluding to, I think we need to allow the BU/BA based HoA assignment so that the HoA assignment is tied to MIP6 access rather than IKE/IPsec access. > > > > > > I-D: draft-devarapalli-mip6-authprotocol-bootstrap proposes such > > > capability. > > > > Also do we need to consider standardizing the bootstrapping > > mechanism > > > for > > > > the auth protocol (RFC 4285)? > > > > > > > > > > Some SDOs use rfc4285 authentication for MIPv6, but as far as I know, > > > they have already defined their own bootstrapping solution. What would > > > be the role of an IETF solution with regards to those? > > > > > [KC>] role of IETF is to define an IETF way to provide dynamic HoA > > allocation capability via mip6 BU/BA. We don't have that today. Also, > > you are forgetting the per-Node SA model that is used in PMIP6. We need > > this capability for PMIP6 also. > > >=20 > I'm still trying to understand why this is needed. Again, if rfc4285 > is used, I'm fine. But if IKEv2/IPsec is used, I don't see any reason > why such a new mechanism should be defined. >=20 [KC>] Such a mechanism should be defined unless there is something technically wrong with setting HoA=3D0::0 in the BU. =20 > --Gerardo >=20 > > > > > > > --Gerardo > > > > > > > -Basavaraj > > > > > > > > > > > > _______________________________________________ > > > > Mip6 mailing list > > > > Mip6@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > > > > _______________________________________________ > > > Mip6 mailing list > > > Mip6@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > "This email message and any attachments are confidential information of > Starent Networks, Corp. The information transmitted may not be used to > create or change any contractual obligations of Starent Networks, Corp. > Any review, retransmission, dissemination or other use of, or taking of > any action in reliance upon this e-mail and its attachments by persons or > entities other than the intended recipient is prohibited. If you are not > the intended recipient, please notify the sender immediately -- by > replying to this message or by sending an email to > postmaster@starentnetworks.com -- and destroy all copies of this message > and any attachments without reading or disclosing their contents. Thank > you." > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 10 12:10:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbIum-0005dg-83; Tue, 10 Apr 2007 12:09:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbIuk-0005Y4-6W for mip6@ietf.org; Tue, 10 Apr 2007 12:09:50 -0400 Received: from nz-out-0506.google.com ([64.233.162.239]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbIui-0003Qa-Px for mip6@ietf.org; Tue, 10 Apr 2007 12:09:50 -0400 Received: by nz-out-0506.google.com with SMTP id z6so1528020nzd for ; Tue, 10 Apr 2007 09:09:48 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=UBUTcurlRIQRSYdY68PaM806whPnuZdv4tUFpWlLm6qwvSjnlSevAtrg851jsOXIV27h9VZAiQesjSE3h59UEllvByv0iRBOUNi5SuIOKvPW4nuPws8xVxl5yNAYanMAJRTXeAcHSh5VGk6UVHAAxCAd25fwXDu3bCwnyVkFi8A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=gowGhoER1sl+e4AFNotnWPH2th8kae9VuLMkYzuEYtLtS+AWEwvFLzEwvdGmFk9S0yz4VzmHTnF/uWYH04OGatB4alfSgpUL8SlpWXmdNShdLlp4ePv1Pvyz3t6PyBs0Irlk0+7lEmcztYoornbKIZ5Zv9aREHJgkxDjn8OP//U= Received: by 10.114.177.1 with SMTP id z1mr2850400wae.1176221387841; Tue, 10 Apr 2007 09:09:47 -0700 (PDT) Received: by 10.115.32.4 with HTTP; Tue, 10 Apr 2007 09:09:47 -0700 (PDT) Message-ID: Date: Wed, 11 Apr 2007 01:09:47 +0900 From: "Junghoon Jee" To: "Basavaraj Patil" Subject: Re: [Mip6] Dynamic HoA assignment In-Reply-To: MIME-Version: 1.0 References: X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1224230036==" Errors-To: mip6-bounces@ietf.org --===============1224230036== Content-Type: multipart/alternative; boundary="----=_Part_23395_19100944.1176221387666" ------=_Part_23395_19100944.1176221387666 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello Raj, I'd say that we need not necessary limit the ways of configuring HoA. Therefore, I am in favor of keeping the HoA configuration way specified from draft-ietf-mip6-hiopt. Junghoon 2007/4/6, Basavaraj Patil : > > > Hello, > > Currently the I-D draft-ietf-mip6-hiopt proposes the MN obtain the HoA as > well in addition to the HA address and prefix via DHCP. > > I think the MN should obtain the minimal information required to > bootstrap. > It is better to have the HA assign the MN an HoA. To do this we would > require capability similar to MIP4 wherein the BU can be sent with an > unspecified HoA. This is currently not possible as per RFC3775. > > Should we consider allowing the MN sending a BU with the unspecified HoA > and > obtain an HoA (assigned by the HA) in the BAck? > > I-D: draft-devarapalli-mip6-authprotocol-bootstrap proposes such > capability. > Also do we need to consider standardizing the bootstrapping mechanism for > the auth protocol (RFC 4285)? > > -Basavaraj > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > ------=_Part_23395_19100944.1176221387666 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hello Raj,
I'd say that we need not necessary limit the ways of configuring HoA. Therefore, I am in favor of keeping the HoA configuration way specified from draft-ietf-mip6-hiopt.
 
Junghoon
 

 
2007/4/6, Basavaraj Patil <basavaraj.patil@nsn.com>:

Hello,

Currently the I-D draft-ietf-mip6-hiopt proposes the MN obtain the HoA as
well in addition to the HA address and prefix via DHCP.

I think the MN should obtain the minimal information required to bootstrap.
It is better to have the HA assign the MN an HoA. To do this we would
require capability similar to MIP4 wherein the BU can be sent with an
unspecified HoA. This is currently not possible as per RFC3775.

Should we consider allowing the MN sending a BU with the unspecified HoA and
obtain an HoA (assigned by the HA) in the BAck?

I-D: draft-devarapalli-mip6-authprotocol-bootstrap proposes such capability.
Also do we need to consider standardizing the bootstrapping mechanism for
the auth protocol (RFC 4285)?

-Basavaraj


_______________________________________________
Mip6 mailing list
Mip6@ietf.org
https://www1.ietf.org/mailman/listinfo/mip6

------=_Part_23395_19100944.1176221387666-- --===============1224230036== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1224230036==-- From mip6-bounces@ietf.org Tue Apr 10 12:37:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbJKt-0004NW-5m; Tue, 10 Apr 2007 12:36:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbJKo-0004Mk-M0 for mip6@ietf.org; Tue, 10 Apr 2007 12:36:46 -0400 Received: from web84112.mail.mud.yahoo.com ([68.142.206.199]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HbJKl-00080D-VI for mip6@ietf.org; Tue, 10 Apr 2007 12:36:46 -0400 Received: (qmail 98903 invoked by uid 60001); 10 Apr 2007 16:36:43 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=qwXdegy1eItLUEhhVTGeay746+kkv/uovOqEjTaPt05GACfWFnbTo3E/02mgMXpKn56YpcW8VZg8y1zlor6fdVI4xdcPoNUAMsOJc9SZ6N4F0gnjYviytrf0QE6sEPO5vpYeCgJi4YvltWhVRwrEytCsehT90KuNjs42nM+hY9w=; X-YMail-OSG: FR1WKn0VM1l2REdOK9fWeQMYh_Y7LyAMalcSWrqTdwKId0Y6uuUb86VrtRQsaDMYi6fAuG4Vd8456pydBr6x49bSmg-- Received: from [206.16.17.212] by web84112.mail.mud.yahoo.com via HTTP; Tue, 10 Apr 2007 09:36:43 PDT X-Mailer: YahooMailRC/476 YahooMailWebService/0.7.41.8 Date: Tue, 10 Apr 2007 09:36:43 -0700 (PDT) From: Behcet Sarikaya Subject: Re: [Mip6] Dynamic HoA assignment To: "Chowdhury, Kuntal" MIME-Version: 1.0 Message-ID: <277166.98253.qm@web84112.mail.mud.yahoo.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Cc: Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Behcet Sarikaya List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0381892361==" Errors-To: mip6-bounces@ietf.org --===============0381892361== Content-Type: multipart/alternative; boundary="0-532534635-1176223003=:98253" --0-532534635-1176223003=:98253 Content-Type: text/plain; charset=ascii Hi Kuntal, RFC 3775 requires BU's to contain HoA destination option. HoA destination option must contain a routable unicast address in HoA field so 0::0 is not possible. I remember WiMAX NWG had asked hiopt to add HoA option as well. I think this is OK so long as HoA is not used as the interface address. What Raj is asking is a unified method, then I would say the one that fits best to RFC 3775 is IKEv2 assignment. If this does not satisfy SDOs then maybe they should adopt it to their needs, e.g. using hiopt. Regards, Behcet ----- Original Message ---- From: "Chowdhury, Kuntal" To: Gerardo Giaretta Cc: Mobile IPv6 Mailing List Sent: Tuesday, April 10, 2007 9:39:46 AM Subject: RE: [Mip6] Dynamic HoA assignment Hi Gerardo, Please see inline... > -----Original Message----- > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > Sent: Tuesday, April 10, 2007 4:06 AM > To: Chowdhury, Kuntal > Cc: Basavaraj Patil; Mobile IPv6 Mailing List > Subject: Re: [Mip6] Dynamic HoA assignment > > Hi Kuntal, > > some comments inline... > > On 4/6/07, Chowdhury, Kuntal wrote: > > > > > > To do this we would > > > > require capability similar to MIP4 wherein the BU can be sent with > > an > > > > unspecified HoA. This is currently not possible as per RFC3775. > > > > > > > > > > I guess you are talking about rfc4285 (auth protocol). If IPsec is > > > used, IKEv2 can be used to assign the HoA, as specified in > > > draft-ietf-mip6-bootstrapping-split > > > > > [KC>] Again, regardless of IKEv2, we should allow the dynamic HoA > > assignment via mip6 BU/BA. People may like to do HoA (address) > > management based on MIP6 _authorization_ and NOT IKEv2 _authentication_. > > > > Can you please clarify? > > In the Diameter Application we are designing in DIME WG, we are > dealing with both authentication and authorization based on the IKEv2 > exchange between the MN and the HA. The HoA assignment is done via > IKEv2 through the configuration payload: I don't understand why an > authorization step is not possible if this HoA assignment method is > used. > So I don't think that HoA assignment in BA enables authorization and > IKEv2 does not. > [KC>] Yes, I am aware of that. However, as I mentioned on the DIME mailing list, authorizing the MN for MIP6 service (HoA assignment) when the MN is just negotiating IKE/IPsec SA is sort of a blind authorization. There is no standard way defined in IKE_AUTH/EAP transactions to indicate that the MN is actually trying to access MIP6 service. One can assume that simply because the MN is setting up an IPsec SA with the HA, it intends to do MIP6. As I have mentioned during the DIME discussion, this assumption won't be true in all cases. So, there will be various ways to figure out MN's intent and authorize the MN accordingly. While this is what you are alluding to, I think we need to allow the BU/BA based HoA assignment so that the HoA assignment is tied to MIP6 access rather than IKE/IPsec access. > > > > > > I-D: draft-devarapalli-mip6-authprotocol-bootstrap proposes such > > > capability. > > > > Also do we need to consider standardizing the bootstrapping > > mechanism > > > for > > > > the auth protocol (RFC 4285)? > > > > > > > > > > Some SDOs use rfc4285 authentication for MIPv6, but as far as I know, > > > they have already defined their own bootstrapping solution. What would > > > be the role of an IETF solution with regards to those? > > > > > [KC>] role of IETF is to define an IETF way to provide dynamic HoA > > allocation capability via mip6 BU/BA. We don't have that today. Also, > > you are forgetting the per-Node SA model that is used in PMIP6. We need > > this capability for PMIP6 also. > > > > I'm still trying to understand why this is needed. Again, if rfc4285 > is used, I'm fine. But if IKEv2/IPsec is used, I don't see any reason > why such a new mechanism should be defined. > [KC>] Such a mechanism should be defined unless there is something technically wrong with setting HoA=0::0 in the BU. > --Gerardo > > > > > > > > --Gerardo > > > > > > > -Basavaraj > > > > > > > > > > > > _______________________________________________ > > > > Mip6 mailing list > > > > Mip6@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > > > > _______________________________________________ > > > Mip6 mailing list > > > Mip6@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > "This email message and any attachments are confidential information of > Starent Networks, Corp. The information transmitted may not be used to > create or change any contractual obligations of Starent Networks, Corp. > Any review, retransmission, dissemination or other use of, or taking of > any action in reliance upon this e-mail and its attachments by persons or > entities other than the intended recipient is prohibited. If you are not > the intended recipient, please notify the sender immediately -- by > replying to this message or by sending an email to > postmaster@starentnetworks.com -- and destroy all copies of this message > and any attachments without reading or disclosing their contents. Thank > you." > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --0-532534635-1176223003=:98253 Content-Type: text/html; charset=ascii
Hi Kuntal,
  RFC 3775 requires BU's to contain HoA destination option. HoA destination option must contain a routable unicast address in HoA field so 0::0 is not possible.
  I remember WiMAX NWG had asked hiopt to add HoA option as well. I think this is OK so long as HoA is not used as the interface address.
  What Raj is asking is a unified method, then I would say the one that fits best to RFC 3775 is IKEv2 assignment. If this does not satisfy SDOs then maybe they should adopt it to their needs, e.g. using hiopt.
 
Regards,
 
Behcet

----- Original Message ----
From: "Chowdhury, Kuntal" <kchowdhury@starentnetworks.com>
To: Gerardo Giaretta <gerardo.giaretta@gmail.com>
Cc: Mobile IPv6 Mailing List <mip6@ietf.org>
Sent: Tuesday, April 10, 2007 9:39:46 AM
Subject: RE: [Mip6] Dynamic HoA assignment

Hi Gerardo,

Please see inline...

> -----Original Message-----
> From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com]
> Sent: Tuesday, April 10, 2007 4:06 AM
> To: Chowdhury, Kuntal
> Cc: Basavaraj Patil; Mobile IPv6 Mailing List
> Subject: Re: [Mip6] Dynamic HoA assignment
>
> Hi Kuntal,
>
> some comments inline...
>
> On 4/6/07, Chowdhury, Kuntal <kchowdhury@starentnetworks.com> wrote:
> >
> > > > To do this we would
> > > > require capability similar to MIP4 wherein the BU can be sent
with
> > an
> > > > unspecified HoA. This is currently not possible as per RFC3775.
> > > >
> > >
> > > I guess you are talking about rfc4285 (auth protocol). If IPsec is
> > > used, IKEv2 can be used to assign the HoA, as specified in
> > > draft-ietf-mip6-bootstrapping-split
> > >
> > [KC>] Again, regardless of IKEv2, we should allow the dynamic HoA
> > assignment via mip6 BU/BA. People may like to do HoA (address)
> > management based on MIP6 _authorization_ and NOT IKEv2
_authentication_.
> >
>
> Can you please clarify?
>
> In the Diameter Application we are designing in DIME WG, we are
> dealing with both authentication and authorization based on the IKEv2
> exchange between the MN and the HA. The HoA assignment is done via
> IKEv2 through the configuration payload: I don't understand why an
> authorization step is not possible if this HoA assignment method is
> used.
> So I don't think that HoA assignment in BA enables authorization and
> IKEv2 does not.
>
[KC>] Yes, I am aware of that. However, as I mentioned on the DIME
mailing list, authorizing the MN for MIP6 service (HoA assignment) when
the MN is just negotiating IKE/IPsec SA is sort of a blind
authorization. There is no standard way defined in IKE_AUTH/EAP
transactions to indicate that the MN is actually trying to access MIP6
service. One can assume that simply because the MN is setting up an
IPsec SA with the HA, it intends to do MIP6. As I have mentioned during
the DIME discussion, this assumption won't be true in all cases. So,
there will be various ways to figure out MN's intent and authorize the
MN accordingly. While this is what you are alluding to, I think we need
to allow the BU/BA based HoA assignment so that the HoA assignment is
tied to MIP6 access rather than IKE/IPsec access.

> >
> > > > I-D: draft-devarapalli-mip6-authprotocol-bootstrap proposes such
> > > capability.
> > > > Also do we need to consider standardizing the bootstrapping
> > mechanism
> > > for
> > > > the auth protocol (RFC 4285)?
> > > >
> > >
> > > Some SDOs use rfc4285 authentication for MIPv6, but as far as I
know,
> > > they have already defined their own bootstrapping solution. What
would
> > > be the role of an IETF solution with regards to those?
> > >
> > [KC>] role of IETF is to define an IETF way to provide dynamic HoA
> > allocation capability via mip6 BU/BA. We don't have that today.
Also,
> > you are forgetting the per-Node SA model that is used in PMIP6. We
need
> > this capability for PMIP6 also.
> >
>
> I'm still trying to understand why this is needed. Again, if rfc4285
> is used, I'm fine. But if IKEv2/IPsec is used, I don't see any reason
> why such a new mechanism should be defined.
>
[KC>] Such a mechanism should be defined unless there is something
technically wrong with setting HoA=0::0 in the BU.  

> --Gerardo
>
> >
> >
> > > --Gerardo
> > >
> > > > -Basavaraj
> > > >
> > > >
> > > > _______________________________________________
> > > > Mip6 mailing list
> > > > Mip6@ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/mip6
> > > >
> > >
> > > _______________________________________________
> > > Mip6 mailing list
> > > Mip6@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/mip6
> >
> >
> > "This email message and any attachments are confidential information
of
> Starent Networks, Corp. The information transmitted may not be used to
> create or change any contractual obligations of Starent Networks,
Corp.
> Any review, retransmission, dissemination or other use of, or taking
of
> any action in reliance upon this e-mail and its attachments by persons
or
> entities other than the intended recipient is prohibited. If you are
not
> the intended recipient, please notify the sender immediately -- by
> replying to this message or by sending an email to
> postmaster@starentnetworks.com -- and destroy all copies of this
message
> and any attachments without reading or disclosing their contents.
Thank
> you."
> >

_______________________________________________
Mip6 mailing list
Mip6@ietf.org
https://www1.ietf.org/mailman/listinfo/mip6

--0-532534635-1176223003=:98253-- --===============0381892361== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0381892361==-- From mip6-bounces@ietf.org Tue Apr 10 14:11:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbKoE-0004Ft-3X; Tue, 10 Apr 2007 14:11:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbKoD-0004Fo-6k for mip6@ietf.org; Tue, 10 Apr 2007 14:11:13 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbKo9-0005Cb-32 for mip6@ietf.org; Tue, 10 Apr 2007 14:11:13 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 5609A90016 for ; Tue, 10 Apr 2007 14:11:05 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17812-01 for ; Tue, 10 Apr 2007 14:11:01 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Tue, 10 Apr 2007 14:11:01 -0400 (EDT) Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Apr 2007 14:11:01 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Mip6] Dynamic HoA assignment Date: Tue, 10 Apr 2007 14:11:00 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D7024D9E22@exchtewks2.starentnetworks.com> In-Reply-To: <277166.98253.qm@web84112.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Dynamic HoA assignment Thread-Index: Acd7jnRMQUOE1FizSPKDq/pTRmJnEQAC8sEw From: "Chowdhury, Kuntal" To: "Behcet Sarikaya" X-OriginalArrivalTime: 10 Apr 2007 18:11:01.0327 (UTC) FILETIME=[98930DF0:01C77B9B] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 111b48b3edee1f6fe0a892c95423c18d Cc: Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1469905262==" Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --===============1469905262== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C77B9B.985F9A80" This is a multi-part message in MIME format. ------_=_NextPart_001_01C77B9B.985F9A80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 =20 ________________________________ From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com]=20 Sent: Tuesday, April 10, 2007 11:37 AM To: Chowdhury, Kuntal Cc: Mobile IPv6 Mailing List Subject: Re: [Mip6] Dynamic HoA assignment =20 Hi Kuntal, RFC 3775 requires BU's to contain HoA destination option. HoA destination option must contain a routable unicast address in HoA field so 0::0 is not possible.=20 [KC>] Yes. But, the proposal is to relax that requirement. =20 I remember WiMAX NWG had asked hiopt to add HoA option as well. I think this is OK so long as HoA is not used as the interface address. [KC>] HoA has an explicit DHCP op-code. So, it should not be used as anything other than as a HoA. =20 What Raj is asking is a unified method, then I would say the one that fits best to RFC 3775 is IKEv2 assignment. If this does not satisfy SDOs then maybe they should adopt it to their needs, e.g. using hiopt. [KC>] IMHO, a DHCP op-code to carry HoA should suffice. We don't have to go any further than that in IETF. =20 =20 Regards, =20 Behcet ----- Original Message ---- From: "Chowdhury, Kuntal" To: Gerardo Giaretta Cc: Mobile IPv6 Mailing List Sent: Tuesday, April 10, 2007 9:39:46 AM Subject: RE: [Mip6] Dynamic HoA assignment Hi Gerardo,=20 Please see inline... > -----Original Message----- > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > Sent: Tuesday, April 10, 2007 4:06 AM > To: Chowdhury, Kuntal > Cc: Basavaraj Patil; Mobile IPv6 Mailing List > Subject: Re: [Mip6] Dynamic HoA assignment >=20 > Hi Kuntal, >=20 > some comments inline... >=20 > On 4/6/07, Chowdhury, Kuntal wrote: > > > > > > To do this we would > > > > require capability similar to MIP4 wherein the BU can be sent with > > an > > > > unspecified HoA. This is currently not possible as per RFC3775. > > > > > > > > > > I guess you are talking about rfc4285 (auth protocol). If IPsec is > > > used, IKEv2 can be used to assign the HoA, as specified in > > > draft-ietf-mip6-bootstrapping-split > > > > > [KC>] Again, regardless of IKEv2, we should allow the dynamic HoA > > assignment via mip6 BU/BA. People may like to do HoA (address) > > management based on MIP6 _authorization_ and NOT IKEv2 _authentication_. > > >=20 > Can you please clarify? >=20 > In the Diameter Application we are designing in DIME WG, we are > dealing with both authentication and authorization based on the IKEv2 > exchange between the MN and the HA. The HoA assignment is done via > IKEv2 through the configuration payload: I don't understand why an > authorization step is not possible if this HoA assignment method is > used. > So I don't think that HoA assignment in BA enables authorization and > IKEv2 does not. >=20 [KC>] Yes, I am aware of that. However, as I mentioned on the DIME mailing list, authorizing the MN for MIP6 service (HoA assignment) when the MN is just negotiating IKE/IPsec SA is sort of a blind authorization. There is no standard way defined in IKE_AUTH/EAP transactions to indicate that the MN is actually trying to access MIP6 service. One can assume that simply because the MN is setting up an IPsec SA with the HA, it intends to do MIP6. As I have mentioned during the DIME discussion, this assumption won't be true in all cases. So, there will be various ways to figure out MN's intent and authorize the MN accordingly. While this is what you are alluding to, I think we need to allow the BU/BA based HoA assignment so that the HoA assignment is tied to MIP6 access rather than IKE/IPsec access. > > > > > > I-D: draft-devarapalli-mip6-authprotocol-bootstrap proposes such > > > capability. > > > > Also do we need to consider standardizing the bootstrapping > > mechanism > > > for > > > > the auth protocol (RFC 4285)? > > > > > > > > > > Some SDOs use rfc4285 authentication for MIPv6, but as far as I know, > > > they have already defined their own bootstrapping solution. What would > > > be the role of an IETF solution with regards to those? > > > > > [KC>] role of IETF is to define an IETF way to provide dynamic HoA > > allocation capability via mip6 BU/BA. We don't have that today. Also, > > you are forgetting the per-Node SA model that is used in PMIP6. We need > > this capability for PMIP6 also. > > >=20 > I'm still trying to understand why this is needed. Again, if rfc4285 > is used, I'm fine. But if IKEv2/IPsec is used, I don't see any reason > why such a new mechanism should be defined. >=20 [KC>] Such a mechanism should be defined unless there is something technically wrong with setting HoA=3D0::0 in the BU. =20 > --Gerardo >=20 > > > > > > > --Gerardo > > > > > > > -Basavaraj > > > > > > > > > > > > _______________________________________________ > > > > Mip6 mailing list > > > > Mip6@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > > > > _______________________________________________ > > > Mip6 mailing list > > > Mip6@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > "This email message and any attachments are confidential information of > Starent Networks, Corp. The information transmitted may not be used to > create or change any contractual obligations of Starent Networks, Corp. > Any review, retransmission, dissemination or other use of, or taking of > any action in reliance upon this e-mail and its attachments by persons or > entities other than the intended recipient is prohibited. If you are not > the intended recipient, please notify the sender immediately -- by > replying to this message or by sending an email to > postmaster@starentnetworks.com -- and destroy all copies of this message > and any attachments without reading or disclosing their contents. Thank > you." > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 =20 ------_=_NextPart_001_01C77B9B.985F9A80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From: = Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com]
Sent: Tuesday, April 10, = 2007 11:37 AM
To: Chowdhury, Kuntal
Cc: Mobile IPv6 Mailing List
Subject: Re: [Mip6] = Dynamic HoA assignment

 

Hi Kuntal,

  RFC 3775 requires BU's to contain HoA destination option. = HoA destination option must contain a routable unicast address in HoA field = so 0::0 is not possible.

[KC>] Yes. But, the proposal is to relax that requirement.

 

  I remember WiMAX NWG had asked hiopt to add HoA = option as well. I think this is OK so long as HoA is not used as the interface = address.

[KC>] HoA has an explicit DHCP op-code. So, it = should not be used as anything other than as a = HoA.

 

  What Raj is asking is a unified method, then I would say = the one that fits best to RFC 3775 is IKEv2 assignment. If this does not satisfy = SDOs then maybe they should adopt it to their needs, e.g. using = hiopt.

[KC>] IMHO, a DHCP op-code to carry HoA should = suffice. We don’t have to go any further than that in = IETF.

 

 

Regards,

 

Behcet

----- Original = Message ----
From: "Chowdhury, = Kuntal" <kchowdhury@starentnetworks.com>
To: Gerardo Giaretta <gerardo.giaretta@gmail.com>
Cc: Mobile IPv6 Mailing List <mip6@ietf.org>
Sent: Tuesday, April 10, 2007 9:39:46 AM
Subject: RE: [Mip6] Dynamic HoA assignment

Hi Gerardo,

Please see inline...

> -----Original Message-----
> From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com]
> Sent: Tuesday, April 10, 2007 4:06 AM
> To: Chowdhury, = Kuntal
> Cc: Basavaraj Patil; Mobile IPv6 = Mailing List
> Subject: Re: [Mip6] Dynamic HoA assignment
>
> Hi Kuntal,
>
> some comments inline...
>
> On 4/6/07, Chowdhury, = Kuntal <kchowdhury@starentnetworks.com> wrote:
> >
> > > > To do this we would
> > > > require capability similar to MIP4 wherein the BU = can be sent
with
> > an
> > > > unspecified HoA. This is currently not possible as = per RFC3775.
> > > >
> > >
> > > I guess you are talking about rfc4285 (auth protocol). If = IPsec is
> > > used, IKEv2 can be used to assign the HoA, as specified = in
> > > draft-ietf-mip6-bootstrapping-split
> > >
> > [KC>] Again, regardless of IKEv2, we should allow the = dynamic HoA
> > assignment via mip6 BU/BA. People may like to do HoA = (address)
> > management based on MIP6 _authorization_ and NOT IKEv2
_authentication_.
> >
>
> Can you please clarify?
>
> In the Diameter Application we are designing in DIME WG, we are
> dealing with both authentication and authorization based on the = IKEv2
> exchange between the MN and the HA. The HoA assignment is done = via
> IKEv2 through the configuration payload: I don't understand why = an
> authorization step is not possible if this HoA assignment method = is
> used.
> So I don't think that HoA assignment in BA enables authorization = and
> IKEv2 does not.
>
[KC>] Yes, I am aware of that. However, as I mentioned on the = DIME
mailing list, authorizing the MN for MIP6 service (HoA assignment) = when
the MN is just negotiating IKE/IPsec SA is sort of a blind
authorization. There is no standard way defined in IKE_AUTH/EAP
transactions to indicate that the MN is actually trying to access = MIP6
service. One can assume that simply because the MN is setting up an
IPsec SA with the HA, it intends to do MIP6. As I have mentioned = during
the DIME discussion, this assumption won't be true in all cases. So,
there will be various ways to figure out MN's intent and authorize = the
MN accordingly. While this is what you are alluding to, I think we = need
to allow the BU/BA based HoA assignment so that the HoA assignment = is
tied to MIP6 access rather than IKE/IPsec access.

> >
> > > > I-D: draft-devarapalli-mip6-authprotocol-bootstrap = proposes such
> > > capability.
> > > > Also do we need to consider standardizing the = bootstrapping
> > mechanism
> > > for
> > > > the auth protocol (RFC 4285)?
> > > >
> > >
> > > Some SDOs use rfc4285 authentication for MIPv6, but as = far as I
know,
> > > they have already defined their own bootstrapping = solution. What
would
> > > be the role of an IETF solution with regards to = those?
> > >
> > [KC>] role of IETF is to define an IETF way to provide = dynamic HoA
> > allocation capability via mip6 BU/BA. We don't have that = today.
Also,
> > you are forgetting the per-Node SA model that is used in = PMIP6. We
need
> > this capability for PMIP6 also.
> >
>
> I'm still trying to understand why this is needed. Again, if = rfc4285
> is used, I'm fine. But if IKEv2/IPsec is used, I don't see any = reason
> why such a new mechanism should be defined.
>
[KC>] Such a mechanism should be defined unless there is = something
technically wrong with setting HoA=3D0::0 in the BU.  

> --Gerardo
>
> >
> >
> > > --Gerardo
> > >
> > > > -Basavaraj
> > > >
> > > >
> > > > _______________________________________________
> > > > Mip6 mailing list
> > > > Mip6@ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/mip6
> > > >
> > >
> > > _______________________________________________
> > > Mip6 mailing list
> > > Mip6@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/mip6
> >
> >
> > "This email message and any attachments are confidential information
of
> Starent Networks, Corp. The information transmitted may not be used = to
> create or change any contractual obligations of Starent = Networks,
Corp.
> Any review, retransmission, dissemination or other use of, or = taking
of
> any action in reliance upon this e-mail and its attachments by = persons
or
> entities other than the intended recipient is prohibited. If you = are
not
> the intended recipient, please notify the sender immediately -- = by
> replying to this message or by sending an email to
> postmaster@starentnetworks.com -- and destroy all copies of = this
message
> and any attachments without reading or disclosing their = contents.
Thank
> you."
> >

_______________________________________________
Mip6 mailing list
Mip6@ietf.org
https://www1.ietf.org/mailman/listinfo/mip6

 

------_=_NextPart_001_01C77B9B.985F9A80-- --===============1469905262== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1469905262==-- From mip6-bounces@ietf.org Tue Apr 10 18:21:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbOhA-0005r7-3W; Tue, 10 Apr 2007 18:20:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbOh9-0005r1-IB for mip6@ietf.org; Tue, 10 Apr 2007 18:20:11 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbOh8-0007bD-9P for mip6@ietf.org; Tue, 10 Apr 2007 18:20:11 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Apr 2007 15:20:09 -0700 Message-ID: <461C0D99.90900@azairenet.com> Date: Tue, 10 Apr 2007 15:20:09 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Gerardo Giaretta Subject: Re: [Mip6] Dynamic HoA assignment References: <7CCD07160348804497EF29E9EA5560D7024D9DDF$0001@exchtewks2.starentnetworks.com> <456943D540CFC14A8D7138E64843F85304499C4F@daebe101.NOE.Nokia.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Apr 2007 22:20:09.0937 (UTC) FILETIME=[66A3EC10:01C77BBE] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Gerardo Giaretta wrote: >> Is there an issue with the IPsec SA >> establishment >> in case the HoA assignment has to be delayed until the MN sends the BU? >> Or can the SA be modified to reflect the HoA assigned by the HA? >> > > I would leave the floor to Vijay or Francis here. The IPsec SA is based on the mobile node's home address. So the home address is needed before the SA can be created. I have some > comments/doubts though. > > Usually the MN specifies the HoA in the TSi payload when setting up > the SA for BU/BA. This is replaced with the correct HoA by the HA in > the IKEv2 response if dynamic HoA assignment is done via IKEv2. In > this case at the end of the IKEv2 exchange, the MN and the HA can > update the SPD entries with the corrects TSi (i.e. Home Address). > > How this can be done if the HoA assignment is done via BA? Which is > the TSi in the meanwhile? Just HoA=all zeros? If so, when the HoA is > assigned, should the MN update the TSi creating a child SA? > > It seems to me this is adding unnecessary complexity to the > bootstrapping procedure. Agreed. You could make it work, but only through a bunch of hacks. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Apr 11 03:57:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbXhR-0000kJ-7y; Wed, 11 Apr 2007 03:57:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbXhP-0000iP-AT for mip6@ietf.org; Wed, 11 Apr 2007 03:57:03 -0400 Received: from neon.tcs.hut.fi ([130.233.215.20] helo=mail.tcs.hut.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbXdP-0007VD-Iq for mip6@ietf.org; Wed, 11 Apr 2007 03:52:59 -0400 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by mail.tcs.hut.fi (Postfix) with ESMTP id 755432C020C35; Wed, 11 Apr 2007 10:52:54 +0300 (EEST) Date: Wed, 11 Apr 2007 10:52:54 +0300 (EEST) From: Wassim Haddad To: Basavaraj Patil Subject: Re: [Mip6] Consensus call on DS-MIP6 issue 73 (IPv4 CoA in the BU) In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Raj, My vote is 1: keep the IPv4 mapped address in the source address field when sending the BU. Regards, Wassim H. On Thu, 5 Apr 2007, Basavaraj Patil wrote: > > Hello, > > I would like to get consensus from the WG on another DS-MIP6 issue > which is pending resolution. > > The issue is about how to include the IPv4 CoA of the MN in the > binding update. > > The choices are: > > 1. Keep the IPv4 mapped address in the source address field when > sending the BU > > 2. Remove the IPv4 mapped address from the src address of the BU and > replace it with the Home address. The IPv4 care-of address will be > included in a new IPv4 alt-CoA option. > > Please express your opinion and preference (a brief justification of > why would be useful but not required) by Thursday, April 12th 07. > > The issue has been noted and is in the tracker at: > http://www.mip4.org/issues/tracker/mip6/issue73 > > -Basavaraj > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Apr 11 03:59:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbXjl-0001Em-5z; Wed, 11 Apr 2007 03:59:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbXjk-0001Eh-Jq for mip6@ietf.org; Wed, 11 Apr 2007 03:59:28 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbXjj-0000kf-6F for mip6@ietf.org; Wed, 11 Apr 2007 03:59:28 -0400 Received: from ep_ms5_bk (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JGB00AMYQ6XJF@mailout1.samsung.com> for mip6@ietf.org; Wed, 11 Apr 2007 16:59:21 +0900 (KST) Received: from ep_spt01 (ms5.samsung.com [203.254.225.113]) by ms5.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JGB00GPOQ6XGY@ms5.samsung.com> for mip6@ietf.org; Wed, 11 Apr 2007 16:59:21 +0900 (KST) Content-return: prohibited Date: Wed, 11 Apr 2007 07:59:21 +0000 (GMT) From: Heejin Jang Subject: Re: [Mip6] Dynamic HoA assignment To: basavaraj.patil@nsn.com, mip6@ietf.org Message-id: <27165242.528561176278361285.JavaMail.weblogic@ep_ml22> MIME-version: 1.0 MIME-version: 1.0 X-Priority: 3 Msgkey: 20070411075921284@heejin.jang X-MTR: 20070411075921284@heejin.jang X-EPLocale: ko_KR.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-EPApproval-Locale: X-Spam-Score: 2.1 (++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: heejin.jang@samsung.com List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0535009483==" Errors-To: mip6-bounces@ietf.org --===============0535009483== Content-return: prohibited Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: base64 SGksIFJhaiAmIGZvbGtzLiANCiANCkkgdGhpbmsgdGhhdCBIb0EgYXNzaWdubWVudCB0aHJvdWdo IERIQ1AgaXMgbmVjZXNzYXJ5Lg0KDQpJbiBQcm94eSBNSVAsIE1OIGhhcyBwbGFpbiBJUCBzdGFj ayAgd2l0aG91dCBhbnkgYWR2YW5jZWQgZnVuY3Rpb25zIHN1Y2ggYXMgTUlQIGNsaWVudCwgDQph bmQgIHRoZXJlIGlzIG5vIHdheSB0byBkZWxpdmVyIEhvQSB0byBNTiBpbiB0aGUgbGFzdCBob3Ag ZXhjZXB0IERIQ1AuIA0KU2luY2UsIGluIFBNSVAsIEhvQSBhc3NpZ25tZW50IGR1cmluZyBJS0V2 MiBvciBCVS9CQSBleGNoYW5nZXMgaXMgcG9zc2libGUgYmV0d2VlbiBQTUEgKE1BRykgJiBIQSwg DQpub3QgYmV0d2VlbiBNTiAmIEhBLiBUaG91Z2ggSG9BIGlzIGJvb3RzdHJhcHBlZCB0aHJvdWdo IGVpdGhlciBJS0V2MiBvciBCVS9CQSBleGNoYW5nZXMsIA0KaXQgc2hvdWxkIGJlIGRlbGl2ZXJl ZCBmcm9tIHRoZSBuZXR3b3JrIHRvIHRoZSBNTiBhZnRlciBhbGwgYW5kIERIQ1AgY291bGQgYmUg YSBkZWxpdmVyeSBtZWNoYW5pc20gZm9yIGl0Lg0KDQotIFJlZ2FyZHMsIA0KSGVlamluLg0KDQoN Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEJhc2F2YXJhaiBQYXRpbCBbbWFp bHRvOmJhc2F2YXJhai5wYXRpbEBuc24uY29tXSANClNlbnQ6IEZyaWRheSwgQXByaWwgMDYsIDIw MDcgNzowNyBBTQ0KVG86IE1vYmlsZSBJUHY2IE1haWxpbmcgTGlzdA0KU3ViamVjdDogW01pcDZd IER5bmFtaWMgSG9BIGFzc2lnbm1lbnQNCg0KDQpIZWxsbywNCg0KQ3VycmVudGx5IHRoZSBJLUQg ZHJhZnQtaWV0Zi1taXA2LWhpb3B0IHByb3Bvc2VzIHRoZSBNTiBvYnRhaW4gdGhlIEhvQSBhcyB3 ZWxsIGluIGFkZGl0aW9uIHRvIHRoZSBIQSBhZGRyZXNzIGFuZCBwcmVmaXggdmlhIERIQ1AuDQoN CkkgdGhpbmsgdGhlIE1OIHNob3VsZCBvYnRhaW4gdGhlIG1pbmltYWwgaW5mb3JtYXRpb24gcmVx dWlyZWQgdG8gYm9vdHN0cmFwLg0KSXQgaXMgYmV0dGVyIHRvIGhhdmUgdGhlIEhBIGFzc2lnbiB0 aGUgTU4gYW4gSG9BLiBUbyBkbyB0aGlzIHdlIHdvdWxkIHJlcXVpcmUgY2FwYWJpbGl0eSBzaW1p bGFyIHRvIE1JUDQgd2hlcmVpbiB0aGUgQlUgY2FuIGJlIHNlbnQgd2l0aCBhbiB1bnNwZWNpZmll ZCBIb0EuIFRoaXMgaXMgY3VycmVudGx5IG5vdCBwb3NzaWJsZSBhcyBwZXIgUkZDMzc3NS4NCg0K U2hvdWxkIHdlIGNvbnNpZGVyIGFsbG93aW5nIHRoZSBNTiBzZW5kaW5nIGEgQlUgd2l0aCB0aGUg dW5zcGVjaWZpZWQgSG9BIGFuZCBvYnRhaW4gYW4gSG9BIChhc3NpZ25lZCBieSB0aGUgSEEpIGlu IHRoZSBCQWNrPw0KDQpJLUQ6IGRyYWZ0LWRldmFyYXBhbGxpLW1pcDYtYXV0aHByb3RvY29sLWJv b3RzdHJhcCBwcm9wb3NlcyBzdWNoIGNhcGFiaWxpdHkuDQpBbHNvIGRvIHdlIG5lZWQgdG8gY29u c2lkZXIgc3RhbmRhcmRpemluZyB0aGUgYm9vdHN0cmFwcGluZyBtZWNoYW5pc20gZm9yIHRoZSBh dXRoIHByb3RvY29sIChSRkMgNDI4NSk/DQoNCi1CYXNhdmFyYWoNCg0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTWlwNiBtYWlsaW5nIGxpc3QNCk1p cDZAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pcDYN Cg0K --===============0535009483== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0535009483==-- From mip6-bounces@ietf.org Wed Apr 11 04:24:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbY7K-0006Mh-F6; Wed, 11 Apr 2007 04:23:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbY7I-0006EO-HL for mip6@ietf.org; Wed, 11 Apr 2007 04:23:48 -0400 Received: from ug-out-1314.google.com ([66.249.92.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbY7H-0008WT-7n for mip6@ietf.org; Wed, 11 Apr 2007 04:23:48 -0400 Received: by ug-out-1314.google.com with SMTP id 72so57601ugd for ; Wed, 11 Apr 2007 01:23:46 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=AJwJkN5xuEItYi4ut22k7PKZwfnGcP0W7VRNp39G7bm0xvV5XVXEwR8gGPIrGyF0eBmlKle3WzeP4RkJShhTGJ5cwHRF+nx2wiCRrxQFDxNMd2pPta02mFXKx6i2dfQg+tMvvRcMoxnV6hjGUCF9u4/FEm/nvJV/wI+xlYtUH/E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=I0F+sXdYbOKjeQ7pr7jOgtCuLQ+5eLFGw0mxFYSN4rD7KEoMfXQcvB1XektnmSka3n5SEEQhw7TfK561WJ8sZTK/jHlG80SYJbtH/3JSrULIs66YDhqwQESrOTeTk8M3MAh8KY1w90kwVia7Zv4nV8mW56aRx/cDxfp2veCsZv4= Received: by 10.67.26.7 with SMTP id d7mr281073ugj.1176279826133; Wed, 11 Apr 2007 01:23:46 -0700 (PDT) Received: by 10.66.243.11 with HTTP; Wed, 11 Apr 2007 01:23:45 -0700 (PDT) Message-ID: Date: Wed, 11 Apr 2007 10:23:45 +0200 From: "Gerardo Giaretta" To: "Vijay Devarapalli" Subject: Re: [Mip6] Dynamic HoA assignment In-Reply-To: <461C0D99.90900@azairenet.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7CCD07160348804497EF29E9EA5560D7024D9DDF$0001@exchtewks2.starentnetworks.com> <456943D540CFC14A8D7138E64843F85304499C4F@daebe101.NOE.Nokia.com> <461C0D99.90900@azairenet.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org On 4/11/07, Vijay Devarapalli wrote: > Gerardo Giaretta wrote: > > >> Is there an issue with the IPsec SA > >> establishment > >> in case the HoA assignment has to be delayed until the MN sends the BU? > >> Or can the SA be modified to reflect the HoA assigned by the HA? > >> > > > > I would leave the floor to Vijay or Francis here. > > The IPsec SA is based on the mobile node's home address. > So the home address is needed before the SA can be created. > > I have some > > comments/doubts though. > > > > Usually the MN specifies the HoA in the TSi payload when setting up > > the SA for BU/BA. This is replaced with the correct HoA by the HA in > > the IKEv2 response if dynamic HoA assignment is done via IKEv2. In > > this case at the end of the IKEv2 exchange, the MN and the HA can > > update the SPD entries with the corrects TSi (i.e. Home Address). > > > > How this can be done if the HoA assignment is done via BA? Which is > > the TSi in the meanwhile? Just HoA=all zeros? If so, when the HoA is > > assigned, should the MN update the TSi creating a child SA? > > > > It seems to me this is adding unnecessary complexity to the > > bootstrapping procedure. > > Agreed. You could make it work, but only through a bunch > of hacks. > Good. So it seems that there are technical issues with HoA assignment via BA if IPsec is used. Moreover, as stated before, I don't see a need for this new mechanism, since IKEv2 already provides a similar solution. Therefore, I'm strongly against defining it, at least if IPsec is used. We can discuss this further for rfc4285. --Gerardo > Vijay > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Apr 11 10:53:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbeBm-0004TX-Jg; Wed, 11 Apr 2007 10:52:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbeBl-0004Sv-Lv for mip6@ietf.org; Wed, 11 Apr 2007 10:52:49 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbeBk-0004NZ-BG for mip6@ietf.org; Wed, 11 Apr 2007 10:52:49 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Apr 2007 07:52:47 -0700 Message-ID: <461CF63F.6000302@azairenet.com> Date: Wed, 11 Apr 2007 07:52:47 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: heejin.jang@samsung.com Subject: Re: [Mip6] Dynamic HoA assignment References: <27165242.528561176278361285.JavaMail.weblogic@ep_ml22> In-Reply-To: <27165242.528561176278361285.JavaMail.weblogic@ep_ml22> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Apr 2007 14:52:47.0980 (UTC) FILETIME=[120012C0:01C77C49] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Heejin Jang wrote: > Hi, Raj & folks. > > I think that HoA assignment through DHCP is necessary. > > In Proxy MIP, MN has plain IP stack without any advanced functions such as MIP client, > and there is no way to deliver HoA to MN in the last hop except DHCP. > Since, in PMIP, HoA assignment during IKEv2 or BU/BA exchanges is possible between PMA (MAG) & HA, > not between MN & HA. Though HoA is bootstrapped through either IKEv2 or BU/BA exchanges, > it should be delivered from the network to the MN after all and DHCP could be a delivery mechanism for it. The base PMIPv6 protocol assumes that the home prefix is sent to the mobile node using a router advertisement and then the mobile node auto-configures a home address from this prefix. IKEv2 based HoA assignment is obviously not applicable to PMIPv6 since there is no IKEv2 being run between the mobile node and the LMA. Vijay > > - Regards, > Heejin. > > > > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > Sent: Friday, April 06, 2007 7:07 AM > To: Mobile IPv6 Mailing List > Subject: [Mip6] Dynamic HoA assignment > > > Hello, > > Currently the I-D draft-ietf-mip6-hiopt proposes the MN obtain the HoA as well in addition to the HA address and prefix via DHCP. > > I think the MN should obtain the minimal information required to bootstrap. > It is better to have the HA assign the MN an HoA. To do this we would require capability similar to MIP4 wherein the BU can be sent with an unspecified HoA. This is currently not possible as per RFC3775. > > Should we consider allowing the MN sending a BU with the unspecified HoA and obtain an HoA (assigned by the HA) in the BAck? > > I-D: draft-devarapalli-mip6-authprotocol-bootstrap proposes such capability. > Also do we need to consider standardizing the bootstrapping mechanism for the auth protocol (RFC 4285)? > > -Basavaraj > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Apr 11 16:44:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbjfh-00009o-N7; Wed, 11 Apr 2007 16:44:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbjfh-00009b-4X for mip6@ietf.org; Wed, 11 Apr 2007 16:44:05 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hbjff-0000En-GF for mip6@ietf.org; Wed, 11 Apr 2007 16:44:05 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3BKhf0g012289; Wed, 11 Apr 2007 23:44:01 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Apr 2007 23:43:59 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Apr 2007 15:43:58 -0500 Received: from 172.19.244.138 ([172.19.244.138]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 11 Apr 2007 20:43:57 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Wed, 11 Apr 2007 15:44:29 -0500 Subject: Re: [Mip6] Dynamic HoA assignment From: Basavaraj Patil To: , Message-ID: Thread-Topic: [Mip6] Dynamic HoA assignment Thread-Index: Acd8ejMwcX/uTOhtEduLRAARJNUNiA== In-Reply-To: <27165242.528561176278361285.JavaMail.weblogic@ep_ml22> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 11 Apr 2007 20:43:58.0192 (UTC) FILETIME=[20D34700:01C77C7A] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070411234401-2E7CBBB0-3C77A5B2/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Heejin, I think we don't need to worry about how the HoA is delivered to the MN in the case of PMIP. That is for the PMIP I-D to specify. In PMIP the MN which obtains an address does not even realize it is an HoA. The scope of the current discussion is limited to bootstrapping for MIP6. IKEv2 is one way of delivering the HoA. This is the preferred approach (IMO) when the MN and HA establish an IPsec SA for securing the MIP6 signaling. When the MN does not estabish an IPsec SA and secures the BU/BAck using the auth protocol (RFC4285), we need the HA to assign the MN the HoA. I think this is the most practical way. Lets take a scenario in which the MN gets the HA address via some out-of-band means, so basically not via DHCP. The MN can then obtain the HoA from the HA via the MIP6 signaling messages. My point is that if the MN is going to run MIP6, then it should get the HoA as well via MIP6 messages (which is either via IKEv2 or the BAck). DHCP is adding yet another means of doing so which is not essential. The fewer the choices, the better it is from a protocol design perspective. -Raj On 4/11/07 2:59 AM, "ext Heejin Jang" wrote: > Hi, Raj & folks. > > I think that HoA assignment through DHCP is necessary. > > In Proxy MIP, MN has plain IP stack without any advanced functions such as > MIP client, > and there is no way to deliver HoA to MN in the last hop except DHCP. > Since, in PMIP, HoA assignment during IKEv2 or BU/BA exchanges is possible > between PMA (MAG) & HA, > not between MN & HA. Though HoA is bootstrapped through either IKEv2 or BU/BA > exchanges, > it should be delivered from the network to the MN after all and DHCP could be > a delivery mechanism for it. > > - Regards, > Heejin. > > > > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > Sent: Friday, April 06, 2007 7:07 AM > To: Mobile IPv6 Mailing List > Subject: [Mip6] Dynamic HoA assignment > > > Hello, > > Currently the I-D draft-ietf-mip6-hiopt proposes the MN obtain the HoA as well > in addition to the HA address and prefix via DHCP. > > I think the MN should obtain the minimal information required to bootstrap. > It is better to have the HA assign the MN an HoA. To do this we would require > capability similar to MIP4 wherein the BU can be sent with an unspecified HoA. > This is currently not possible as per RFC3775. > > Should we consider allowing the MN sending a BU with the unspecified HoA and > obtain an HoA (assigned by the HA) in the BAck? > > I-D: draft-devarapalli-mip6-authprotocol-bootstrap proposes such capability. > Also do we need to consider standardizing the bootstrapping mechanism for the > auth protocol (RFC 4285)? > > -Basavaraj > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Apr 11 20:37:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbnJN-0002vX-Bq; Wed, 11 Apr 2007 20:37:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbnJK-0002v1-3V; Wed, 11 Apr 2007 20:37:14 -0400 Received: from nit.isi.edu ([128.9.160.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbnJH-0001zo-Mi; Wed, 11 Apr 2007 20:37:14 -0400 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id l3C0bBiG028931; Wed, 11 Apr 2007 17:37:11 -0700 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id l3C0bBMj028930; Wed, 11 Apr 2007 17:37:11 -0700 Date: Wed, 11 Apr 2007 17:37:11 -0700 Message-Id: <200704120037.l3C0bBMj028930@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org X-Spam-Score: -14.8 (--------------) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: mip6@ietf.org, rfc-editor@rfc-editor.org Subject: [Mip6] RFC 4877 on Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4877 Title: Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture Author: V. Devarapalli, F. Dupont Status: Standards Track Date: April 2007 Mailbox: vijay.devarapalli@azairenet.com, Francis.Dupont@fdupont.fr Pages: 26 Characters: 57941 Updates: RFC3776 See-Also: I-D Tag: draft-ietf-mip6-ikev2-ipsec-08.txt URL: http://www.rfc-editor.org/rfc/rfc4877.txt This document describes Mobile IPv6 operation with the revised IPsec architecture and IKEv2. [STANDARDS TRACK] This document is a product of the Mobility for IPv6 Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Apr 12 05:11:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbvLI-0003Cn-8F; Thu, 12 Apr 2007 05:11:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbvLH-0003Bn-Bq for mip6@ietf.org; Thu, 12 Apr 2007 05:11:47 -0400 Received: from mout.perfora.net ([217.160.230.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbvLG-0006dv-3f for mip6@ietf.org; Thu, 12 Apr 2007 05:11:47 -0400 Received: from [85.102.195.35] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrelayus1) with ESMTP (Nemesis), id 0MKp2t-1HbvL92U2W-00005l; Thu, 12 Apr 2007 05:11:45 -0400 From: "Alper Yegin" To: "'Vijay Devarapalli'" , Subject: RE: [Mip6] Dynamic HoA assignment Date: Thu, 12 Apr 2007 12:11:21 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <461CF63F.6000302@azairenet.com> Thread-Index: Acd8STGai5zjTsIWQvGVFvF8agcoRQAmPdDw Message-ID: <0MKp2t-1HbvL92U2W-00005l@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX19sxptdz9ZHgUTFdCwMSJcjWpZYfyBxzHBXNTX WtgsywJfC2u9k1ZaE5xbkX6UqsU/aECSg1rki0epSwyXBq6rRD UDUpr/kc+0dgWk/7r7pPQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > The base PMIPv6 protocol assumes that the home prefix is sent > to the mobile node using a router advertisement and then the > mobile node auto-configures a home address from this prefix. Isn't an IPv6 host in charge of whether it uses address autoconfiguration or DHCP? If so, PMIPv6 spec shall accommodate that, assuming it does not want to dictate any particular behaviour on the hosts. Alper > > IKEv2 based HoA assignment is obviously not applicable to > PMIPv6 since there is no IKEv2 being run between the mobile > node and the LMA. > > Vijay > > > > > - Regards, > > Heejin. > > > > > > > > -----Original Message----- > > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > Sent: Friday, April 06, 2007 7:07 AM > > To: Mobile IPv6 Mailing List > > Subject: [Mip6] Dynamic HoA assignment > > > > > > Hello, > > > > Currently the I-D draft-ietf-mip6-hiopt proposes the MN obtain the HoA > as well in addition to the HA address and prefix via DHCP. > > > > I think the MN should obtain the minimal information required to > bootstrap. > > It is better to have the HA assign the MN an HoA. To do this we would > require capability similar to MIP4 wherein the BU can be sent with an > unspecified HoA. This is currently not possible as per RFC3775. > > > > Should we consider allowing the MN sending a BU with the unspecified HoA > and obtain an HoA (assigned by the HA) in the BAck? > > > > I-D: draft-devarapalli-mip6-authprotocol-bootstrap proposes such > capability. > > Also do we need to consider standardizing the bootstrapping mechanism > for the auth protocol (RFC 4285)? > > > > -Basavaraj > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Apr 12 09:29:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbzN1-0005Qz-Jt; Thu, 12 Apr 2007 09:29:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbzN0-0005Q1-H2 for mip6@ietf.org; Thu, 12 Apr 2007 09:29:50 -0400 Received: from otm-mgo01.iij.ad.jp ([210.138.20.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbzMz-0000Nl-My for mip6@ietf.org; Thu, 12 Apr 2007 09:29:50 -0400 Received: OTM-MO(otm-mgo01) id l3CDTlhT052557; Thu, 12 Apr 2007 22:29:47 +0900 (JST) Received: OTM-MIX(otm-mix01) id l3CDTlT7056257; Thu, 12 Apr 2007 22:29:47 +0900 (JST) Received: from [127.0.0.1] (jc-ssh00.iij.ad.jp [192.168.174.22]) by rsmtp.iij.ad.jp (OTM-MR/rsmtp01) id l3CDSTUA014905 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 12 Apr 2007 22:28:30 +0900 (JST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9D922117-15FF-4D7F-93E4-45D6C1CBA0BF@iijlab.net> Content-Transfer-Encoding: 7bit From: Keiichi SHIMA Subject: Re: [Mip6] Consensus call on DS-MIP6 issue 73 (IPv4 CoA in the BU) Date: Thu, 12 Apr 2007 22:29:45 +0900 To: Basavaraj Patil X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hello, On 2007/04/06, at 6:28, Basavaraj Patil wrote: > I would like to get consensus from the WG on another DS-MIP6 issue > which is pending resolution. > > The issue is about how to include the IPv4 CoA of the MN in the > binding update. > > The choices are: > > 1. Keep the IPv4 mapped address in the source address field when > sending the BU > > 2. Remove the IPv4 mapped address from the src address of the BU and > replace it with the Home address. The IPv4 care-of address will be > included in a new IPv4 alt-CoA option. > > Please express your opinion and preference (a brief justification of > why would be useful but not required) by Thursday, April 12th 07. I vote 2. The IPv4 mapped address is designed as an application interface for the legacy IPv4 applications to adapt to IPv6 with minimal change of its code, and I believe it is better to limit the usage to that purpose. --- Keiichi SHIMA IIJ Research Laboratory WIDE Project _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Apr 12 09:45:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbzbz-0003aF-1K; Thu, 12 Apr 2007 09:45:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbzbx-0003a9-HT for mip6@ietf.org; Thu, 12 Apr 2007 09:45:17 -0400 Received: from omta04sl.mx.bigpond.com ([144.140.93.156]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hbzbt-0005n3-1i for mip6@ietf.org; Thu, 12 Apr 2007 09:45:17 -0400 Received: from oaamta08sl.mx.bigpond.com ([124.191.178.123]) by omta04sl.mx.bigpond.com with ESMTP id <20070412134508.OHQZ28583.omta04sl.mx.bigpond.com@oaamta08sl.mx.bigpond.com>; Thu, 12 Apr 2007 13:45:08 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta08sl.mx.bigpond.com with ESMTP id <20070412134508.YALF19518.oaamta08sl.mx.bigpond.com@PC20005>; Thu, 12 Apr 2007 13:45:08 +0000 From: "Hesham Soliman" To: "'Basavaraj Patil'" Subject: RE: [Mip6] Consensus call on DS-MIP6 issue 73 (IPv4 CoA in the BU) Date: Thu, 12 Apr 2007 23:45:06 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: Acd8D1eiQ8xHSEs2SJeuDHzgXLIXTgA+VzOA Message-Id: <20070412134508.YALF19518.oaamta08sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: 'Mobile IPv6 Mailing List' X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org I prefer 1 as well. Hesham > -----Original Message----- > From: Wassim Haddad [mailto:whaddad@tcs.hut.fi] > Sent: Wednesday, April 11, 2007 5:53 PM > To: Basavaraj Patil > Cc: Mobile IPv6 Mailing List > Subject: Re: [Mip6] Consensus call on DS-MIP6 issue 73 (IPv4 > CoA in the BU) > > Hi Raj, > > My vote is 1: keep the IPv4 mapped address in the source > address field > when sending the BU. > > > Regards, > > Wassim H. > > > On Thu, 5 Apr 2007, Basavaraj Patil wrote: > > > > > Hello, > > > > I would like to get consensus from the WG on another DS-MIP6 issue > > which is pending resolution. > > > > The issue is about how to include the IPv4 CoA of the MN in the > > binding update. > > > > The choices are: > > > > 1. Keep the IPv4 mapped address in the source address field when > > sending the BU > > > > 2. Remove the IPv4 mapped address from the src address of > the BU and > > replace it with the Home address. The IPv4 care-of > address will be > > included in a new IPv4 alt-CoA option. > > > > Please express your opinion and preference (a brief > justification of > > why would be useful but not required) by Thursday, April 12th 07. > > > > The issue has been noted and is in the tracker at: > > http://www.mip4.org/issues/tracker/mip6/issue73 > > > > -Basavaraj > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Apr 12 15:06:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc4dB-0000yI-KW; Thu, 12 Apr 2007 15:06:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc4dA-0000y7-AT for mip6@ietf.org; Thu, 12 Apr 2007 15:06:52 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc4d9-0005Ko-1k for mip6@ietf.org; Thu, 12 Apr 2007 15:06:52 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Apr 2007 12:06:50 -0700 Message-ID: <461E8349.20506@azairenet.com> Date: Thu, 12 Apr 2007 12:06:49 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Alper Yegin Subject: Re: [Mip6] Dynamic HoA assignment References: <0MKp2t-1HbvL92U2W-00005l@mrelay.perfora.net> In-Reply-To: <0MKp2t-1HbvL92U2W-00005l@mrelay.perfora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Apr 2007 19:06:50.0526 (UTC) FILETIME=[B9ADC3E0:01C77D35] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: mip6@ietf.org, heejin.jang@samsung.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Alper Yegin wrote: >> The base PMIPv6 protocol assumes that the home prefix is sent >> to the mobile node using a router advertisement and then the >> mobile node auto-configures a home address from this prefix. > > Isn't an IPv6 host in charge of whether it uses address autoconfiguration or > DHCP? If so, PMIPv6 spec shall accommodate that, assuming it does not want > to dictate any particular behaviour on the hosts. 2461bis says Router Advertisements (and per-prefix flags) allow routers to inform hosts how to perform Address Autoconfiguration. For example, routers can specify whether hosts should use DHCPv6 and/or autonomous (stateless) address configuration. Stateful address configuration is not mandatory to support. RFC 4294 says Stateful Address Autoconfiguration MAY be supported. But I do agree DHCPv6 could be used between the mobile node and the MAG (Mobile Access Gateway). However, the address configuration for PMIPv6 depends to a large extent on what kind of link layer is used between the mobile node and the MAG. If the link layer is PPP, for e.g., IPv6CP is used. If the link layer is an IPsec tunnel then IKEv2 configuration payloads are used. The PMIPv6 protocol does consider this and has some text addressing this. Anyway, this discussion needs to happen on the NETLMM mailing list. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Apr 12 16:39:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc651-0006tQ-HX; Thu, 12 Apr 2007 16:39:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc650-0006tG-4r for mip6@ietf.org; Thu, 12 Apr 2007 16:39:42 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc64y-0005P8-Ks for mip6@ietf.org; Thu, 12 Apr 2007 16:39:42 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3CKdTqZ017601 for ; Thu, 12 Apr 2007 23:39:38 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Apr 2007 23:39:34 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Apr 2007 15:39:20 -0500 Received: from 172.19.244.124 ([172.19.244.124]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Thu, 12 Apr 2007 20:39:19 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Thu, 12 Apr 2007 15:39:52 -0500 From: Basavaraj Patil To: Mobile IPv6 Mailing List Message-ID: Thread-Topic: Summary and conclusion of DS-MIP6 Issue 73 Thread-Index: Acd9Qrh/90aJx+k1EduLRAARJNUNiA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 12 Apr 2007 20:39:20.0351 (UTC) FILETIME=[A5A1DAF0:01C77D42] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070412233938-44927BB0-4A1E2061/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [Mip6] Summary and conclusion of DS-MIP6 Issue 73 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Now to summarize the discussion and conclusion on Issue 73: The following emails provide a good summary of issue and the arguments that have been made for the use of alt-COA option vs the mapped-v4 address as the HoA in DSMIP6. 1. http://www1.ietf.org/mail-archive/web/mip6/current/msg05796.html 2. http://www1.ietf.org/mail-archive/web/mip6/current/msg05804.html I have also reviewed the discussion which occurred in February, 07 on this issue and taken that into account as well. The choice of whether to use a v4-mapped address as the HoA or to use the IPv6 HoA and indicate the v4 address in a new alt-CoA option in the BU has boiled down to a few main criteria: a. v4 mapped addresses are discarded in the Kame implementation. However it is not known if the same applies to other OS'. No one has come forth to make an explicit statement one way or another. b. The impact to the MIP6 code base is lower by using a v4 mapped address as the HoA instead of having to parse and process a new alt-COA option (which would be new code) c. Cleaner approach and no ambiguity (i.e overloading the HoA) by using the alt-COA option. Consensus (if you call it that), by a very slim margin at least, is to define a new alt-COA option for carrying the IPv4 address. So we are going to close this issue and make the necessary change in the I-D. IMO (without chair hat), I think that while both options are feasible, I have some concerns about using a mapped-v4 address (based on the comments by the Kame folks). To support DS-MIP6, code base for the HA and MN will change and hence I do not see this being a significant cause for concern. -Raj Just as an FYI, these are some of the people who expressed their opinions on this issue: Alt-CoA : Vijay, Henrik, Koshiro, Keiichi, Alex Mapped-v4: Conny, Hesham, Pascal, Wasim _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Apr 12 17:15:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc6dY-0004Ef-VG; Thu, 12 Apr 2007 17:15:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc6dX-0004EZ-6S for mip6@ietf.org; Thu, 12 Apr 2007 17:15:23 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc6dU-00052k-Rj for mip6@ietf.org; Thu, 12 Apr 2007 17:15:23 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Apr 2007 14:15:20 -0700 Message-ID: <461EA167.5060701@azairenet.com> Date: Thu, 12 Apr 2007 14:15:19 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Basavaraj Patil Subject: Re: [Mip6] Summary and conclusion of DS-MIP6 Issue 73 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Apr 2007 21:15:20.0453 (UTC) FILETIME=[AD274350:01C77D47] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Raj, Thanks for closing this issue. Vijay Basavaraj Patil wrote: > Now to summarize the discussion and conclusion on Issue 73: > > The following emails provide a good summary of issue and the arguments > that have been made for the use of alt-COA option vs the mapped-v4 > address as the HoA in DSMIP6. > > 1. http://www1.ietf.org/mail-archive/web/mip6/current/msg05796.html > 2. http://www1.ietf.org/mail-archive/web/mip6/current/msg05804.html > > I have also reviewed the discussion which occurred in February, 07 on this > issue and taken that into account as well. > > The choice of whether to use a v4-mapped address as the HoA or to use > the IPv6 HoA and indicate the v4 address in a new alt-CoA option in > the BU has boiled down to a few main criteria: > a. v4 mapped addresses are discarded in the Kame > implementation. However it is not known if the same applies to > other OS'. No one has come forth to make an explicit statement one > way or another. > b. The impact to the MIP6 code base is lower by using a v4 mapped > address as the HoA instead of having to parse and process a new > alt-COA option (which would be new code) > c. Cleaner approach and no ambiguity (i.e overloading the HoA) by > using the alt-COA option. > > Consensus (if you call it that), by a very slim margin at least, is to > define a new alt-COA option for carrying the IPv4 address. > > So we are going to close this issue and make the necessary change in > the I-D. > > IMO (without chair hat), I think that while both options are feasible, > I have some concerns about using a mapped-v4 address (based on the > comments by the Kame folks). To support DS-MIP6, code base for the HA > and MN will change and hence I do not see this being a significant > cause for concern. > > -Raj > > Just as an FYI, these are some of the people who expressed their > opinions on this issue: > > Alt-CoA : Vijay, Henrik, Koshiro, Keiichi, Alex > > Mapped-v4: Conny, Hesham, Pascal, Wasim > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Apr 12 17:48:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc794-00074i-8u; Thu, 12 Apr 2007 17:47:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc793-00074c-DL for mip6@ietf.org; Thu, 12 Apr 2007 17:47:57 -0400 Received: from mout.perfora.net ([217.160.230.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc792-0006Lc-6N for mip6@ietf.org; Thu, 12 Apr 2007 17:47:57 -0400 Received: from [88.235.149.214] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrelayus0) with ESMTP (Nemesis), id 0MKoyl-1Hc78x1ADj-0003Va; Thu, 12 Apr 2007 17:47:55 -0400 From: "Alper Yegin" To: "'Vijay Devarapalli'" Subject: RE: [Mip6] Dynamic HoA assignment Date: Fri, 13 Apr 2007 00:47:33 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <461E8349.20506@azairenet.com> Thread-Index: Acd9NcG180KgN3YuT/igIFuiar8pggAFhs3A Message-ID: <0MKoyl-1Hc78x1ADj-0003Va@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX19wp9X88qzrVe/UL8+x0P64e3anwjADXPFw1rz RtFgQ7IdfsU8nGnoXJhXHvogbP2vPOtFieBJBoO4d2V/1td9kZ tcgocjF7yiCJ+RF848Eaw== X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: mip6@ietf.org, heejin.jang@samsung.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > >> The base PMIPv6 protocol assumes that the home prefix is sent > >> to the mobile node using a router advertisement and then the > >> mobile node auto-configures a home address from this prefix. > > > > Isn't an IPv6 host in charge of whether it uses address > autoconfiguration or > > DHCP? If so, PMIPv6 spec shall accommodate that, assuming it does not > want > > to dictate any particular behaviour on the hosts. > > 2461bis says > > Router Advertisements (and per-prefix flags) allow routers to inform > hosts how to perform Address Autoconfiguration. For example, routers > can specify whether hosts should use DHCPv6 and/or > autonomous (stateless) address configuration. > > Stateful address configuration is not mandatory to support. > RFC 4294 says > > Stateful Address Autoconfiguration MAY be supported. > > But I do agree DHCPv6 could be used between the mobile node > and the MAG (Mobile Access Gateway). > > However, the address configuration for PMIPv6 depends to a > large extent on what kind of link layer is used between the > mobile node and the MAG. If the link layer is PPP, for e.g., > IPv6CP is used. If the link layer is an IPsec tunnel then > IKEv2 configuration payloads are used. So, your original statement does not sound accurate anymore. > The PMIPv6 protocol > does consider this and has some text addressing this. > Anyway, this discussion needs to happen on the NETLMM > mailing list. I agree, this requires some clarification. Alper > > Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Apr 12 17:54:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc7Fa-0002nV-ED; Thu, 12 Apr 2007 17:54:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc7FZ-0002nQ-CX for mip6@ietf.org; Thu, 12 Apr 2007 17:54:41 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc7FZ-0000Pe-3I for mip6@ietf.org; Thu, 12 Apr 2007 17:54:41 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Apr 2007 14:54:40 -0700 Message-ID: <461EAA9E.2000503@azairenet.com> Date: Thu, 12 Apr 2007 14:54:38 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Alper Yegin Subject: Re: [Mip6] Dynamic HoA assignment References: <0MKoyl-1Hc78x1ADj-0003Va@mrelay.perfora.net> In-Reply-To: <0MKoyl-1Hc78x1ADj-0003Va@mrelay.perfora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Apr 2007 21:54:40.0967 (UTC) FILETIME=[2C211D70:01C77D4D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: mip6@ietf.org, heejin.jang@samsung.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Alper Yegin wrote: >>>> The base PMIPv6 protocol assumes that the home prefix is sent >>>> to the mobile node using a router advertisement and then the >>>> mobile node auto-configures a home address from this prefix. >>> Isn't an IPv6 host in charge of whether it uses address >> autoconfiguration or >>> DHCP? If so, PMIPv6 spec shall accommodate that, assuming it does not >> want >>> to dictate any particular behaviour on the hosts. >> 2461bis says >> >> Router Advertisements (and per-prefix flags) allow routers to inform >> hosts how to perform Address Autoconfiguration. For example, routers >> can specify whether hosts should use DHCPv6 and/or >> autonomous (stateless) address configuration. >> >> Stateful address configuration is not mandatory to support. >> RFC 4294 says >> >> Stateful Address Autoconfiguration MAY be supported. >> >> But I do agree DHCPv6 could be used between the mobile node >> and the MAG (Mobile Access Gateway). >> >> However, the address configuration for PMIPv6 depends to a >> large extent on what kind of link layer is used between the >> mobile node and the MAG. If the link layer is PPP, for e.g., >> IPv6CP is used. If the link layer is an IPsec tunnel then >> IKEv2 configuration payloads are used. > > So, your original statement does not sound accurate anymore. ?? I said the default mechanism is to use router advertisement for conveying the home prefix to the mobile node. That is what is assumed in the Proxy MIPv6 base spec. That is still valid. You would be using router advertisements and stateless address auto-configuration as much as possible. When you have "special" link layers, then the link specific mechanisms are used. >> The PMIPv6 protocol >> does consider this and has some text addressing this. > > >> Anyway, this discussion needs to happen on the NETLMM >> mailing list. > > I agree, this requires some clarification. Take a look at the current text in draft-ietf-netlmm-pmip6-00 to see if it is sufficient. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 13 01:23:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcEFW-0002H6-P4; Fri, 13 Apr 2007 01:23:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcEFW-0002Gw-5M for mip6@ietf.org; Fri, 13 Apr 2007 01:23:06 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcEFT-0000bY-PU for mip6@ietf.org; Fri, 13 Apr 2007 01:23:06 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 68E9F9001D for ; Fri, 13 Apr 2007 01:23:00 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20153-20 for ; Fri, 13 Apr 2007 01:22:53 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Fri, 13 Apr 2007 01:22:53 -0400 (EDT) Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 01:22:53 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Dynamic HoA assignment Date: Fri, 13 Apr 2007 01:22:52 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D7024D9E7E@exchtewks2.starentnetworks.com> In-Reply-To: <461E8349.20506@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Dynamic HoA assignment Thread-Index: Acd9NcVEOlef0945Ssuic9sPQzWBxQAVcnZQ From: "Chowdhury, Kuntal" To: "Vijay Devarapalli" , "Alper Yegin" X-OriginalArrivalTime: 13 Apr 2007 05:22:53.0465 (UTC) FILETIME=[C94EA890:01C77D8B] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: mip6@ietf.org, heejin.jang@samsung.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org IPv6CP is used to negotiate the IID only which helps in producing the link local address. RS/RA or DHCPv6 is used to configure the global scope address. -Kuntal > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > Sent: Thursday, April 12, 2007 2:07 PM > To: Alper Yegin > Cc: mip6@ietf.org; heejin.jang@samsung.com > Subject: Re: [Mip6] Dynamic HoA assignment >=20 > Alper Yegin wrote: > >> The base PMIPv6 protocol assumes that the home prefix is sent > >> to the mobile node using a router advertisement and then the > >> mobile node auto-configures a home address from this prefix. > > > > Isn't an IPv6 host in charge of whether it uses address > autoconfiguration or > > DHCP? If so, PMIPv6 spec shall accommodate that, assuming it does not > want > > to dictate any particular behaviour on the hosts. >=20 > 2461bis says >=20 > Router Advertisements (and per-prefix flags) allow routers to inform > hosts how to perform Address Autoconfiguration. For example, routers > can specify whether hosts should use DHCPv6 and/or > autonomous (stateless) address configuration. >=20 > Stateful address configuration is not mandatory to support. > RFC 4294 says >=20 > Stateful Address Autoconfiguration MAY be supported. >=20 > But I do agree DHCPv6 could be used between the mobile node > and the MAG (Mobile Access Gateway). >=20 > However, the address configuration for PMIPv6 depends to a > large extent on what kind of link layer is used between the > mobile node and the MAG. If the link layer is PPP, for e.g., > IPv6CP is used. If the link layer is an IPsec tunnel then > IKEv2 configuration payloads are used. The PMIPv6 protocol > does consider this and has some text addressing this. >=20 > Anyway, this discussion needs to happen on the NETLMM > mailing list. >=20 > Vijay >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 13 12:39:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcOo3-0004vJ-Qk; Fri, 13 Apr 2007 12:39:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcOo1-0004uy-Vh for mip6@ietf.org; Fri, 13 Apr 2007 12:39:25 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcOo1-0006nj-E9 for mip6@ietf.org; Fri, 13 Apr 2007 12:39:25 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3DGd1WV000673; Fri, 13 Apr 2007 19:39:18 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 19:38:16 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 11:38:05 -0500 Received: from 172.19.244.151 ([172.19.244.151]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Fri, 13 Apr 2007 16:38:05 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 13 Apr 2007 11:38:38 -0500 Subject: Re: [Mip6] Dynamic HoA assignment From: Basavaraj Patil To: "Chowdhury, Kuntal" , Vijay Devarapalli , Alper Yegin Message-ID: Thread-Topic: [Mip6] Dynamic HoA assignment Thread-Index: Acd9NcVEOlef0945Ssuic9sPQzWBxQAVcnZQABeoJ7g= In-Reply-To: <7CCD07160348804497EF29E9EA5560D7024D9E7E@exchtewks2.starentnetworks.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 13 Apr 2007 16:38:05.0530 (UTC) FILETIME=[1C6133A0:01C77DEA] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070413193919-7E1EABB0-34FB7829/0-0/0-0 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: mip6@ietf.org, heejin.jang@samsung.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Looks like we are diverging on this thread here. Lets try and see if we can come to a conclusion on this topic: - IKEv2 is the preferred approach to obtaining the HoA when IPsec is used to secure the MIP6 signaling messages. With this approach the MN will not need to send a BU with the unspecified address. So we do not have any impact on RFC3775 with this approach while still allowing for dynamic assignment of the HoA. This approach applies to the intergrated scenario bootstrapping solution as well. Hence an MN which obtains only the HA via DHCPv6 SHOULD obtain the HoA via IKEv2 when IPsec is used. - When the BU/BAck are secured as per RFC4285 and the MN needs to be bootstrapped, the MN cannot send a BU to an HA without an HoA (as per current RFC3775 which does not allow the sending of the unspecified address). If the MN is assigned the HoA, the scope of this address being at some remote HA, via DHCPv6, do we need to specify the interaction between the HA and DHCP server (via an intermediary such as AAA as has been suggested in the integrated scenario bootstrapping I-D)? I am not sure if it is sufficient to state that the method by which the HoA is inserted in the DHCP server is out-of-scope good enough. So given the current MIP6 requirement that the BU contain the HoA, there is a need to assign the HoA, possibly via DHCPv6 when RFC4285 mode of operation is assumed. - Now if we change the RFC3775 requirement for requiring the HoA in the BU, do we cause any harm? I mean other then the impact to the current implementations which would be required to process such BU messages. The intent is to allow the MN to send a BU with HoA=0:0 only in the case when IPsec is not used between the MN and HA (i.e 4285 mode). -Raj On 4/13/07 12:22 AM, "ext Chowdhury, Kuntal" wrote: > IPv6CP is used to negotiate the IID only which helps in producing the > link local address. RS/RA or DHCPv6 is used to configure the global > scope address. > > -Kuntal > > >> -----Original Message----- >> From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] >> Sent: Thursday, April 12, 2007 2:07 PM >> To: Alper Yegin >> Cc: mip6@ietf.org; heejin.jang@samsung.com >> Subject: Re: [Mip6] Dynamic HoA assignment >> >> Alper Yegin wrote: >>>> The base PMIPv6 protocol assumes that the home prefix is sent >>>> to the mobile node using a router advertisement and then the >>>> mobile node auto-configures a home address from this prefix. >>> >>> Isn't an IPv6 host in charge of whether it uses address >> autoconfiguration or >>> DHCP? If so, PMIPv6 spec shall accommodate that, assuming it does > not >> want >>> to dictate any particular behaviour on the hosts. >> >> 2461bis says >> >> Router Advertisements (and per-prefix flags) allow routers to > inform >> hosts how to perform Address Autoconfiguration. For example, > routers >> can specify whether hosts should use DHCPv6 and/or >> autonomous (stateless) address configuration. >> >> Stateful address configuration is not mandatory to support. >> RFC 4294 says >> >> Stateful Address Autoconfiguration MAY be supported. >> >> But I do agree DHCPv6 could be used between the mobile node >> and the MAG (Mobile Access Gateway). >> >> However, the address configuration for PMIPv6 depends to a >> large extent on what kind of link layer is used between the >> mobile node and the MAG. If the link layer is PPP, for e.g., >> IPv6CP is used. If the link layer is an IPsec tunnel then >> IKEv2 configuration payloads are used. The PMIPv6 protocol >> does consider this and has some text addressing this. >> >> Anyway, this discussion needs to happen on the NETLMM >> mailing list. >> >> Vijay >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 13 12:56:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcP4k-0006Pl-KS; Fri, 13 Apr 2007 12:56:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcP4k-0006Pf-7P for mip6@ietf.org; Fri, 13 Apr 2007 12:56:42 -0400 Received: from an-out-0708.google.com ([209.85.132.242]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcP4j-0000Yc-PP for mip6@ietf.org; Fri, 13 Apr 2007 12:56:42 -0400 Received: by an-out-0708.google.com with SMTP id d30so1058886and for ; Fri, 13 Apr 2007 09:56:41 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=C8jvfaJYanDSXhA7QC3ydT494sncZ0B7MAnRobzsg8hVIKNeyI5MCSqtJDw6IDVlNpkqIPvjw1vzQbC/Qv5KxQTz3sJbLCYg2u0r3Ciwz1MbWFgUNmfeEEw2kQrA1uA6PlPjl1UcEfq0hdIWGcZji6F2h3jwLD92pBXOgnWYN+k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=f19/siTaC+KxLcH5uwKisq0w7eJ+5RgmQr4By3nHE88142lYPW+xWUjuRpjidNaPncdVTwdZi7Qzmdx1jNDfh66KPm2cfebgBVMmLF+QBXMvBQquBGheorSoQtZK2PDmjvEqoWKYnWA7MfV2Znx/OuzYgAKSgz/mbjDyhm66zys= Received: by 10.100.132.16 with SMTP id f16mr2651670and.1176483401105; Fri, 13 Apr 2007 09:56:41 -0700 (PDT) Received: by 10.100.205.13 with HTTP; Fri, 13 Apr 2007 09:56:41 -0700 (PDT) Message-ID: <729b68be0704130956n1c2233ehf73ea259e83d409d@mail.gmail.com> Date: Fri, 13 Apr 2007 18:56:41 +0200 From: "Jean-Michel Combes" To: "Basavaraj Patil" Subject: Re: [Mip6] Dynamic HoA assignment In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7CCD07160348804497EF29E9EA5560D7024D9E7E@exchtewks2.starentnetworks.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: mip6@ietf.org, heejin.jang@samsung.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi, 2007/4/13, Basavaraj Patil : > [snip] > > - Now if we change the RFC3775 requirement for requiring the HoA in the BU, > do we cause any harm? I mean other then the impact to the current > implementations which would be required to process such BU messages. >From a security point of view, IMHO, there are 2 issues. The first one, which is minor because easily solved, is that an already authenticated MN may flood the HA in requesting plenty of HoA without a heavy security process. The consequences may be (here the draft is not clear) a surcharge of the HA, a flood of BCE (i.e. BC Overflow), etc. To solved this, the HA should allow only a strict number of HoA per MN-ID The second issue is that, normally, security policy (i.e. filtering rules) at the border of an administrative domain (i.e. HA's domain here) should be based on HoA. If the BU has HoA=0::0, the packet should be rejected. Best regards. JMC. > > The intent is to allow the MN to send a BU with HoA=0:0 only in the case > when IPsec is not used between the MN and HA (i.e 4285 mode). > > -Raj > > > > > On 4/13/07 12:22 AM, "ext Chowdhury, Kuntal" > wrote: > > > IPv6CP is used to negotiate the IID only which helps in producing the > > link local address. RS/RA or DHCPv6 is used to configure the global > > scope address. > > > > -Kuntal > > > > > >> -----Original Message----- > >> From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > >> Sent: Thursday, April 12, 2007 2:07 PM > >> To: Alper Yegin > >> Cc: mip6@ietf.org; heejin.jang@samsung.com > >> Subject: Re: [Mip6] Dynamic HoA assignment > >> > >> Alper Yegin wrote: > >>>> The base PMIPv6 protocol assumes that the home prefix is sent > >>>> to the mobile node using a router advertisement and then the > >>>> mobile node auto-configures a home address from this prefix. > >>> > >>> Isn't an IPv6 host in charge of whether it uses address > >> autoconfiguration or > >>> DHCP? If so, PMIPv6 spec shall accommodate that, assuming it does > > not > >> want > >>> to dictate any particular behaviour on the hosts. > >> > >> 2461bis says > >> > >> Router Advertisements (and per-prefix flags) allow routers to > > inform > >> hosts how to perform Address Autoconfiguration. For example, > > routers > >> can specify whether hosts should use DHCPv6 and/or > >> autonomous (stateless) address configuration. > >> > >> Stateful address configuration is not mandatory to support. > >> RFC 4294 says > >> > >> Stateful Address Autoconfiguration MAY be supported. > >> > >> But I do agree DHCPv6 could be used between the mobile node > >> and the MAG (Mobile Access Gateway). > >> > >> However, the address configuration for PMIPv6 depends to a > >> large extent on what kind of link layer is used between the > >> mobile node and the MAG. If the link layer is PPP, for e.g., > >> IPv6CP is used. If the link layer is an IPsec tunnel then > >> IKEv2 configuration payloads are used. The PMIPv6 protocol > >> does consider this and has some text addressing this. > >> > >> Anyway, this discussion needs to happen on the NETLMM > >> mailing list. > >> > >> Vijay > >> > >> _______________________________________________ > >> Mip6 mailing list > >> Mip6@ietf.org > >> https://www1.ietf.org/mailman/listinfo/mip6 > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 13 13:02:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcPAQ-0002SO-MB; Fri, 13 Apr 2007 13:02:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcPAP-0002PK-E2 for mip6@ietf.org; Fri, 13 Apr 2007 13:02:33 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcPAN-0002tp-DW for mip6@ietf.org; Fri, 13 Apr 2007 13:02:33 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l3DH2Ta05218; Fri, 13 Apr 2007 17:02:29 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Dynamic HoA assignment Date: Fri, 13 Apr 2007 12:02:25 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60B5F6AF7@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Dynamic HoA assignment thread-index: Acd9NcVEOlef0945Ssuic9sPQzWBxQAVcnZQABeoJ7gAAJFoQA== From: "Mohamed Khalil" To: "Basavaraj Patil" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Raj, I believe we should allow MN to send a BU with HoA=3D0:0 only in the = case when IPsec is not used between the MN and HA (i.e 4285 mode). The HA when receives a request for HoA assignment it can use DHCP, AAA, or static configuration of a set of addresses to allocate an IP address for the MN. -----Original Message----- From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com]=20 Sent: Friday, April 13, 2007 11:39 AM To: Chowdhury, Kuntal; Vijay Devarapalli; Alper Yegin Cc: mip6@ietf.org; heejin.jang@samsung.com Subject: Re: [Mip6] Dynamic HoA assignment Looks like we are diverging on this thread here. Lets try and see if we can come to a conclusion on this topic: - IKEv2 is the preferred approach to obtaining the HoA when IPsec is used to secure the MIP6 signaling messages. With this approach the MN will not need to send a BU with the unspecified address. So we do not have any impact on RFC3775 with this approach while still allowing for dynamic assignment of the HoA.=20 This approach applies to the intergrated scenario bootstrapping solution as well. Hence an MN which obtains only the HA via DHCPv6 SHOULD obtain the HoA via IKEv2 when IPsec is used. - When the BU/BAck are secured as per RFC4285 and the MN needs to be bootstrapped, the MN cannot send a BU to an HA without an HoA (as per current RFC3775 which does not allow the sending of the unspecified address). If the MN is assigned the HoA, the scope of this address being at some remote HA, via DHCPv6, do we need to specify the interaction between the HA and DHCP server (via an intermediary such as AAA as has been suggested in the integrated scenario bootstrapping I-D)? I am not sure if it is sufficient to state that the method by which the HoA is inserted in the DHCP server is out-of-scope good enough. So given the current MIP6 requirement that the BU contain the HoA, there is a need to assign the HoA, possibly via DHCPv6 when RFC4285 mode of operation is assumed. - Now if we change the RFC3775 requirement for requiring the HoA in the BU, do we cause any harm? I mean other then the impact to the current implementations which would be required to process such BU messages. The intent is to allow the MN to send a BU with HoA=3D0:0 only in the = case when IPsec is not used between the MN and HA (i.e 4285 mode). -Raj On 4/13/07 12:22 AM, "ext Chowdhury, Kuntal" wrote: > IPv6CP is used to negotiate the IID only which helps in producing the=20 > link local address. RS/RA or DHCPv6 is used to configure the global=20 > scope address. >=20 > -Kuntal >=20 >=20 >> -----Original Message----- >> From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] >> Sent: Thursday, April 12, 2007 2:07 PM >> To: Alper Yegin >> Cc: mip6@ietf.org; heejin.jang@samsung.com >> Subject: Re: [Mip6] Dynamic HoA assignment >>=20 >> Alper Yegin wrote: >>>> The base PMIPv6 protocol assumes that the home prefix is sent to=20 >>>> the mobile node using a router advertisement and then the mobile=20 >>>> node auto-configures a home address from this prefix. >>>=20 >>> Isn't an IPv6 host in charge of whether it uses address >> autoconfiguration or >>> DHCP? If so, PMIPv6 spec shall accommodate that, assuming it does > not >> want >>> to dictate any particular behaviour on the hosts. >>=20 >> 2461bis says >>=20 >> Router Advertisements (and per-prefix flags) allow routers to > inform >> hosts how to perform Address Autoconfiguration. For example, > routers >> can specify whether hosts should use DHCPv6 and/or >> autonomous (stateless) address configuration. >>=20 >> Stateful address configuration is not mandatory to support. RFC 4294=20 >> says >>=20 >> Stateful Address Autoconfiguration MAY be supported. >>=20 >> But I do agree DHCPv6 could be used between the mobile node and the=20 >> MAG (Mobile Access Gateway). >>=20 >> However, the address configuration for PMIPv6 depends to a large=20 >> extent on what kind of link layer is used between the mobile node and >> the MAG. If the link layer is PPP, for e.g., IPv6CP is used. If the=20 >> link layer is an IPsec tunnel then IKEv2 configuration payloads are=20 >> used. The PMIPv6 protocol does consider this and has some text=20 >> addressing this. >>=20 >> Anyway, this discussion needs to happen on the NETLMM mailing list. >>=20 >> Vijay >>=20 >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 13 13:21:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcPSN-00069V-0q; Fri, 13 Apr 2007 13:21:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcPSL-00069O-Ix for mip6@ietf.org; Fri, 13 Apr 2007 13:21:05 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcPSK-0002pj-GR for mip6@ietf.org; Fri, 13 Apr 2007 13:21:05 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3DHKdwt008890; Fri, 13 Apr 2007 20:20:56 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 20:20:53 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 12:20:44 -0500 Received: from 172.19.244.151 ([172.19.244.151]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Fri, 13 Apr 2007 17:20:43 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 13 Apr 2007 12:21:17 -0500 Subject: Re: [Mip6] Dynamic HoA assignment From: Basavaraj Patil To: ext Jean-Michel Combes Message-ID: Thread-Topic: [Mip6] Dynamic HoA assignment Thread-Index: Acd98CUEY5W1TOnjEduLRAARJNUNiA== In-Reply-To: <729b68be0704130956n1c2233ehf73ea259e83d409d@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 13 Apr 2007 17:20:44.0280 (UTC) FILETIME=[11837780:01C77DF0] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: mip6@ietf.org, heejin.jang@samsung.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Jean, On 4/13/07 11:56 AM, "ext Jean-Michel Combes" wrote: > Hi, > > 2007/4/13, Basavaraj Patil : >> > > [snip] > >> >> - Now if we change the RFC3775 requirement for requiring the HoA in the BU, >> do we cause any harm? I mean other then the impact to the current >> implementations which would be required to process such BU messages. > > From a security point of view, IMHO, there are 2 issues. > > The first one, which is minor because easily solved, is that an > already authenticated MN may flood the HA in requesting plenty of HoA > without a heavy security process. The consequences may be (here the > draft is not clear) a surcharge of the HA, a flood of BCE (i.e. BC > Overflow), etc. > To solved this, the HA should allow only a strict number of HoA per MN-ID I guess this is not really a new issue. Every BU with a request for an HoA would have to authenticate itself. And then it is up to the HA to have some policy to deal with it. > > The second issue is that, normally, security policy (i.e. filtering > rules) at the border of an administrative domain (i.e. HA's domain > here) should be based on HoA. If the BU has HoA=0::0, the packet > should be rejected. I don't know if that is how the firewall rules would be. -Raj > > Best regards. > > JMC. > >> >> The intent is to allow the MN to send a BU with HoA=0:0 only in the case >> when IPsec is not used between the MN and HA (i.e 4285 mode). >> >> -Raj >> >> >> >> >> On 4/13/07 12:22 AM, "ext Chowdhury, Kuntal" >> wrote: >> >>> IPv6CP is used to negotiate the IID only which helps in producing the >>> link local address. RS/RA or DHCPv6 is used to configure the global >>> scope address. >>> >>> -Kuntal >>> >>> >>>> -----Original Message----- >>>> From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] >>>> Sent: Thursday, April 12, 2007 2:07 PM >>>> To: Alper Yegin >>>> Cc: mip6@ietf.org; heejin.jang@samsung.com >>>> Subject: Re: [Mip6] Dynamic HoA assignment >>>> >>>> Alper Yegin wrote: >>>>>> The base PMIPv6 protocol assumes that the home prefix is sent >>>>>> to the mobile node using a router advertisement and then the >>>>>> mobile node auto-configures a home address from this prefix. >>>>> >>>>> Isn't an IPv6 host in charge of whether it uses address >>>> autoconfiguration or >>>>> DHCP? If so, PMIPv6 spec shall accommodate that, assuming it does >>> not >>>> want >>>>> to dictate any particular behaviour on the hosts. >>>> >>>> 2461bis says >>>> >>>> Router Advertisements (and per-prefix flags) allow routers to >>> inform >>>> hosts how to perform Address Autoconfiguration. For example, >>> routers >>>> can specify whether hosts should use DHCPv6 and/or >>>> autonomous (stateless) address configuration. >>>> >>>> Stateful address configuration is not mandatory to support. >>>> RFC 4294 says >>>> >>>> Stateful Address Autoconfiguration MAY be supported. >>>> >>>> But I do agree DHCPv6 could be used between the mobile node >>>> and the MAG (Mobile Access Gateway). >>>> >>>> However, the address configuration for PMIPv6 depends to a >>>> large extent on what kind of link layer is used between the >>>> mobile node and the MAG. If the link layer is PPP, for e.g., >>>> IPv6CP is used. If the link layer is an IPsec tunnel then >>>> IKEv2 configuration payloads are used. The PMIPv6 protocol >>>> does consider this and has some text addressing this. >>>> >>>> Anyway, this discussion needs to happen on the NETLMM >>>> mailing list. >>>> >>>> Vijay >>>> >>>> _______________________________________________ >>>> Mip6 mailing list >>>> Mip6@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/mip6 >>> >>> _______________________________________________ >>> Mip6 mailing list >>> Mip6@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mip6 >> >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 >> _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 13 15:35:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcRYb-0005CW-V7; Fri, 13 Apr 2007 15:35:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcRYa-0005CQ-SG for mip6@ietf.org; Fri, 13 Apr 2007 15:35:40 -0400 Received: from ceiling.dave.sonera.fi ([131.177.130.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcRYX-0007Hk-AS for mip6@ietf.org; Fri, 13 Apr 2007 15:35:40 -0400 Received: from ceiling.dave.sonera.fi (localhost [127.0.0.1]) by ceiling.dave.sonera.fi (Sendmail) with ESMTP id l3DJZX6A017981 for ; Fri, 13 Apr 2007 22:35:33 +0300 (EEST) Received: from [131.177.101.100] ([131.177.101.100]) by ceiling.dave.sonera.fi (Sendmail) with ESMTP id l3DJZRxj017972; Fri, 13 Apr 2007 22:35:30 +0300 (EEST) From: jouni.korhonen@teliasonera.com To: "Jean-Michel Combes" Subject: VS: Re: [Mip6] Dynamic HoA assignment Date: Fri, 13 Apr 2007 22:35:26 +0300 Message-ID: <4y2ZYtbDmbK5.1MhSgY2V@smtp.dave.sonera.fi> X-Mailer: EPOC Email Version 2.10 MIME-Version: 1.0 Content-Language: i-default Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.2 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: mip6@ietf.org, heejin.jang@samsung.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jouni.korhonen@teliasonera.com List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Jean, I doubt the the fw rules (or other filtering) would be based on HoA, at = least not for BUs. Of course it is up to the operator's deployment but I = would not generalize.. /jouni [snip] The second issue is that, normally, security policy (i.e. filtering rules) at the border of an administrative domain (i.e. HA's domain here) should be based on HoA. If the BU has HoA=3D0::0, the packet should be rejected. Best regards. JMC. > > The intent is to allow the MN to send a BU with HoA=3D0:0 only in the = case > when IPsec is not used between the MN and HA (i.e 4285 mode). > > -Raj > > > > > On 4/13/07 12:22 AM, "ext Chowdhury, Kuntal" > wrote: > > > IPv6CP is used to negotiate the IID only which helps in producing = the > > link local address. RS/RA or DHCPv6 is used to configure the = global > > scope address. > > > > -Kuntal > > > > > >> -----Original Message----- > >> From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > >> Sent: Thursday, April 12, 2007 2:07 PM > >> To: Alper Yegin > >> Cc: mip6@ietf.org; heejin.jang@samsung.com > >> Subject: Re: [Mip6] Dynamic HoA assignment > >> > >> Alper Yegin wrote: > >>>> The base PMIPv6 protocol assumes that the home prefix is sent > >>>> to the mobile node using a router advertisement and then the > >>>> mobile node auto-configures a home address from this prefix. > >>> > >>> Isn't an IPv6 host in charge of whether it uses address > >> autoconfiguration or > >>> DHCP? If so, PMIPv6 spec shall accommodate that, assuming it = does > > not > >> want > >>> to dictate any particular behaviour on the hosts. > >> > >> 2461bis says > >> > >> Router Advertisements (and per-prefix flags) allow routers = to > > inform > >> hosts how to perform Address Autoconfiguration. For = example, > > routers > >> can specify whether hosts should use DHCPv6 and/or > >> autonomous (stateless) address configuration. > >> > >> Stateful address configuration is not mandatory to support. > >> RFC 4294 says > >> > >> Stateful Address Autoconfiguration MAY be supported. > >> > >> But I do agree DHCPv6 could be used between the mobile node > >> and the MAG (Mobile Access Gateway). > >> > >> However, the address configuration for PMIPv6 depends to a > >> large extent on what kind of link layer is used between the > >> mobile node and the MAG. If the link layer is PPP, for e.g., > >> IPv6CP is used. If the link layer is an IPsec tunnel then > >> IKEv2 configuration payloads are used. The PMIPv6 protocol > >> does consider this and has some text addressing this. > >> > >> Anyway, this discussion needs to happen on the NETLMM > >> mailing list. > >> > >> Vijay > >> > >> _______________________________________________ > >> Mip6 mailing list > >> Mip6@ietf.org > >> https://www1.ietf.org/mailman/listinfo/mip6 > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Apr 15 21:19:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdFsd-0008BS-Up; Sun, 15 Apr 2007 21:19:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdFsc-0008BE-Mz for mip6@ietf.org; Sun, 15 Apr 2007 21:19:42 -0400 Received: from yskfw1.ysknet.co.jp ([210.169.255.3] helo=ksns.ks.ysknet.co.jp) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HdFsb-0003lS-21 for mip6@ietf.org; Sun, 15 Apr 2007 21:19:42 -0400 Received: (qmail 31997 invoked from network); 16 Apr 2007 10:19:38 +0900 Received: from (HELO MIP6-236) (@) by with SMTP; 16 Apr 2007 10:19:38 +0900 To: mip6@ietf.org, nemo@ietf.org From: "K.Kawaguchi" Message-Id: <200704160957.CFI56707.XVJBBLHU@ysknet.co.jp> X-Mailer: Winbiff [Version 2.43 PL1] X-Accept-Language: ja,en Date: Mon, 16 Apr 2007 10:19:35 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Subject: [Mip6] [Reminder] The 9th TAHI IPv6 Interoperability Test Event !! X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Dear all, This is a reminder for the 9th TAHI IPv6 Interoperability Test Event. As you know, TAHI Project is planning to hold the 9th TAHI IPv6 Interoperability Test Event at 14th - 18th May, 2007. You can make a registration on http://www.tahi.org/inop/9thinterop.html And you can also get the detailed information about the event. The registration deadline is at 17:00 on Friday, 27th Apr. Please make a registration as soon as possible, if you are planning to participate to the event. We are looking forward to see you at the 9th TAHI event! Thanks, Best regards --- Kiyoaki KAWAGUCHI _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 16 06:14:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdODh-0004DP-J5; Mon, 16 Apr 2007 06:14:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdODh-0004DK-0X for mip6@ietf.org; Mon, 16 Apr 2007 06:14:01 -0400 Received: from an-out-0708.google.com ([209.85.132.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdODf-0006HU-LG for mip6@ietf.org; Mon, 16 Apr 2007 06:14:00 -0400 Received: by an-out-0708.google.com with SMTP id d30so1806957and for ; Mon, 16 Apr 2007 03:13:59 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=sO/gcY9u5q6tuGLhzw7O68GTglkc8jZ7AeoEoWwkcODYSkF3/+038u2ki5bSc+RRY+N2YoZ5qg22cM64UVbOmCTpev0w7AAE6802UhXqd4XR0NNyk5ePWOSkE73/Sb0dqh74C+elj9RJKZmVXhTm+kB0c73pXiMavOzniGk7XSE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=OlqhIOgyhkQFa1M2+la2fZBd6ywHcpt93teOv1P7SuhBVZEIIUmdELxdcm0LF8d6HV2WlSLaxQv5fc7hNHjoqI1CE1I8rfYLHJwn7MrK0BV1EoPsJf5CF9InlbRDH5bmbmQR8ZKPq2R7oSXENqAx9rlNtSCgajXajmCjUD/ImWU= Received: by 10.100.190.8 with SMTP id n8mr4334394anf.1176718439188; Mon, 16 Apr 2007 03:13:59 -0700 (PDT) Received: by 10.100.205.13 with HTTP; Mon, 16 Apr 2007 03:13:59 -0700 (PDT) Message-ID: <729b68be0704160313y4f71a582tfa41d2779dc21ede@mail.gmail.com> Date: Mon, 16 Apr 2007 12:13:59 +0200 From: "Jean-Michel Combes" To: "Basavaraj Patil" Subject: Re: [Mip6] Dynamic HoA assignment In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <729b68be0704130956n1c2233ehf73ea259e83d409d@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: mip6@ietf.org, heejin.jang@samsung.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Raj, 2007/4/13, Basavaraj Patil : > > Hi Jean, s/Jean/Jean-Michel ;) > > > On 4/13/07 11:56 AM, "ext Jean-Michel Combes" > wrote: > > > Hi, > > > > 2007/4/13, Basavaraj Patil : > >> > > > > [snip] > > > >> > >> - Now if we change the RFC3775 requirement for requiring the HoA in the BU, > >> do we cause any harm? I mean other then the impact to the current > >> implementations which would be required to process such BU messages. > > > > From a security point of view, IMHO, there are 2 issues. > > > > The first one, which is minor because easily solved, is that an > > already authenticated MN may flood the HA in requesting plenty of HoA > > without a heavy security process. The consequences may be (here the > > draft is not clear) a surcharge of the HA, a flood of BCE (i.e. BC > > Overflow), etc. > > To solved this, the HA should allow only a strict number of HoA per MN-ID > > I guess this is not really a new issue. > Every BU with a request for an HoA would have to authenticate itself. I agree but the security is lighter than a IKEv2 process, so the attack is easier. > And > then it is up to the HA to have some policy to deal with it. I agree of course. That's why I said this is a minor issue :) Best regards. JMC. > > > > > The second issue is that, normally, security policy (i.e. filtering > > rules) at the border of an administrative domain (i.e. HA's domain > > here) should be based on HoA. If the BU has HoA=0::0, the packet > > should be rejected. > > I don't know if that is how the firewall rules would be. > > -Raj > > > > > Best regards. > > > > JMC. > > > >> > >> The intent is to allow the MN to send a BU with HoA=0:0 only in the case > >> when IPsec is not used between the MN and HA (i.e 4285 mode). > >> > >> -Raj > >> > >> > >> > >> > >> On 4/13/07 12:22 AM, "ext Chowdhury, Kuntal" > >> wrote: > >> > >>> IPv6CP is used to negotiate the IID only which helps in producing the > >>> link local address. RS/RA or DHCPv6 is used to configure the global > >>> scope address. > >>> > >>> -Kuntal > >>> > >>> > >>>> -----Original Message----- > >>>> From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > >>>> Sent: Thursday, April 12, 2007 2:07 PM > >>>> To: Alper Yegin > >>>> Cc: mip6@ietf.org; heejin.jang@samsung.com > >>>> Subject: Re: [Mip6] Dynamic HoA assignment > >>>> > >>>> Alper Yegin wrote: > >>>>>> The base PMIPv6 protocol assumes that the home prefix is sent > >>>>>> to the mobile node using a router advertisement and then the > >>>>>> mobile node auto-configures a home address from this prefix. > >>>>> > >>>>> Isn't an IPv6 host in charge of whether it uses address > >>>> autoconfiguration or > >>>>> DHCP? If so, PMIPv6 spec shall accommodate that, assuming it does > >>> not > >>>> want > >>>>> to dictate any particular behaviour on the hosts. > >>>> > >>>> 2461bis says > >>>> > >>>> Router Advertisements (and per-prefix flags) allow routers to > >>> inform > >>>> hosts how to perform Address Autoconfiguration. For example, > >>> routers > >>>> can specify whether hosts should use DHCPv6 and/or > >>>> autonomous (stateless) address configuration. > >>>> > >>>> Stateful address configuration is not mandatory to support. > >>>> RFC 4294 says > >>>> > >>>> Stateful Address Autoconfiguration MAY be supported. > >>>> > >>>> But I do agree DHCPv6 could be used between the mobile node > >>>> and the MAG (Mobile Access Gateway). > >>>> > >>>> However, the address configuration for PMIPv6 depends to a > >>>> large extent on what kind of link layer is used between the > >>>> mobile node and the MAG. If the link layer is PPP, for e.g., > >>>> IPv6CP is used. If the link layer is an IPsec tunnel then > >>>> IKEv2 configuration payloads are used. The PMIPv6 protocol > >>>> does consider this and has some text addressing this. > >>>> > >>>> Anyway, this discussion needs to happen on the NETLMM > >>>> mailing list. > >>>> > >>>> Vijay > >>>> > >>>> _______________________________________________ > >>>> Mip6 mailing list > >>>> Mip6@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/mip6 > >>> > >>> _______________________________________________ > >>> Mip6 mailing list > >>> Mip6@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/mip6 > >> > >> > >> _______________________________________________ > >> Mip6 mailing list > >> Mip6@ietf.org > >> https://www1.ietf.org/mailman/listinfo/mip6 > >> > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 16 06:22:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdOLo-00079b-75; Mon, 16 Apr 2007 06:22:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdOLm-00079W-UM for mip6@ietf.org; Mon, 16 Apr 2007 06:22:22 -0400 Received: from an-out-0708.google.com ([209.85.132.249]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdOLm-0000Er-K8 for mip6@ietf.org; Mon, 16 Apr 2007 06:22:22 -0400 Received: by an-out-0708.google.com with SMTP id d30so1809587and for ; Mon, 16 Apr 2007 03:22:22 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=aaaXUiPoLRd/+IFIgpJn2PwsWJBoNqJlM/Vo66q1oeuAqW4rV7rsU6p0P+1AqAqSeVE1b2uPntWWy0HLfOQyZBvDPAGLnKpejekPbZk5eeXyM2FOHHMc80g2eM643mpo6Ai7HpW6rLXHc3W5B5RK+irLHtorbzKd6pc0EHPmME0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=DFPY6Uvpa/+N2ttzIFcCSvdF1tfslKqb4Ai4vluwDZb/6dU+scMBxX90zbDrQ2QR+bWIFFbgGAmmrc0Xki2pILe8ZGJm0dxEA9k+KV7IDC3eBGpR6Kk/v2O+TT2NcRFFgYk1tcMgUWN4Aq119lYwWcEA4YN0FJfxe4AF+xVajs0= Received: by 10.100.44.13 with SMTP id r13mr4347259anr.1176718942343; Mon, 16 Apr 2007 03:22:22 -0700 (PDT) Received: by 10.100.205.13 with HTTP; Mon, 16 Apr 2007 03:22:22 -0700 (PDT) Message-ID: <729b68be0704160322v41cd1811xce222715ae50513d@mail.gmail.com> Date: Mon, 16 Apr 2007 12:22:22 +0200 From: "Jean-Michel Combes" To: jouni.korhonen@teliasonera.com Subject: Re: VS: Re: [Mip6] Dynamic HoA assignment In-Reply-To: <4y2ZYtbDmbK5.1MhSgY2V@smtp.dave.sonera.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4y2ZYtbDmbK5.1MhSgY2V@smtp.dave.sonera.fi> X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: mip6@ietf.org, heejin.jang@samsung.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Jouni, 2007/4/13, jouni.korhonen@teliasonera.com : > Hi Jean, > > I doubt the the fw rules (or other filtering) would be based on HoA, Why not? IMHO, this is the more logical: - the HoA is the more 'permanent' IP address for a MN which is needed for the stateful function of a FW - the HoA is owned by the operator and so the security administrator is aware of them and can set up the security policy easily - the MIPv6 aware FWs I have tested work with HoA policy based > at least not for BUs. Of course it is up to the operator's deployment but I would not generalize.. I agree on this point. But this is just an advertisement in the case where security policy would be based on HoAs. Best regards. JMC. > > /jouni > > [snip] > > The second issue is that, normally, security policy (i.e. filtering > rules) at the border of an administrative domain (i.e. HA's domain > here) should be based on HoA. If the BU has HoA=0::0, the packet > should be rejected. > > Best regards. > > JMC. > > > > > The intent is to allow the MN to send a BU with HoA=0:0 only in the case > > when IPsec is not used between the MN and HA (i.e 4285 mode). > > > > -Raj > > > > > > > > > > On 4/13/07 12:22 AM, "ext Chowdhury, Kuntal" > > wrote: > > > > > IPv6CP is used to negotiate the IID only which helps in producing the > > > link local address. RS/RA or DHCPv6 is used to configure the global > > > scope address. > > > > > > -Kuntal > > > > > > > > >> -----Original Message----- > > >> From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > > >> Sent: Thursday, April 12, 2007 2:07 PM > > >> To: Alper Yegin > > >> Cc: mip6@ietf.org; heejin.jang@samsung.com > > >> Subject: Re: [Mip6] Dynamic HoA assignment > > >> > > >> Alper Yegin wrote: > > >>>> The base PMIPv6 protocol assumes that the home prefix is sent > > >>>> to the mobile node using a router advertisement and then the > > >>>> mobile node auto-configures a home address from this prefix. > > >>> > > >>> Isn't an IPv6 host in charge of whether it uses address > > >> autoconfiguration or > > >>> DHCP? If so, PMIPv6 spec shall accommodate that, assuming it does > > > not > > >> want > > >>> to dictate any particular behaviour on the hosts. > > >> > > >> 2461bis says > > >> > > >> Router Advertisements (and per-prefix flags) allow routers to > > > inform > > >> hosts how to perform Address Autoconfiguration. For example, > > > routers > > >> can specify whether hosts should use DHCPv6 and/or > > >> autonomous (stateless) address configuration. > > >> > > >> Stateful address configuration is not mandatory to support. > > >> RFC 4294 says > > >> > > >> Stateful Address Autoconfiguration MAY be supported. > > >> > > >> But I do agree DHCPv6 could be used between the mobile node > > >> and the MAG (Mobile Access Gateway). > > >> > > >> However, the address configuration for PMIPv6 depends to a > > >> large extent on what kind of link layer is used between the > > >> mobile node and the MAG. If the link layer is PPP, for e.g., > > >> IPv6CP is used. If the link layer is an IPsec tunnel then > > >> IKEv2 configuration payloads are used. The PMIPv6 protocol > > >> does consider this and has some text addressing this. > > >> > > >> Anyway, this discussion needs to happen on the NETLMM > > >> mailing list. > > >> > > >> Vijay > > >> > > >> _______________________________________________ > > >> Mip6 mailing list > > >> Mip6@ietf.org > > >> https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > _______________________________________________ > > > Mip6 mailing list > > > Mip6@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 16 15:20:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdWkK-0004IF-3n; Mon, 16 Apr 2007 15:20:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdWkI-0004I7-St for mip6@ietf.org; Mon, 16 Apr 2007 15:20:14 -0400 Received: from web84112.mail.mud.yahoo.com ([68.142.206.199]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HdWkI-0004zo-5A for mip6@ietf.org; Mon, 16 Apr 2007 15:20:14 -0400 Received: (qmail 5092 invoked by uid 60001); 16 Apr 2007 19:20:13 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=KaJ1AExv/rfU7FUOXmamGlznDrUOyAYU5YSdkYseGyAbShmvIOAmKmT09HVTgRuUHWRgRxpRyuWRmcN8r0WL8V7pzR7yP21XEUg65Z0tZAuWFke3iMys8r+wDVUFgAa+qrgSxAhaOJyfis/JnREExW5dIoHmD7H45EDABFH9x/o=; X-YMail-OSG: eCmUatMVM1kwdXdUbLKuDajYYAAFQFM1N5GtN6u0c_F2OeR.1SEEGCuEI4hHrhnpLEqz8UC2UfpIxQHVCy2dEkOZ6fu3SabD2wvD_Ltpp6KENc8Bt6M- Received: from [206.16.17.212] by web84112.mail.mud.yahoo.com via HTTP; Mon, 16 Apr 2007 12:20:13 PDT X-Mailer: YahooMailRC/478 YahooMailWebService/0.7.41.10 Date: Mon, 16 Apr 2007 12:20:13 -0700 (PDT) From: Behcet Sarikaya Subject: Re: VS: Re: [Mip6] Dynamic HoA assignment To: Jean-Michel Combes MIME-Version: 1.0 Message-ID: <588112.1618.qm@web84112.mail.mud.yahoo.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Behcet Sarikaya List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1354100523==" Errors-To: mip6-bounces@ietf.org --===============1354100523== Content-Type: multipart/alternative; boundary="0-1803777546-1176751213=:1618" --0-1803777546-1176751213=:1618 Content-Type: text/plain; charset=ascii Jean-Michel, it is good to hear that MIP6 is being deployed in Europe. Regards, Behcet ----- Original Message ---- From: Jean-Michel Combes To: jouni.korhonen@teliasonera.com Cc: mip6@ietf.org; heejin.jang@samsung.com Sent: Monday, April 16, 2007 5:22:22 AM Subject: Re: VS: Re: [Mip6] Dynamic HoA assignment Hi Jouni, 2007/4/13, jouni.korhonen@teliasonera.com : > Hi Jean, > > I doubt the the fw rules (or other filtering) would be based on HoA, Why not? IMHO, this is the more logical: - the HoA is the more 'permanent' IP address for a MN which is needed for the stateful function of a FW - the HoA is owned by the operator and so the security administrator is aware of them and can set up the security policy easily - the MIPv6 aware FWs I have tested work with HoA policy based > at least not for BUs. Of course it is up to the operator's deployment but I would not generalize.. I agree on this point. But this is just an advertisement in the case where security policy would be based on HoAs. Best regards. JMC. > > /jouni > > [snip] > > The second issue is that, normally, security policy (i.e. filtering > rules) at the border of an administrative domain (i.e. HA's domain > here) should be based on HoA. If the BU has HoA=0::0, the packet > should be rejected. > > Best regards. > > JMC. > > > > > The intent is to allow the MN to send a BU with HoA=0:0 only in the case > > when IPsec is not used between the MN and HA (i.e 4285 mode). > > > > -Raj > > > > > > > > > > On 4/13/07 12:22 AM, "ext Chowdhury, Kuntal" > > wrote: > > > > > IPv6CP is used to negotiate the IID only which helps in producing the > > > link local address. RS/RA or DHCPv6 is used to configure the global > > > scope address. > > > > > > -Kuntal > > > > > > > > >> -----Original Message----- > > >> From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > > >> Sent: Thursday, April 12, 2007 2:07 PM > > >> To: Alper Yegin > > >> Cc: mip6@ietf.org; heejin.jang@samsung.com > > >> Subject: Re: [Mip6] Dynamic HoA assignment > > >> > > >> Alper Yegin wrote: > > >>>> The base PMIPv6 protocol assumes that the home prefix is sent > > >>>> to the mobile node using a router advertisement and then the > > >>>> mobile node auto-configures a home address from this prefix. > > >>> > > >>> Isn't an IPv6 host in charge of whether it uses address > > >> autoconfiguration or > > >>> DHCP? If so, PMIPv6 spec shall accommodate that, assuming it does > > > not > > >> want > > >>> to dictate any particular behaviour on the hosts. > > >> > > >> 2461bis says > > >> > > >> Router Advertisements (and per-prefix flags) allow routers to > > > inform > > >> hosts how to perform Address Autoconfiguration. For example, > > > routers > > >> can specify whether hosts should use DHCPv6 and/or > > >> autonomous (stateless) address configuration. > > >> > > >> Stateful address configuration is not mandatory to support. > > >> RFC 4294 says > > >> > > >> Stateful Address Autoconfiguration MAY be supported. > > >> > > >> But I do agree DHCPv6 could be used between the mobile node > > >> and the MAG (Mobile Access Gateway). > > >> > > >> However, the address configuration for PMIPv6 depends to a > > >> large extent on what kind of link layer is used between the > > >> mobile node and the MAG. If the link layer is PPP, for e.g., > > >> IPv6CP is used. If the link layer is an IPsec tunnel then > > >> IKEv2 configuration payloads are used. The PMIPv6 protocol > > >> does consider this and has some text addressing this. > > >> > > >> Anyway, this discussion needs to happen on the NETLMM > > >> mailing list. > > >> > > >> Vijay > > >> > > >> _______________________________________________ > > >> Mip6 mailing list > > >> Mip6@ietf.org > > >> https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > _______________________________________________ > > > Mip6 mailing list > > > Mip6@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --0-1803777546-1176751213=:1618 Content-Type: text/html; charset=ascii
Jean-Michel, it is good to hear that MIP6 is being deployed in Europe.
 
Regards,
 
Behcet

----- Original Message ----
From: Jean-Michel Combes <jeanmichel.combes@gmail.com>
To: jouni.korhonen@teliasonera.com
Cc: mip6@ietf.org; heejin.jang@samsung.com
Sent: Monday, April 16, 2007 5:22:22 AM
Subject: Re: VS: Re: [Mip6] Dynamic HoA assignment

Hi Jouni,

2007/4/13, jouni.korhonen@teliasonera.com <jouni.korhonen@teliasonera.com>:
> Hi Jean,
>
> I doubt the the fw rules (or other filtering) would be based on HoA,

Why not?
IMHO, this is the more logical:
- the HoA is the more 'permanent' IP address for a MN which is needed
for the stateful function of a FW
- the HoA is owned by the operator and so the security administrator
is aware of them and can set up the security policy easily
- the MIPv6 aware FWs I have tested work with HoA policy based

>  at least not for BUs. Of course it is up to the operator's deployment but I would not generalize..

I agree on this point. But this is just an advertisement in the case
where security policy would be based on HoAs.

Best regards.

JMC.

>
> /jouni
>
> [snip]
>
> The second issue is that, normally, security policy (i.e. filtering
> rules) at the border of an  administrative domain (i.e. HA's domain
> here) should be based on HoA. If the BU has HoA=0::0, the packet
> should be rejected.
>
> Best regards.
>
> JMC.
>
> >
> > The intent is to allow the MN to send a BU with HoA=0:0 only in the case
> > when IPsec is not used between the MN and HA (i.e 4285 mode).
> >
> > -Raj
> >
> >
> >
> >
> > On 4/13/07 12:22 AM, "ext Chowdhury, Kuntal"
> > <kchowdhury@starentnetworks.com> wrote:
> >
> > > IPv6CP is used to negotiate the IID only which helps in producing the
> > > link local address. RS/RA or DHCPv6 is used to configure the global
> > > scope address.
> > >
> > > -Kuntal
> > >
> > >
> > >> -----Original Message-----
> > >> From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com]
> > >> Sent: Thursday, April 12, 2007 2:07 PM
> > >> To: Alper Yegin
> > >> Cc: mip6@ietf.org; heejin.jang@samsung.com
> > >> Subject: Re: [Mip6] Dynamic HoA assignment
> > >>
> > >> Alper Yegin wrote:
> > >>>> The base PMIPv6 protocol assumes that the home prefix is sent
> > >>>> to the mobile node using a router advertisement and then the
> > >>>> mobile node auto-configures a home address from this prefix.
> > >>>
> > >>> Isn't an IPv6 host in charge of whether it uses address
> > >> autoconfiguration or
> > >>> DHCP? If so, PMIPv6 spec shall accommodate that, assuming it does
> > > not
> > >> want
> > >>> to dictate any particular behaviour on the hosts.
> > >>
> > >> 2461bis says
> > >>
> > >>     Router Advertisements (and per-prefix flags) allow routers to
> > > inform
> > >>     hosts how to perform Address Autoconfiguration.  For example,
> > > routers
> > >>     can specify whether hosts should use DHCPv6 and/or
> > >>     autonomous (stateless) address configuration.
> > >>
> > >> Stateful address configuration is not mandatory to support.
> > >> RFC 4294 says
> > >>
> > >>     Stateful Address Autoconfiguration MAY be supported.
> > >>
> > >> But I do agree DHCPv6 could be used between the mobile node
> > >> and the MAG (Mobile Access Gateway).
> > >>
> > >> However, the address configuration for PMIPv6 depends to a
> > >> large extent on what kind of link layer is used between the
> > >> mobile node and the MAG. If the link layer is PPP, for e.g.,
> > >> IPv6CP is used. If the link layer is an IPsec tunnel then
> > >> IKEv2 configuration payloads are used. The PMIPv6 protocol
> > >> does consider this and has some text addressing this.
> > >>
> > >> Anyway, this discussion needs to happen on the NETLMM
> > >> mailing list.
> > >>
> > >> Vijay
> > >>
> > >> _______________________________________________
> > >> Mip6 mailing list
> > >> Mip6@ietf.org
> > >> https://www1.ietf.org/mailman/listinfo/mip6
> > >
> > > _______________________________________________
> > > Mip6 mailing list
> > > Mip6@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/mip6
> >
> >
> > _______________________________________________
> > Mip6 mailing list
> > Mip6@ietf.org
> > https://www1.ietf.org/mailman/listinfo/mip6
> >
>
> _______________________________________________
> Mip6 mailing list
> Mip6@ietf.org
> https://www1.ietf.org/mailman/listinfo/mip6
>
>

_______________________________________________
Mip6 mailing list
Mip6@ietf.org
https://www1.ietf.org/mailman/listinfo/mip6

--0-1803777546-1176751213=:1618-- --===============1354100523== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1354100523==-- From mip6-bounces@ietf.org Wed Apr 18 10:49:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeBSx-0004ap-3b; Wed, 18 Apr 2007 10:49:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeBSw-0004af-Lg for mip6@ietf.org; Wed, 18 Apr 2007 10:49:02 -0400 Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeBSv-0002eC-D7 for mip6@ietf.org; Wed, 18 Apr 2007 10:49:02 -0400 Received: from lor-maknavic3.int-evry.fr (lor-maknavic3.int-evry.fr [157.159.103.217]) by smtp2.int-evry.fr (Postfix) with ESMTP id 33CAE2FE0C for ; Wed, 18 Apr 2007 16:48:57 +0200 (CEST) From: Pars Mutaf To: mip6@ietf.org In-Reply-To: <45F7EB74.7060405@piuha.net> References: <45F7EB74.7060405@piuha.net> Content-Type: text/plain Organization: INT Evry Date: Wed, 18 Apr 2007 16:49:02 +0200 Message-Id: <1176907742.30106.33.camel@lor-maknavic3.int-evry.fr> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-MCPCheck: X-INT-MailScanner-SpamCheck: X-INT-MailScanner-From: pars.mutaf@int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [Mip6] Comment/question on draft-ietf-mip6-cn-ipsec-04.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pars.mutaf@int-evry.fr List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hello, IPsec would be possible between two mobile hosts that meet each other? This is a very important and common scenario. An example authentication method without PKI is given in: sparrow.ece.cmu.edu/~adrian/projects/sib.pdf Independently: I understand that global PKI cannot be reasonably assumed. I'm wondering why the same impossibility result would be applicable to a "regional PKI". Or, a PKI island. I'm not sure about the term exact. This would be very useful for securing the communication between mobile hosts living in the same region. [and possibly more practical than the above cited type of approaches]. I missed something? Thanks, pars _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 20 16:59:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hf0CE-0004SN-Qp; Fri, 20 Apr 2007 16:59:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hf0CD-0004S3-U8 for mip6@ietf.org; Fri, 20 Apr 2007 16:59:09 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hf0CC-0002gc-2V for mip6@ietf.org; Fri, 20 Apr 2007 16:59:09 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3KKwdfi030477 for ; Fri, 20 Apr 2007 23:59:06 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Apr 2007 23:59:04 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Apr 2007 15:59:02 -0500 Received: from 172.19.244.145 ([172.19.244.145]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Fri, 20 Apr 2007 20:59:02 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 20 Apr 2007 15:59:45 -0500 From: Basavaraj Patil To: Mobile IPv6 Mailing List Message-ID: Thread-Topic: IETF68 WG meeting minutes Thread-Index: AceDjtLiEW65Du+CEdudogARJNUNiA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 20 Apr 2007 20:59:02.0362 (UTC) FILETIME=[B9786BA0:01C7838E] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070420235906-70A39BB0-7D40E885/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ba0d4c5f57f7c289496fce758bbf4798 Subject: [Mip6] IETF68 WG meeting minutes X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Minutes of: Mobility for IPv6 (mip6) At: IETF68 March 19th, 2007 Chairs: Basavaraj Patil Gopal Dommety Credit for these minutes: 1. Ahmad Muhanna (amuhanna@nortel.com) -------------------------------------------------------- Chairs presented the agenda: - Alper suggested to move the DHCP discussion after the bootstrapping agenda item. 2. WG status and I-Ds update 5 Mins - Raj presented the WG Status. - Raj invited Jari to present his idea about merging the WGs MIP6, NEMO, and Monami6 - Jari presented consolidating WGs MIP6, NEMOW, and Monami6 in one. - These WGs handle the same technology. - Jari gave a very brief status of what these WGs are doing. - Raj presented the WG Document status. - Mip6-ikev2 draft is on the editor queue - Privacy location, Rajeev has addressed all security issues and concerns and it is in good shape to move forward. - Hesham mentioned that it is difficult to update the DSMIP draft without feedback from the group. - New WG document - Mip6-rfc4285bis, the primary change is very small change to fix the key length. - Completed WG LC: - Why auth data option - AAA-Ha-goals - Bootstrapping integrated - Ready for WG LC - Mip6-vsm - Experimental-messages - Nemo-v4traversal - Mip6-radius - Mip6-hareliability Raj asked the group if anyone has any comments. No comments. ...................................... 3. MIP6 support for DS hosts/routers - Open issues and discussion I-D: draft-ietf-mip6-nemo-v4traversal-03 Hesham Soliman 15 Mins - It is an update to the existing draft - Allows the MN to use either IPv4 or IPv6 CoA. Keiichi: if we can specify the tunneling mechanism, currently we can use either IP-in-IPv6 or IP-in-IPv4. He proposed to specify the tunneling mechanism. Sri: There is proper qualifier. Hesham: do you agree that you can receive it and after that based on the version you can do the switch. Sri: agreed that should work. But generally a qualifier is needed when do encapsulation. Kent: when looking at UDP header, in this case, there is a specific UDP port to specify. Alex: there will be one probably Hesham: said that we have two cases Alex: said when it is an IP-in-IP we do not need another header. Kent: said is that specific to Mobile IP encapsulation? Why do not we use a generic encapsulation mechanism? Sri: said, if there is a fire wall, there is a problem. Henrik: said that we heard this from Sri many times but this is not an issue. Francis: it was not designed for this purpose Henrik: V4 mapped address was not designed for this purpose. The second bullet is kind of bogus. I am not implemented this and I have to rely on other people who implemented this. Hesham, said Pascal implemented this and Keiichi did but he did not comment on it. Henrik continued saying that should be stated more strongly. Hesham: do you agree or disagree to bind the .. Henrik: yes Vijay: this is one sided of solving the issue. IPv4 CoA is carried in. you have to look into the most address and there was many issues raised to why it is a bad idea. Kuntal: one more issue discussed on the ML. one proposal to allow DHCPv6 to be used. I did not see any comment. Hesham and Raj asked Kuntal to register the issue on the tracker. Gopal: the chairs will send an email. Is that ok with you, asking Hesham. Hesham said: Yes. Is there any issue for using RF4334, I do not want to go and ask for another port. Hesham has not thought about it. Gopal, if it can work with two ports, then let us be. Henrik: we can easily make it work with by having an intermediate thing. There should not be a problem using RFC4334. Hesham: they might benefit from other tunneling GRE and that stuff. Henrik: it is even possible, we took some extra space from MIPv4 traversal, but it seems that a good idea. Raj let us close this issue at this point. Let us discuss it and reach consensus. Henrik: after hearing Vijay point and agree and change my point by reserving a new port. Raj: will post on the mailing list. ................................... 3a. UDP Encapsulation for IPv4 and IPv6 in DS-MIPv6 Issue 93 in MIP6 tracker (http://www.mip4.org/issues/tracker/mip6/) Vijay Devarapalli 15 Mins Vijay presented UDP encapsulation for IPv4 and IPv6 in DS-MIPv6 Raj, we will limit the amount of time and we will be better off if we think about them and make a decision later. Henrik: for option 4: you are limited to always have one type of encapsulated header. Vijay: you can send a new BU. Henrik: when I consider how the kernel handles incoming packets it will be easier for the in buffer to handle incoming code. I do not feel very happy about this one. Alex: Pascal if you set a flag in BU but what if you want to send IPv6 traffic in the middle. Is it possible to have this without NAT UDP. Alex, I do not know how you can have IP-in-IP over UDP. Kent: No. 3 other than using an over head I think it is ok. Gopal, Vijay did a good job presenting these options, let us discussing them on the mailing list. ....................................... 5. Home agent reliability I-D: draft-ietf-mip6-hareliability-01.txt Ryuji Wakikawa 15 Mins Ryuji presented Home Agent Reliability Protocol. - Issue about the convergence time in case of an HA switch. Sri mentioned that this is not an MN issue. Raj: please review the document and send feedback. ............................ 6. Discussion of open issues on I-Ds that are in WG LC 20 Mins a. draft-ietf-mip6-bootstrapping-integrated-02.txt Kuntal presented the integrated AAA-HA solution. Kilian said that he did not proposed what the slide says. In other words, he said the draft should not mention that. Vidya: I am fine with mentioning that about the DHCP security. I had some comments that I sent on the list which talk about physical security. There is nothing about DHCP security. Jari: what DHCP security? Having said that, if Vidya is frightened what you are suggesting is just fine or some ll security mechanism. Hesham: it is public knowledge, the IP address. Vidya: the text seems like it is mandating something Alper: it is a mistake to address DHCP security and we should remove it. Kuntal: we will remove this comment and issue is closed. John Michael: the key authenticate the DHCP server and DHCP client. Where the key comes from. Kuntal, Alper, Vidya, Raj there is no sensitivity in the information carried. Move on. Vidya: we do not need to mandate anything just as clarification. Kuntal agreed. Vidya: this is not closed. Do we need to discuss here or on ML? Kuntal: I have some solution. Raj: take the comments to the ML. Kilian: this scenario is not considered. Raj let us discuss offline. Alper: local HA issue is not specific to this draft and we should not tie it to this draft. Vijay: this issue is a little different RFC3403. if the MN got a DHCP address aside from IKEv2, I am not sure how this will be addressed. Kuntal: we get the address from NAS and it is stateless. Vijay: DHCP is used as a tool. Kuntal: yes as a tool to get an address. This is an address and can be used. Vijay: is there a problem. What is the relationship between the DHCP server and HA. For HA it is not an issue but for HoA it is. RAJ: let us take the issue to the ML. Kuntal: prefix also may have the same issue. Vijay: there is another DHCP option draft, can we move forward and address that in that draft. Kuntal: will update the current draft and then post emails about the open issues. Vijay: this document has a section how the MN should send DHCP request and how the DHCP relay should work. Also that other document also has the same text. It should be addressed in one draft but not in both. Vijay will send the text to the authors. ....................................... 4. DHCP Option for Home Information Discovery in MIPv6 I-D: draft-ietf-mip6-hiopt-02.txt Heejin Jang 10 Mins Vidya: more HL Q, if we assigned HA this way, if we use IKEv2 to fetch the information why we need DHCP? Vidya: why Gerardo: I agree with Vidya that we do not need this document. It seems that as if it is a companion document but not needed. Raj: do we need additional information. Kuntal: there was discussion in WiMAX and they added this option. Raj: then you need to put forward a Use case and if it is specific to some SDOs then we can rethink it. Raj: do we need that info Raj: write the use case and why we need this option. Bechet: we need the address but do we need stateless or not. Raj, Alper let us take it to the ML. Alper: what is the process, we have open issues? Can you guys send your comments ASAP that we can address them Vijay: both these documents have similar changes, can we write another document. Raj: we do not need another one. ........................................ Non-WG items: 1. Service Selection for Mobile IPv6 I-D: draft-korhonen-mip6-service-00.txt Jouni Korhonen 10 Mins Henrik: Mostly concern about the ID if it is plain that is ok but it has to be much more secure. Jouni: will be sent in BU Henrik: If this ID is handed out by the provider, it should not be possible to change it. .............................. 2. Mobility Header Signaling Message I-D: draft-haley-mip6-mh-signaling-02.txt Sri Gundavelli 10 Mins Alper; what is the scope of the message. Sri: Opaque load, HA is going down after 1 hr or something? Alper: is that related to MIPv6 related or prepaid. Henrik: there is a similar thing in MIPv4. My worries when saying opaque. This becomes not MIP6 specific. Alex: looks like a good idea. Hesham: there is another draft about vendor specific because there is another draft which is VS draft. It was agreed that this is a good thing for MIP6 and Raj will ask for consensus to make this a WG document. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 23 02:43:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfsGT-0005Xh-0S; Mon, 23 Apr 2007 02:43:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfsGS-0005V7-7v for mip6@ietf.org; Mon, 23 Apr 2007 02:43:08 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfsGP-0000VE-SH for mip6@ietf.org; Mon, 23 Apr 2007 02:43:08 -0400 Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l3N6fvgh019184 for ; Mon, 23 Apr 2007 01:42:01 -0500 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Apr 2007 01:43:00 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 23 Apr 2007 02:42:59 -0400 Message-ID: <6D19CA8D71C89C43A057926FE0D4ADAA542DF2@ecamlmw720.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Multicast Mobility mailing list Thread-Index: AceFcqI82L4/uYfSSLSCsoo+s03ruA== From: "Suresh Krishnan \(QB/EMC\)" To: X-OriginalArrivalTime: 23 Apr 2007 06:43:01.0115 (UTC) FILETIME=[A30554B0:01C78572] X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Mip6] Multicast Mobility mailing list X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Folks, =20 We wanted to inform you that we have created a new mailing list in order to discuss the interactions occuring between mobility and multicast. We invite anyone interested in contributing to the work to subscribe and collaborate. To register visit the list page at: =20 https://www1.ietf.org/mailman/listinfo/multimob =20 Several of you have expressed interest in this work and some documents already exist without a home working group. =20 The primary problem that we foresee being discussed in the mailing list is issues with Multicast listener (receiver) mobility for multicast routing. There are several other associated problems like sender mobility, which can also be discussed. =20 Thanks Suresh and Behcet _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 23 03:20:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfsqY-0002F7-PD; Mon, 23 Apr 2007 03:20:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfsqW-0002Ci-NA for mip6@ietf.org; Mon, 23 Apr 2007 03:20:24 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfsqU-0008Jz-CU for mip6@ietf.org; Mon, 23 Apr 2007 03:20:24 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Apr 2007 00:20:19 -0700 Message-ID: <462C5E21.2050008@azairenet.com> Date: Mon, 23 Apr 2007 00:20:01 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Suresh Krishnan (QB/EMC)" Subject: Re: [Mip6] Multicast Mobility mailing list References: <6D19CA8D71C89C43A057926FE0D4ADAA542DF2@ecamlmw720.eamcs.ericsson.se> In-Reply-To: <6D19CA8D71C89C43A057926FE0D4ADAA542DF2@ecamlmw720.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Apr 2007 07:20:20.0524 (UTC) FILETIME=[D9D006C0:01C78577] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hello Suresh, I would suggest mobopts as one venue for this work. Some proposals have already been presented in the mobopts group on this topic. We could do the work in the mobopts group and once they are stable enough, bring them to the MIPSHOP or the MIP6 WG for standardization. Vijay Suresh Krishnan (QB/EMC) wrote: > Hi Folks, > > We wanted to inform you that we have created a new mailing list in order > to discuss the interactions occuring between mobility and multicast. We > invite anyone interested in contributing to the work to subscribe and > collaborate. To register visit the list page at: > > https://www1.ietf.org/mailman/listinfo/multimob > > Several of you have expressed interest in this work and some documents > already exist without a home working group. > > The primary problem that we foresee being discussed in the mailing list > is issues with Multicast listener (receiver) mobility for multicast > routing. There are several other associated problems like sender > mobility, which can also be discussed. > > Thanks > Suresh and Behcet > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 23 04:05:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HftY9-0004kN-5f; Mon, 23 Apr 2007 04:05:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HftY8-0004kI-4A for mip6@ietf.org; Mon, 23 Apr 2007 04:05:28 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HftY6-0007zZ-LW for mip6@ietf.org; Mon, 23 Apr 2007 04:05:28 -0400 Received: (qmail invoked by alias); 23 Apr 2007 08:05:24 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp030) with SMTP; 23 Apr 2007 10:05:24 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18OgcxGcyoOCTjokmpJDIQsX6hQYCJaLJxLUWHbzH cK9yANpt9bQrv1 Message-ID: <462C68C2.9090305@gmx.net> Date: Mon, 23 Apr 2007 10:05:22 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Suresh Krishnan (QB/EMC)" Subject: Re: [Mip6] Multicast Mobility mailing list References: <6D19CA8D71C89C43A057926FE0D4ADAA542DF2@ecamlmw720.eamcs.ericsson.se> In-Reply-To: <6D19CA8D71C89C43A057926FE0D4ADAA542DF2@ecamlmw720.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Do we have some information about the usage of multicast on the Internet? Suresh Krishnan (QB/EMC) wrote: > Hi Folks, > > We wanted to inform you that we have created a new mailing list in order > to discuss the interactions occuring between mobility and multicast. We > invite anyone interested in contributing to the work to subscribe and > collaborate. To register visit the list page at: > > https://www1.ietf.org/mailman/listinfo/multimob > > Several of you have expressed interest in this work and some documents > already exist without a home working group. > > The primary problem that we foresee being discussed in the mailing list > is issues with Multicast listener (receiver) mobility for multicast > routing. There are several other associated problems like sender > mobility, which can also be discussed. > > Thanks > Suresh and Behcet > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 23 05:24:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfumx-0003CE-FO; Mon, 23 Apr 2007 05:24:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfumu-0003Bw-Nv for mip6@ietf.org; Mon, 23 Apr 2007 05:24:49 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hfumt-0000Zq-Bq for mip6@ietf.org; Mon, 23 Apr 2007 05:24:48 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-6.tower-153.messagelabs.com!1177320286!1265202!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 22013 invoked from network); 23 Apr 2007 09:24:46 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-6.tower-153.messagelabs.com with SMTP; 23 Apr 2007 09:24:46 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l3N9OkkX017174; Mon, 23 Apr 2007 02:24:46 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id l3N9OjWm022124; Mon, 23 Apr 2007 04:24:45 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l3N9Og0I022075; Mon, 23 Apr 2007 04:24:43 -0500 (CDT) Message-ID: <462C7B59.9040900@gmail.com> Date: Mon, 23 Apr 2007 11:24:41 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Mip6] Multicast Mobility mailing list References: <6D19CA8D71C89C43A057926FE0D4ADAA542DF2@ecamlmw720.eamcs.ericsson.se> <462C68C2.9090305@gmx.net> In-Reply-To: <462C68C2.9090305@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000735-1, 21/04/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: mip6@ietf.org, "Suresh Krishnan \(QB/EMC\)" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hannes Tschofenig wrote: > Do we have some information about the usage of multicast on the Internet? Some RFCs on the Standards Track? Do we have some information about the non-usage of multicast on the Internet? Alex > > Suresh Krishnan (QB/EMC) wrote: >> Hi Folks, >> >> We wanted to inform you that we have created a new mailing list in order >> to discuss the interactions occuring between mobility and multicast. We >> invite anyone interested in contributing to the work to subscribe and >> collaborate. To register visit the list page at: >> >> https://www1.ietf.org/mailman/listinfo/multimob >> >> Several of you have expressed interest in this work and some documents >> already exist without a home working group. >> >> The primary problem that we foresee being discussed in the mailing list >> is issues with Multicast listener (receiver) mobility for multicast >> routing. There are several other associated problems like sender >> mobility, which can also be discussed. >> >> Thanks >> Suresh and Behcet >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 >> > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 23 12:26:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg1NB-0007XJ-6D; Mon, 23 Apr 2007 12:26:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg1N8-0007H4-AM for mip6@ietf.org; Mon, 23 Apr 2007 12:26:38 -0400 Received: from web84107.mail.mud.yahoo.com ([68.142.206.194]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hg1IB-0004Kk-VB for mip6@ietf.org; Mon, 23 Apr 2007 12:21:32 -0400 Received: (qmail 35112 invoked by uid 60001); 23 Apr 2007 16:21:30 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=YfRKSlrUMo/+K3XNTCXkv1HbXlfvNJfaYS4TQUq17vb74JT6JSUGKbwcFlQdWxDnAMiBBQ1ojxMvAtnzvehlNApNqSNsYSSqSJKGcS2wf7WMqGvkwKA+s382zy/ayqwWKMQThL1UbOW0vz7x/rfLKkMLeKs5HvSTFOUsbuQ99oU=; X-YMail-OSG: 4FXjogwVM1ljHvBZXK3Gdcn4gBCMZPifV_BxiU2m0Ir16u4i2xUdYYAm4l2BMwp5_6HONw2tv9fi8NTmdizs.0ZO3h0EwJ3jTD3dHKbAfQ5ebkA3Gt_VietVJmEmoQ-- Received: from [206.16.17.212] by web84107.mail.mud.yahoo.com via HTTP; Mon, 23 Apr 2007 09:21:30 PDT X-Mailer: YahooMailRC/478 YahooMailWebService/0.7.41.10 Date: Mon, 23 Apr 2007 09:21:30 -0700 (PDT) From: Behcet Sarikaya Subject: Re: [Mip6] Multicast Mobility mailing list To: Alexandru Petrescu , Hannes Tschofenig MIME-Version: 1.0 Message-ID: <668535.26558.qm@web84107.mail.mud.yahoo.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: mip6@ietf.org, multimob@ietf.org, "Suresh Krishnan \(QB/EMC\)" , schmidt@fhtw-berlin.de X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Behcet Sarikaya List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1896294294==" Errors-To: mip6-bounces@ietf.org --===============1896294294== Content-Type: multipart/alternative; boundary="0-1496560980-1177345290=:26558" --0-1496560980-1177345290=:26558 Content-Type: text/plain; charset=ascii Hi Alex, Hannes and Vijay, Thanks for your comments. Thomas' draft is one of the starting points to be taken in multimob activity. We invite all of you to join the multimob mailing list. Let's continue the discussions there. Regards, Behcet ----- Original Message ---- From: Alexandru Petrescu To: Hannes Tschofenig Cc: mip6@ietf.org; Suresh Krishnan (QB/EMC) Sent: Monday, April 23, 2007 4:24:41 AM Subject: Re: [Mip6] Multicast Mobility mailing list Hannes Tschofenig wrote: > Do we have some information about the usage of multicast on the Internet? Some RFCs on the Standards Track? Do we have some information about the non-usage of multicast on the Internet? Alex > > Suresh Krishnan (QB/EMC) wrote: >> Hi Folks, >> >> We wanted to inform you that we have created a new mailing list in order >> to discuss the interactions occuring between mobility and multicast. We >> invite anyone interested in contributing to the work to subscribe and >> collaborate. To register visit the list page at: >> >> https://www1.ietf.org/mailman/listinfo/multimob >> >> Several of you have expressed interest in this work and some documents >> already exist without a home working group. >> >> The primary problem that we foresee being discussed in the mailing list >> is issues with Multicast listener (receiver) mobility for multicast >> routing. There are several other associated problems like sender >> mobility, which can also be discussed. >> >> Thanks >> Suresh and Behcet >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 >> > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --0-1496560980-1177345290=:26558 Content-Type: text/html; charset=ascii
Hi Alex, Hannes and Vijay,
  Thanks for your comments.
Thomas' draft is one of the starting points to be taken in multimob activity. We invite all of you to join the multimob mailing list.
  Let's continue the discussions there.
Regards,
 
Behcet

----- Original Message ----
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
To: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
Cc: mip6@ietf.org; Suresh Krishnan (QB/EMC) <suresh.krishnan@ericsson.com>
Sent: Monday, April 23, 2007 4:24:41 AM
Subject: Re: [Mip6] Multicast Mobility mailing list

Hannes Tschofenig wrote:
> Do we have some information about the usage of multicast on the Internet?

Some RFCs on the Standards Track?

Do we have some information about the non-usage of multicast on the
Internet?

Alex

>
> Suresh Krishnan (QB/EMC) wrote:
>> Hi Folks,
>>  
>> We wanted to inform you that we have created a new mailing list in order
>> to discuss the interactions occuring between mobility and multicast. We
>> invite anyone interested in contributing to the work to subscribe and
>> collaborate. To register visit the list page at:
>>  
>> https://www1.ietf.org/mailman/listinfo/multimob
>>  
>> Several of you have expressed interest in this work and some documents
>> already exist without a home working group.
>>  
>> The primary problem that we foresee being discussed in the mailing list
>> is issues with Multicast listener (receiver) mobility for multicast
>> routing. There are several other associated problems like sender
>> mobility, which can also be discussed.
>>  
>> Thanks
>> Suresh and Behcet
>>
>> _______________________________________________
>> Mip6 mailing list
>> Mip6@ietf.org
>> https://www1.ietf.org/mailman/listinfo/mip6
>>  
>
>
> _______________________________________________
> Mip6 mailing list
> Mip6@ietf.org
> https://www1.ietf.org/mailman/listinfo/mip6
>


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________

_______________________________________________
Mip6 mailing list
Mip6@ietf.org
https://www1.ietf.org/mailman/listinfo/mip6

--0-1496560980-1177345290=:26558-- --===============1896294294== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1896294294==-- From mip6-bounces@ietf.org Mon Apr 23 15:50:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg4Y2-0003DW-40; Mon, 23 Apr 2007 15:50:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg4Xy-0003CA-Nh; Mon, 23 Apr 2007 15:50:02 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg4Xy-0005pK-FW; Mon, 23 Apr 2007 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 6EE3432AF6; Mon, 23 Apr 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Hg4Xy-0004CK-As; Mon, 23 Apr 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 23 Apr 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: mip6@ietf.org Subject: [Mip6] I-D ACTION:draft-ietf-mip6-bootstrapping-integrated-dhc-03.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv6 Working Group of the IETF. Title : MIP6-bootstrapping for the Integrated Scenario Author(s) : K. Chowdhury, A. Yegin Filename : draft-ietf-mip6-bootstrapping-integrated-dhc-03.txt Pages : 19 Date : 2007-4-23 The Mobile IPv6 bootstrapping problem statement describes two main scenarios. In the first scenario (i.e. the split scenario), the mobile node's mobility service is authorized by a different service authorizer than the basic network access authorizer. In the second scenario (i.e. the integrated scenario), the mobile node's mobility service is authorized by the same service authorizer as the basic network access service authorizer. This document defines a method for home agent information discovery for the integrated scenario. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-integrated-dhc-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-ietf-mip6-bootstrapping-integrated-dhc-03.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-ietf-mip6-bootstrapping-integrated-dhc-03.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-4-23112614.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-bootstrapping-integrated-dhc-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-bootstrapping-integrated-dhc-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-4-23112614.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --NextPart-- From mip6-bounces@ietf.org Mon Apr 23 15:50:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg4Yf-0004aU-Ju; Mon, 23 Apr 2007 15:50:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg4YU-0004Fl-1d; Mon, 23 Apr 2007 15:50:34 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hg4YS-00083Q-KO; Mon, 23 Apr 2007 15:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 86FA02AD02; Mon, 23 Apr 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Hg4Xy-0004CH-AH; Mon, 23 Apr 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 23 Apr 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: mip6@ietf.org Subject: [Mip6] I-D ACTION:draft-ietf-mip6-bootstrapping-integrated-dhc-03.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv6 Working Group of the IETF. Title : MIP6-bootstrapping for the Integrated Scenario Author(s) : K. Chowdhury, A. Yegin Filename : draft-ietf-mip6-bootstrapping-integrated-dhc-03.txt Pages : 19 Date : 2007-4-23 The Mobile IPv6 bootstrapping problem statement describes two main scenarios. In the first scenario (i.e. the split scenario), the mobile node's mobility service is authorized by a different service authorizer than the basic network access authorizer. In the second scenario (i.e. the integrated scenario), the mobile node's mobility service is authorized by the same service authorizer as the basic network access service authorizer. This document defines a method for home agent information discovery for the integrated scenario. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-integrated-dhc-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-ietf-mip6-bootstrapping-integrated-dhc-03.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-ietf-mip6-bootstrapping-integrated-dhc-03.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-4-23112123.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-bootstrapping-integrated-dhc-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-bootstrapping-integrated-dhc-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-4-23112123.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --NextPart-- From mip6-bounces@ietf.org Mon Apr 23 16:56:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg5ac-000766-BO; Mon, 23 Apr 2007 16:56:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg5aa-00073w-Mb for mip6@ietf.org; Mon, 23 Apr 2007 16:56:48 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg5aZ-0005nK-KQ for mip6@ietf.org; Mon, 23 Apr 2007 16:56:48 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l3NKu5011252 for ; Mon, 23 Apr 2007 20:56:06 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 23 Apr 2007 15:56:44 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60B5F6B3D@zrc2hxm2.corp.nortel.com> In-Reply-To: <729b68be0704130956n1c2233ehf73ea259e83d409d@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: GRE key thread-index: Acd97L2a1de9c2pASm6EtmS+pJLuvwH/LBqg From: "Mohamed Khalil" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [Mip6] GRE key X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi All, The following draft has been posted on netlmm, your comments and feedback is much appreciated. The Proxy Mobile IPv6 base specification defined in [PMIP6-ID] allows the mobile node's IPv4 and IPv6 traffic between the local mobility anchor and the mobile access gateway to be tunneled using IPv6, IPv4 or IPv4-UDP encapsulation headers. These encapsulation modes do not offer semantics for the tunnel end-points to expose a service identifier that can be used to identify traffic for a certain classification, such as for supporting mobile nodes that are using overlapping private IPv4 addressing. The extensions defined in this document allow the mobile access gateway and the local mobility anchor to negotiate GRE encapsulation mode and along with the GRE symmetric key or asymmetric keys for marking the flows, so that differential processing can be applied by the tunnel peers over those flows. http://www.ietf.org/internet-drafts/draft-muhanna-netlmm-grekey-option-0 0.txt _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 23 18:13:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg6mR-0004DA-G0; Mon, 23 Apr 2007 18:13:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg6mP-0004D1-Uk for mip6@ietf.org; Mon, 23 Apr 2007 18:13:05 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg6mO-0003z4-FR for mip6@ietf.org; Mon, 23 Apr 2007 18:13:05 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JGZ002QX1OH6M@szxga03-in.huawei.com> for mip6@ietf.org; Tue, 24 Apr 2007 06:12:17 +0800 (CST) Received: from ny3104051930 ([10.124.12.71]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JGZ00JJ31OCJI@szxga03-in.huawei.com> for mip6@ietf.org; Tue, 24 Apr 2007 06:12:17 +0800 (CST) Date: Mon, 23 Apr 2007 17:13:44 -0500 From: Frank Xia Subject: Re: [Mip6] Multicast Mobility mailing list To: Alexandru Petrescu , Hannes Tschofenig Message-id: <007f01c785f4$a9e57490$470c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <6D19CA8D71C89C43A057926FE0D4ADAA542DF2@ecamlmw720.eamcs.ericsson.se> <462C68C2.9090305@gmx.net> <462C7B59.9040900@gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: mip6@ietf.org, "Suresh Krishnan \(QB/EMC\)" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Alex, Hannes Last year, in San Diego meeting , I gave a presentation about multicast fast handover which received many good feedbacks. It is time to discuss multicast mobility, because it could be a challenge technical point when mobile IPTV is deployed on WiMAX, 3G networks. BR Frank ----- Original Message ----- From: "Alexandru Petrescu" To: "Hannes Tschofenig" Cc: ; "Suresh Krishnan (QB/EMC)" Sent: Monday, April 23, 2007 4:24 AM Subject: Re: [Mip6] Multicast Mobility mailing list > Hannes Tschofenig wrote: > > Do we have some information about the usage of multicast on the Internet? > > Some RFCs on the Standards Track? > > Do we have some information about the non-usage of multicast on the > Internet? > > Alex > > > > > Suresh Krishnan (QB/EMC) wrote: > >> Hi Folks, > >> > >> We wanted to inform you that we have created a new mailing list in order > >> to discuss the interactions occuring between mobility and multicast. We > >> invite anyone interested in contributing to the work to subscribe and > >> collaborate. To register visit the list page at: > >> > >> https://www1.ietf.org/mailman/listinfo/multimob > >> > >> Several of you have expressed interest in this work and some documents > >> already exist without a home working group. > >> > >> The primary problem that we foresee being discussed in the mailing list > >> is issues with Multicast listener (receiver) mobility for multicast > >> routing. There are several other associated problems like sender > >> mobility, which can also be discussed. > >> > >> Thanks > >> Suresh and Behcet > >> > >> _______________________________________________ > >> Mip6 mailing list > >> Mip6@ietf.org > >> https://www1.ietf.org/mailman/listinfo/mip6 > >> > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 24 12:03:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgNUA-0004sC-Co; Tue, 24 Apr 2007 12:03:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgNU9-0004qb-4O for mip6@ietf.org; Tue, 24 Apr 2007 12:03:21 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HgNU6-0006xr-Nd for mip6@ietf.org; Tue, 24 Apr 2007 12:03:21 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-6.tower-128.messagelabs.com!1177430597!18368375!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 5962 invoked from network); 24 Apr 2007 16:03:17 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-6.tower-128.messagelabs.com with SMTP; 24 Apr 2007 16:03:17 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l3OG3ENh015391; Tue, 24 Apr 2007 09:03:14 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id l3OG3EQu029524; Tue, 24 Apr 2007 11:03:14 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l3OG3CIf029389; Tue, 24 Apr 2007 11:03:13 -0500 (CDT) Message-ID: <462E2A3B.6010403@gmail.com> Date: Tue, 24 Apr 2007 18:03:07 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Mohamed Khalil Subject: Re: [Mip6] GRE key References: <62B9B0847CC47543B6B3B5E26BD268E60B5F6B3D@zrc2hxm2.corp.nortel.com> In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60B5F6B3D@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000735-2, 23/04/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Mohamed Khalil wrote: > Hi All, > > The following draft has been posted on netlmm, your comments and > feedback is much appreciated. > > The Proxy Mobile IPv6 base specification defined in [PMIP6-ID] allows > the mobile node's IPv4 and IPv6 traffic between the local mobility > anchor and the mobile access gateway to be tunneled using IPv6, IPv4 > or IPv4-UDP encapsulation headers. These encapsulation modes do not > offer semantics for the tunnel end-points to expose a service > identifier that can be used to identify traffic for a certain > classification, such as for supporting mobile nodes that are using > overlapping private IPv4 addressing. The extensions defined in this > document allow the mobile access gateway and the local mobility > anchor to negotiate GRE encapsulation mode and along with the GRE > symmetric key or asymmetric keys for marking the flows, so that > differential processing can be applied by the tunnel peers over those > flows. Several reasons I believe GRE is not necessary for PMIPv6. Does GRE work transporting IPv6? I thought it only transports IPv4. PMIPv6 assumes IPv6 applications first, in my understanding. PMIPv6 inherits from MIPv6 tunnelling, which is IPv6-in-IPv6 which is Generic Packet Tunnelling rfc2473 (not GRE); and it maybe inherits from DS-MIPv6 whose method of transporting IPv6 over IPv4 is not yet clarified, but was discussed until now to be IPv6 in UDPv4 (again not GRE) or maybe IPv6-in-IPv4 with protocol number 41 rfc2893 (yet again not GRE). I think it is also obvious that PMIPv6 done in netlmm WG should encapsulate only once at max, not twice nor more. Ie a packet from LMA to MAG should only be encapsulated once (IPv6 in UDP/IPv4 or maybe IPv6 in IPv6, but not in a double encapsulation like IPv6-in-IPv4-in-GRE). So in this context, can I ask why GRE? It's not used by MIPv6, was never suggested by DS-MIPv6, can't transport IPv6 and has several implemented alternatives. Why GRE? Alex > > > > http://www.ietf.org/internet-drafts/draft-muhanna-netlmm-grekey-option-0 > 0.txt > > > > _______________________________________________ Mip6 mailing list > Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 24 12:23:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgNni-0007ml-0d; Tue, 24 Apr 2007 12:23:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgNng-0007lY-V2 for mip6@ietf.org; Tue, 24 Apr 2007 12:23:32 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgNne-0003pl-Kx for mip6@ietf.org; Tue, 24 Apr 2007 12:23:32 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l3OGNM027633; Tue, 24 Apr 2007 16:23:22 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] GRE key Date: Tue, 24 Apr 2007 11:23:21 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60B5F6B4C@zrc2hxm2.corp.nortel.com> In-Reply-To: <462E2A3B.6010403@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] GRE key thread-index: AceGihXui1/pTgu7S5O8VJ53ndVOZwAAChwg From: "Mohamed Khalil" To: "Alexandru Petrescu" X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Alexandru, -----Original Message----- From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 Sent: Tuesday, April 24, 2007 11:03 AM To: Khalil, Mohamed (RICH2:2S20) Cc: mip6@ietf.org Subject: Re: [Mip6] GRE key Mohamed Khalil wrote: > Hi All, >=20 > The following draft has been posted on netlmm, your comments and > feedback is much appreciated. >=20 > The Proxy Mobile IPv6 base specification defined in [PMIP6-ID] allows > the mobile node's IPv4 and IPv6 traffic between the local mobility=20 > anchor and the mobile access gateway to be tunneled using IPv6, IPv4=20 > or IPv4-UDP encapsulation headers. These encapsulation modes do not=20 > offer semantics for the tunnel end-points to expose a service=20 > identifier that can be used to identify traffic for a certain=20 > classification, such as for supporting mobile nodes that are using=20 > overlapping private IPv4 addressing. The extensions defined in this=20 > document allow the mobile access gateway and the local mobility anchor > to negotiate GRE encapsulation mode and along with the GRE symmetric=20 > key or asymmetric keys for marking the flows, so that differential=20 > processing can be applied by the tunnel peers over those flows. Several reasons I believe GRE is not necessary for PMIPv6. Does GRE work transporting IPv6? I thought it only transports IPv4. PMIPv6 assumes IPv6 applications first, in my understanding. Mohamed>> should be use to transport IP6 too. PMIPv6 inherits from MIPv6 tunnelling, which is IPv6-in-IPv6 which is Generic Packet Tunnelling rfc2473 (not GRE); and it maybe inherits from DS-MIPv6 whose method of transporting IPv6 over IPv4 is not yet clarified, but was discussed until now to be IPv6 in UDPv4 (again not GRE) or maybe IPv6-in-IPv4 with protocol number 41 rfc2893 (yet again not GRE). I think it is also obvious that PMIPv6 done in netlmm WG should encapsulate only once at max, not twice nor more. Ie a packet from LMA to MAG should only be encapsulated once (IPv6 in UDP/IPv4 or maybe IPv6 in IPv6, but not in a double encapsulation like IPv6-in-IPv4-in-GRE). Mohamed>> I don't see the issue of double encapsulation, IP4-UDP-IP6 is double encapsulation (DS-MIP6). IPv4 header (src=3DV4ADDR, dst=3DHA_V4ADDR) UDP header IPv6 header (src=3DV4CoA, dst=3DHAADDR) DST-OPT HAO (IPv6 home address) Mobility header BU [IPv4 HAO] So in this context, can I ask why GRE? It's not used by MIPv6, was never suggested by DS-MIPv6, can't transport IPv6 and has several implemented alternatives. Why GRE? mohamed>> GRE is used in this draft to mark/identify traffic for a certain classification, such as for supporting mobile nodes that are using overlapping private IPv4 addressing. Mohamed Alex >=20 >=20 >=20 > http://www.ietf.org/internet-drafts/draft-muhanna-netlmm-grekey-option > -0 > 0.txt >=20 >=20 >=20 > _______________________________________________ Mip6 mailing list > Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 >=20 ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email=20 ______________________________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 24 12:37:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgO0l-0006mD-Uk; Tue, 24 Apr 2007 12:37:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgO0l-0006m8-Eg for mip6@ietf.org; Tue, 24 Apr 2007 12:37:03 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgO0j-0006X7-VB for mip6@ietf.org; Tue, 24 Apr 2007 12:37:03 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 24 Apr 2007 09:37:01 -0700 X-IronPort-AV: i="4.14,448,1170662400"; d="scan'208"; a="415080973:sNHT63694062" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l3OGb1O5020637; Tue, 24 Apr 2007 09:37:01 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3OGb1MF027448; Tue, 24 Apr 2007 16:37:01 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Apr 2007 09:37:01 -0700 Received: from sgundavewxp ([10.32.246.211]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Apr 2007 09:37:00 -0700 From: "Sri Gundavelli" To: "'Alexandru Petrescu'" , "'Mohamed Khalil'" References: <62B9B0847CC47543B6B3B5E26BD268E60B5F6B3D@zrc2hxm2.corp.nortel.com> <462E2A3B.6010403@gmail.com> Subject: RE: [Mip6] GRE key Date: Tue, 24 Apr 2007 09:37:00 -0700 Message-ID: <018f01c7868e$c84b6210$d3f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceGikEm4Ce+hVjXT2e11N57Sn9LuwAAt+Xg In-Reply-To: <462E2A3B.6010403@gmail.com> X-OriginalArrivalTime: 24 Apr 2007 16:37:00.0695 (UTC) FILETIME=[C8476A70:01C7868E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3708; t=1177432621; x=1178296621; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[Mip6]=20GRE=20key |Sender:=20; bh=m2onz6WhYJ7hpg6P7WvvIhruqnVfvUskv5w8/1i0pVY=; b=V6DBO2L/tixonZyYSZ+VuWCFKpYFiZPjrtMNeg9BUQ8Da7wGsAGQuWBfVjYxzsYbEzLmmsW3 BYOJulwTHsgO3tmydWZ7cpy9Y0U32GA/g9AR+RanWawLOLPPlCq/HBHS; Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org quick comments on this .... -----Original Message----- From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] Sent: Tuesday, April 24, 2007 9:03 AM To: Mohamed Khalil Cc: mip6@ietf.org Subject: Re: [Mip6] GRE key Mohamed Khalil wrote: > Hi All, > > The following draft has been posted on netlmm, your comments and > feedback is much appreciated. > > The Proxy Mobile IPv6 base specification defined in [PMIP6-ID] allows > the mobile node's IPv4 and IPv6 traffic between the local mobility > anchor and the mobile access gateway to be tunneled using IPv6, IPv4 > or IPv4-UDP encapsulation headers. These encapsulation modes do not > offer semantics for the tunnel end-points to expose a service > identifier that can be used to identify traffic for a certain > classification, such as for supporting mobile nodes that are using > overlapping private IPv4 addressing. The extensions defined in this > document allow the mobile access gateway and the local mobility > anchor to negotiate GRE encapsulation mode and along with the GRE > symmetric key or asymmetric keys for marking the flows, so that > differential processing can be applied by the tunnel peers over those > flows. Several reasons I believe GRE is not necessary for PMIPv6. Does GRE work transporting IPv6? I thought it only transports IPv4. PMIPv6 assumes IPv6 applications first, in my understanding. [Sri] 2784 does not disallow the IPv6 transport. The note in the Appendix section just states, at that time when the spec was written, there were no known implementation supporting GRE over IPv6. It needs to be understood that the GRE implementations were out there first before the spec came out and so the comment was in that context. Cisco has GRE support over IPv6 for years and nothing in the spec prevents that. PMIPv6 inherits from MIPv6 tunnelling, which is IPv6-in-IPv6 which is Generic Packet Tunnelling rfc2473 (not GRE); and it maybe inherits from DS-MIPv6 whose method of transporting IPv6 over IPv4 is not yet clarified, but was discussed until now to be IPv6 in UDPv4 (again not GRE) or maybe IPv6-in-IPv4 with protocol number 41 rfc2893 (yet again not GRE). I think it is also obvious that PMIPv6 done in netlmm WG should encapsulate only once at max, not twice nor more. Ie a packet from LMA to MAG should only be encapsulated once (IPv6 in UDP/IPv4 or maybe IPv6 in IPv6, but not in a double encapsulation like IPv6-in-IPv4-in-GRE). [Sri] Probably the draft needs one revision to reflect the current WG chair's decision to split the PMIP6 document. Probably, this draft should be discussed a bit later after the current PMIP6 work is complete, may be 2 months down the road. So in this context, can I ask why GRE? It's not used by MIPv6, was never suggested by DS-MIPv6, can't transport IPv6 and has several implemented alternatives. Why GRE? [Sri] There are many use cases. It should be discussed later, IMO. Alex > > > > http://www.ietf.org/internet-drafts/draft-muhanna-netlmm-grekey-option-0 > 0.txt > > > > _______________________________________________ Mip6 mailing list > Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 24 12:43:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgO6l-0007gl-6C; Tue, 24 Apr 2007 12:43:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgO6j-0007gd-KC for mip6@ietf.org; Tue, 24 Apr 2007 12:43:13 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HgO6j-0008Ou-5F for mip6@ietf.org; Tue, 24 Apr 2007 12:43:13 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-4.tower-153.messagelabs.com!1177432991!1867063!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 20658 invoked from network); 24 Apr 2007 16:43:11 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-4.tower-153.messagelabs.com with SMTP; 24 Apr 2007 16:43:11 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l3OGhBFd027154; Tue, 24 Apr 2007 09:43:11 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id l3OGhBan000900; Tue, 24 Apr 2007 11:43:11 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id l3OGh9bC000836; Tue, 24 Apr 2007 11:43:10 -0500 (CDT) Message-ID: <462E3398.7000100@gmail.com> Date: Tue, 24 Apr 2007 18:43:04 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Mohamed Khalil Subject: Re: [Mip6] GRE key References: <62B9B0847CC47543B6B3B5E26BD268E60B5F6B4C@zrc2hxm2.corp.nortel.com> In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60B5F6B4C@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000735-2, 23/04/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Mohamed Khalil wrote: > Hi Alexandru, > > -----Original Message----- From: Alexandru Petrescu > [mailto:alexandru.petrescu@gmail.com] Sent: Tuesday, April 24, 2007 > 11:03 AM To: Khalil, Mohamed (RICH2:2S20) Cc: mip6@ietf.org Subject: > Re: [Mip6] GRE key > > > Mohamed Khalil wrote: >> Hi All, >> >> The following draft has been posted on netlmm, your comments and >> feedback is much appreciated. >> >> The Proxy Mobile IPv6 base specification defined in [PMIP6-ID] >> allows > >> the mobile node's IPv4 and IPv6 traffic between the local mobility >> anchor and the mobile access gateway to be tunneled using IPv6, >> IPv4 or IPv4-UDP encapsulation headers. These encapsulation modes >> do not offer semantics for the tunnel end-points to expose a >> service identifier that can be used to identify traffic for a >> certain classification, such as for supporting mobile nodes that >> are using overlapping private IPv4 addressing. The extensions >> defined in this document allow the mobile access gateway and the >> local mobility anchor > >> to negotiate GRE encapsulation mode and along with the GRE >> symmetric key or asymmetric keys for marking the flows, so that >> differential processing can be applied by the tunnel peers over >> those flows. > > Several reasons I believe GRE is not necessary for PMIPv6. > > Does GRE work transporting IPv6? I thought it only transports IPv4. > PMIPv6 assumes IPv6 applications first, in my understanding. > > Mohamed>> should be use to transport IP6 too. It's true that the RFC I'm referring to is relatively old, is there an update on the GRE implementation as to show it can transport IPv6? rfc2784 says: > o IPv6 as Delivery and/or Payload Protocol > > This specification describes the intersection of GRE currently > deployed by multiple vendors. IPv6 as delivery and/or payload > protocol is not included in the currently deployed versions of GRE. Is there an update to this RFC or to this statement in this RFC? Thanks. >> PMIPv6 inherits from MIPv6 tunnelling, which is IPv6-in-IPv6 which >> is Generic Packet Tunnelling rfc2473 (not GRE); and it maybe >> inherits from DS-MIPv6 whose method of transporting IPv6 over IPv4 >> is not yet clarified, but was discussed until now to be IPv6 in >> UDPv4 (again not GRE) or maybe IPv6-in-IPv4 with protocol number 41 >> rfc2893 (yet again not GRE). >> >> I think it is also obvious that PMIPv6 done in netlmm WG should >> encapsulate only once at max, not twice nor more. Ie a packet from >> LMA to MAG should only be encapsulated once (IPv6 in UDP/IPv4 or >> maybe IPv6 in IPv6, but not in a double encapsulation like >> IPv6-in-IPv4-in-GRE). > > Mohamed>> I don't see the issue of double encapsulation, IP4-UDP-IP6 > is double encapsulation (DS-MIP6). IPv4 header (src=V4ADDR, > dst=HA_V4ADDR) UDP header IPv6 header (src=V4CoA, dst=HAADDR) DST-OPT > HAO (IPv6 home address) Mobility header BU [IPv4 HAO] That's simple encapsulation I believe, it's IPv6 packets in UDPv4 packets. One may interpret that as double encapsulation. What I mean is that if the PMIP approach relies on some deployed code that doesn't assume GRE then where would GRE necessity come from? Could you answer this? >> So in this context, can I ask why GRE? It's not used by MIPv6, was >> never suggested by DS-MIPv6, can't transport IPv6 and has several >> implemented alternatives. Why GRE? > > mohamed>> GRE is used in this draft to mark/identify traffic for a > certain classification, such as for supporting mobile nodes that are > using overlapping private IPv4 addressing. Yes, I read that in the abstract. But I don't see any NAT throughout the document. I think all other forms of IPv6-in-IPv4 (and in UDPv4) are capable to deal with the problem of overlapping private IPv4 addressing you cite in the draft. Don't you think so? Please don't get me wrong. I think many forms of tunnelling are possible and that some decisions have already been made, and that GRE tunnelling is straight competitor to the ones I've listed. A dynamic method to choose between the available methods is probably useful. But I don't see why pushing solely GRE; again, where is GRE coming from into the PMIP picture? Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 24 12:57:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgOKC-0006Z8-T0; Tue, 24 Apr 2007 12:57:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgOKB-0006Yt-Hk for mip6@ietf.org; Tue, 24 Apr 2007 12:57:07 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HgOKB-0003vv-69 for mip6@ietf.org; Tue, 24 Apr 2007 12:57:07 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-13.tower-128.messagelabs.com!1177433426!2886180!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 13670 invoked from network); 24 Apr 2007 16:50:26 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-13.tower-128.messagelabs.com with SMTP; 24 Apr 2007 16:50:26 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l3OGoPtr029320; Tue, 24 Apr 2007 09:50:25 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id l3OGoP5n021501; Tue, 24 Apr 2007 11:50:25 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id l3OGoNRl021478; Tue, 24 Apr 2007 11:50:24 -0500 (CDT) Message-ID: <462E354F.7020909@gmail.com> Date: Tue, 24 Apr 2007 18:50:23 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Sri Gundavelli Subject: Re: [Mip6] GRE key References: <62B9B0847CC47543B6B3B5E26BD268E60B5F6B3D@zrc2hxm2.corp.nortel.com> <462E2A3B.6010403@gmail.com> <018f01c7868e$c84b6210$d3f6200a@amer.cisco.com> In-Reply-To: <018f01c7868e$c84b6210$d3f6200a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000735-2, 23/04/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Sri Gundavelli wrote: > quick comments on this .... > > > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Sent: Tuesday, April 24, 2007 9:03 AM > To: Mohamed Khalil > Cc: mip6@ietf.org > Subject: Re: [Mip6] GRE key > > Mohamed Khalil wrote: >> Hi All, >> >> The following draft has been posted on netlmm, your comments and >> feedback is much appreciated. >> >> The Proxy Mobile IPv6 base specification defined in [PMIP6-ID] allows >> the mobile node's IPv4 and IPv6 traffic between the local mobility >> anchor and the mobile access gateway to be tunneled using IPv6, IPv4 >> or IPv4-UDP encapsulation headers. These encapsulation modes do not >> offer semantics for the tunnel end-points to expose a service >> identifier that can be used to identify traffic for a certain >> classification, such as for supporting mobile nodes that are using >> overlapping private IPv4 addressing. The extensions defined in this >> document allow the mobile access gateway and the local mobility >> anchor to negotiate GRE encapsulation mode and along with the GRE >> symmetric key or asymmetric keys for marking the flows, so that >> differential processing can be applied by the tunnel peers over those >> flows. > > Several reasons I believe GRE is not necessary for PMIPv6. > > Does GRE work transporting IPv6? I thought it only transports IPv4. > PMIPv6 assumes IPv6 applications first, in my understanding. > > > [Sri] 2784 does not disallow the IPv6 transport. The note in the > Appendix section just states, at that time when the spec was > written, there were no known implementation supporting GRE over > IPv6. It needs to be understood that the GRE implementations were > out there first before the spec came out and so the comment was > in that context. Cisco has GRE support over IPv6 for years and > nothing in the spec prevents that. Let me clarify this... can a Cisco router transport IPv6 _over_ IPv4 with GRE? (not IPv6 over IPv6 with GRE). I agree the spec doesn't prevent it. But it doesn't say what the Protocol Type is either (in the case of IPv6). It refers to an invalid http address. So how could one implement it? >> I think it is also obvious that PMIPv6 done in netlmm WG should >> encapsulate only once at max, not twice nor more. Ie a packet from LMA >> to MAG should only be encapsulated once (IPv6 in UDP/IPv4 or maybe IPv6 >> in IPv6, but not in a double encapsulation like IPv6-in-IPv4-in-GRE). > > [Sri] Probably the draft needs one revision to reflect the current > WG chair's decision to split the PMIP6 document. Probably, this > draft should be discussed a bit later after the current PMIP6 work > is complete, may be 2 months down the road. I somehow agree with you. >> So in this context, can I ask why GRE? It's not used by MIPv6, was >> never suggested by DS-MIPv6, can't transport IPv6 and has several >> implemented alternatives. Why GRE? > > [Sri] There are many use cases. It should be discussed later, IMO. Ok, sorry for disturbing, let's see later. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 24 13:01:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgOOM-0007lT-Dt; Tue, 24 Apr 2007 13:01:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgOOL-0007lO-D6 for mip6@ietf.org; Tue, 24 Apr 2007 13:01:25 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgOOK-0004rT-0u for mip6@ietf.org; Tue, 24 Apr 2007 13:01:25 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l3OH0eT01449; Tue, 24 Apr 2007 17:00:40 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] GRE key Date: Tue, 24 Apr 2007 12:01:18 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437113D36D8F@zrc2hxm2.corp.nortel.com> In-Reply-To: <462E3398.7000100@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] GRE key thread-index: AceGj7nMcX+sgcgKRq2ab8Qrx0yulgAAPK4A References: <62B9B0847CC47543B6B3B5E26BD268E60B5F6B4C@zrc2hxm2.corp.nortel.com> <462E3398.7000100@gmail.com> From: "Ahmad Muhanna" To: "Alexandru Petrescu" , "Mohamed Khalil" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Alex, Thanks for your comments. Please see comments inline. Regards, Ahmad =20 > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 > Sent: Tuesday, April 24, 2007 11:43 AM > To: Khalil, Mohamed (RICH2:2S20) > Cc: mip6@ietf.org > Subject: Re: [Mip6] GRE key >=20 > Mohamed Khalil wrote: > > Hi Alexandru, > >=20 > > -----Original Message----- From: Alexandru Petrescu=20 > > [mailto:alexandru.petrescu@gmail.com] Sent: Tuesday, April 24, 2007 > > 11:03 AM To: Khalil, Mohamed (RICH2:2S20) Cc: mip6@ietf.org Subject: > > Re: [Mip6] GRE key > >=20 > >=20 > > Mohamed Khalil wrote: > >> Hi All, > >>=20 > >> The following draft has been posted on netlmm, your comments and=20 > >> feedback is much appreciated. > >>=20 > >> The Proxy Mobile Ivy base specification defined in=20 > [PMIP6-ID] allows > >=20 > >> the mobile node's IPv4 and IPv6 traffic between the local=20 > mobility =20 > >> anchor and the mobile access gateway to be tunneled using IPv6, > >> IPv4 or IPv4-UDP encapsulation headers. These=20 > encapsulation modes do=20 > >> not offer semantics for the tunnel end-points to expose a service=20 > >> identifier that can be used to identify traffic for a certain=20 > >> classification, such as for supporting mobile nodes that are using=20 > >> overlapping private IPv4 addressing. The extensions=20 > defined in this=20 > >> document allow the mobile access gateway and the local mobility=20 > >> anchor > >=20 > >> to negotiate GRE encapsulation mode and along with the GRE=20 > symmetric=20 > >> key or asymmetric keys for marking the flows, so that differential=20 > >> processing can be applied by the tunnel peers over those flows. > >=20 > > Several reasons I believe GRE is not necessary for PMIPv6. > >=20 > > Does GRE work transporting IPv6? I thought it only=20 > transports IPv4.=20 > > PMIPv6 assumes IPv6 applications first, in my understanding. > >=20 > > Mohamed>> should be use to transport IP6 too. >=20 > It's true that the RFC I'm referring to is relatively old, is=20 > there an update on the GRE implementation as to show it can=20 > transport IPv6? > rfc2784 says: > > o IPv6 as Delivery and/or Payload Protocol > >=20 > > This specification describes the intersection of GRE currently=20 > > deployed by multiple vendors. IPv6 as delivery and/or=20 > payload protocol=20 > > is not included in the currently deployed versions of GRE. >=20 > Is there an update to this RFC or to this statement in this=20 > RFC? Thanks. [Ahmad] Please see Sri comments earlier. >=20 > >> PMIPv6 inherits from MIPv6 tunnelling, which is=20 > IPv6-in-IPv6 which is=20 > >> Generic Packet Tunnelling rfc2473 (not GRE); and it maybe inherits=20 > >> from DS-MIPv6 whose method of transporting IPv6 over IPv4=20 > is not yet=20 > >> clarified, but was discussed until now to be IPv6 in > >> UDPv4 (again not GRE) or maybe IPv6-in-IPv4 with protocol number 41 > >> rfc2893 (yet again not GRE). > >>=20 > >> I think it is also obvious that PMIPv6 done in netlmm WG should=20 > >> encapsulate only once at max, not twice nor more. Ie a=20 > packet from=20 > >> LMA to MAG should only be encapsulated once (IPv6 in UDP/IPv4 or=20 > >> maybe IPv6 in IPv6, but not in a double encapsulation like=20 > >> IPv6-in-IPv4-in-GRE). > > > > Mohamed>> I don't see the issue of double encapsulation, IP4-UDP-IP6 > > is double encapsulation (DS-MIP6). IPv4 header (src=3DV4ADDR, > > dst=3DHA_V4ADDR) UDP header IPv6 header (src=3DV4CoA,=20 > dst=3DHAADDR) DST-OPT =20 > > HAO (IPv6 home address) Mobility header BU [IPv4 HAO] >=20 > That's simple encapsulation I believe, it's IPv6 packets in=20 > UDPv4 packets. One may interpret that as double encapsulation. >=20 > What I mean is that if the PMIP approach relies on some=20 > deployed code that doesn't assume GRE then where would GRE=20 > necessity come from? Could you answer this? [Ahmad] The draft proposes a mechanism to negotiate GRE keys and obviously to be used whenever needed. i.e. GRE encapsulation is an optional feature. >=20 > >> So in this context, can I ask why GRE? It's not used by=20 > MIPv6, was =20 > >> never suggested by DS-MIPv6, can't transport IPv6 and has several=20 > >> implemented alternatives. Why GRE? > >=20 > > mohamed>> GRE is used in this draft to mark/identify traffic for a > > certain classification, such as for supporting mobile nodes=20 > that are=20 > > using overlapping private IPv4 addressing. >=20 > Yes, I read that in the abstract. But I don't see any NAT=20 > throughout the document. >=20 > I think all other forms of IPv6-in-IPv4 (and in UDPv4) are=20 > capable to deal with the problem of overlapping private IPv4=20 > addressing you cite in the draft. Don't you think so? >=20 > Please don't get me wrong. I think many forms of tunnelling=20 > are possible and that some decisions have already been made,=20 > and that GRE tunnelling is straight competitor to the ones=20 > I've listed. A dynamic method to choose between the=20 > available methods is probably useful. But I don't see why=20 > pushing solely GRE; again, where is GRE coming from into the=20 > PMIP picture? [Ahmad] GRE is widely deployed and used and I believe it has a use case in Proxy MIP in general. You are welcome to publish any other mechanisms that you think valuable and has a use case.=20 >=20 > Alex >=20 >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email=20 > ______________________________________________________________________ >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 24 13:20:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgOgF-00045d-Ns; Tue, 24 Apr 2007 13:19:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgOgF-00045V-5W for mip6@ietf.org; Tue, 24 Apr 2007 13:19:55 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgOgE-0001pS-QW for mip6@ietf.org; Tue, 24 Apr 2007 13:19:55 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 24 Apr 2007 10:19:54 -0700 X-IronPort-AV: i="4.14,448,1170662400"; d="scan'208"; a="55910159:sNHT63885897" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l3OHJswt024732; Tue, 24 Apr 2007 10:19:54 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l3OHJeAI006455; Tue, 24 Apr 2007 17:19:54 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Apr 2007 10:19:40 -0700 Received: from sgundavewxp ([10.32.246.211]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Apr 2007 10:19:40 -0700 From: "Sri Gundavelli" To: "'Alexandru Petrescu'" Subject: FW: [Mip6] GRE key Date: Tue, 24 Apr 2007 10:19:40 -0700 Message-ID: <019301c78694$bdff5ea0$d3f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceGkKl4zuQ8SVSSSUqyClSuGNPuQQAAVPdA X-OriginalArrivalTime: 24 Apr 2007 17:19:40.0283 (UTC) FILETIME=[BDE98CB0:01C78694] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2462; t=1177435194; x=1178299194; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20FW=3A=20[Mip6]=20GRE=20key |Sender:=20; bh=LajTgDiDbQKAV2tq4qpnUHCAZcdDmM4ahiMfLQCxd20=; b=dsqGZhlsRNEXpkqjqCBOzWrCOZdpWOkOjMT6HnwyHffUtgfemPq6Szkjpoxasrh/M7/MhsFc KeFZ6yvM+RF6exfXp+5vhfTV+QNojpM2zWLiOSZp9+CmfI40qX5eGzvi; Authentication-Results: sj-dkim-6; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Alex: Please see inline .. Sri > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Sent: Tuesday, April 24, 2007 9:50 AM > To: Sri Gundavelli > Cc: 'Mohamed Khalil'; mip6@ietf.org > Subject: Re: [Mip6] GRE key > > Sri Gundavelli wrote: > > quick comments on this .... > > > > > > Several reasons I believe GRE is not necessary for PMIPv6. > > > > Does GRE work transporting IPv6? I thought it only transports IPv4. > > PMIPv6 assumes IPv6 applications first, in my understanding. > > > > > > [Sri] 2784 does not disallow the IPv6 transport. The note in the > > Appendix section just states, at that time when the spec was > > written, there were no known implementation supporting GRE over > > IPv6. It needs to be understood that the GRE implementations were > > out there first before the spec came out and so the comment was > > in that context. Cisco has GRE support over IPv6 for years and > > nothing in the spec prevents that. > > Let me clarify this... can a Cisco router transport IPv6 _over_ IPv4 > with GRE? (not IPv6 over IPv6 with GRE). > Yes. interface tunnel 5 tunnel mode gre [ip] | [ipv6] Once the GRE mode and the transport is chosen, both IPv4 and IPv6 payloads can be carried. > I agree the spec doesn't prevent it. But it doesn't say what the > Protocol Type is either (in the case of IPv6). It refers to > an invalid > http address. So how could one implement it? > True. The protocol number for IPv6 is not explicitly specified. But, the "Protocol Type" field needs to be interpreted as its used in Ethernet frames when carrying IPv6 packets. If its needed, may be the IPv6 WG can have a 1-page write up on clarifying this. I'm sure, there are many implementations in the field and need to verify if there is an ambiguity there. Also, the use case here is is for IPv4 and IPv6 transports. > >> So in this context, can I ask why GRE? It's not used by MIPv6, was > >> never suggested by DS-MIPv6, can't transport IPv6 and has several > >> implemented alternatives. Why GRE? > > > > [Sri] There are many use cases. It should be discussed later, IMO. > > Ok, sorry for disturbing, let's see later. > No, not at all. Since, this is an extension work, closing up on the base work will clarify lot of things. So, was suggesting a discussion at a later point. Sri _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 24 13:33:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgOsu-0002mk-S8; Tue, 24 Apr 2007 13:33:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgOst-0002k1-Mk for mip6@ietf.org; Tue, 24 Apr 2007 13:32:59 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HgOst-0005hY-7S for mip6@ietf.org; Tue, 24 Apr 2007 13:32:59 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-6.tower-153.messagelabs.com!1177435977!1386443!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.9] Received: (qmail 2551 invoked from network); 24 Apr 2007 17:32:58 -0000 Received: from ftpbox.mot.com (HELO ftpbox.mot.com) (129.188.136.9) by server-6.tower-153.messagelabs.com with SMTP; 24 Apr 2007 17:32:58 -0000 Received: from az33exr03.mot.com ([10.64.251.233]) by ftpbox.mot.com (8.12.11/Motorola) with ESMTP id l3OHWvQq025644; Tue, 24 Apr 2007 12:32:57 -0500 (CDT) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id l3OHWuF6010540; Tue, 24 Apr 2007 12:32:56 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l3OHWsuJ010447; Tue, 24 Apr 2007 12:32:55 -0500 (CDT) Message-ID: <462E3F40.2060101@gmail.com> Date: Tue, 24 Apr 2007 19:32:48 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Ahmad Muhanna Subject: Re: [Mip6] GRE key References: <62B9B0847CC47543B6B3B5E26BD268E60B5F6B4C@zrc2hxm2.corp.nortel.com> <462E3398.7000100@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437113D36D8F@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437113D36D8F@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000735-2, 23/04/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Ahmad Muhanna wrote: > Hi Alex, > > Thanks for your comments. Please see comments inline. > > Regards, Ahmad > > >> -----Original Message----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@gmail.com] Sent: Tuesday, April 24, 2007 >> 11:43 AM To: Khalil, Mohamed (RICH2:2S20) Cc: mip6@ietf.org >> Subject: Re: [Mip6] GRE key >> >> Mohamed Khalil wrote: >>> Hi Alexandru, >>> >>> -----Original Message----- From: Alexandru Petrescu >>> [mailto:alexandru.petrescu@gmail.com] Sent: Tuesday, April 24, >>> 2007 11:03 AM To: Khalil, Mohamed (RICH2:2S20) Cc: mip6@ietf.org >>> Subject: Re: [Mip6] GRE key >>> >>> >>> Mohamed Khalil wrote: >>>> Hi All, >>>> >>>> The following draft has been posted on netlmm, your comments >>>> and feedback is much appreciated. >>>> >>>> The Proxy Mobile Ivy base specification defined in >> [PMIP6-ID] allows >>>> the mobile node's IPv4 and IPv6 traffic between the local >> mobility >>>> anchor and the mobile access gateway to be tunneled using IPv6, >>>> IPv4 or IPv4-UDP encapsulation headers. These >> encapsulation modes do >>>> not offer semantics for the tunnel end-points to expose a >>>> service identifier that can be used to identify traffic for a >>>> certain classification, such as for supporting mobile nodes >>>> that are using overlapping private IPv4 addressing. The >>>> extensions >> defined in this >>>> document allow the mobile access gateway and the local mobility >>>> anchor to negotiate GRE encapsulation mode and along with the >>>> GRE >> symmetric >>>> key or asymmetric keys for marking the flows, so that >>>> differential processing can be applied by the tunnel peers over >>>> those flows. >>> Several reasons I believe GRE is not necessary for PMIPv6. >>> >>> Does GRE work transporting IPv6? I thought it only >> transports IPv4. >>> PMIPv6 assumes IPv6 applications first, in my understanding. >>> >>> Mohamed>> should be use to transport IP6 too. >> It's true that the RFC I'm referring to is relatively old, is there >> an update on the GRE implementation as to show it can transport >> IPv6? rfc2784 says: >>> o IPv6 as Delivery and/or Payload Protocol >>> >>> This specification describes the intersection of GRE currently >>> deployed by multiple vendors. IPv6 as delivery and/or >> payload protocol >>> is not included in the currently deployed versions of GRE. >> Is there an update to this RFC or to this statement in this RFC? >> Thanks. > > > [Ahmad] Please see Sri comments earlier. Ok, yes, seems to be implemented to transport IPv6 in GRE with protocol number apparently 0x86dd. >>>> PMIPv6 inherits from MIPv6 tunnelling, which is >> IPv6-in-IPv6 which is >>>> Generic Packet Tunnelling rfc2473 (not GRE); and it maybe >>>> inherits from DS-MIPv6 whose method of transporting IPv6 over >>>> IPv4 >> is not yet >>>> clarified, but was discussed until now to be IPv6 in UDPv4 >>>> (again not GRE) or maybe IPv6-in-IPv4 with protocol number 41 >>>> rfc2893 (yet again not GRE). >>>> >>>> I think it is also obvious that PMIPv6 done in netlmm WG should >>>> encapsulate only once at max, not twice nor more. Ie a >> packet from >>>> LMA to MAG should only be encapsulated once (IPv6 in UDP/IPv4 >>>> or maybe IPv6 in IPv6, but not in a double encapsulation like >>>> IPv6-in-IPv4-in-GRE). >>> Mohamed>> I don't see the issue of double encapsulation, >>> IP4-UDP-IP6 is double encapsulation (DS-MIP6). IPv4 header >>> (src=V4ADDR, dst=HA_V4ADDR) UDP header IPv6 header (src=V4CoA, >> dst=HAADDR) DST-OPT >>> HAO (IPv6 home address) Mobility header BU [IPv4 HAO] >> That's simple encapsulation I believe, it's IPv6 packets in UDPv4 >> packets. One may interpret that as double encapsulation. >> >> What I mean is that if the PMIP approach relies on some deployed >> code that doesn't assume GRE then where would GRE necessity come >> from? Could you answer this? > > [Ahmad] The draft proposes a mechanism to negotiate GRE keys and > obviously to be used whenever needed. i.e. GRE encapsulation is an > optional feature. It's also true that one wouldn't negotiate any GRE key if there were no GRE encapsulation with keys fields to use these GRE keys, no? If I use IPv6-in-UDPv4 (as DS-MIPv6 suggests) then no need to negotiate GRE keys, no? GRE keys aren't used for anything else than GRE tunnels, am I right? >>>> So in this context, can I ask why GRE? It's not used by MIPv6, >>>> was never suggested by DS-MIPv6, can't transport IPv6 and has >>>> several implemented alternatives. Why GRE? >>> mohamed>> GRE is used in this draft to mark/identify traffic for >>> a certain classification, such as for supporting mobile nodes >> that are >>> using overlapping private IPv4 addressing. >> Yes, I read that in the abstract. But I don't see any NAT >> throughout the document. >> >> I think all other forms of IPv6-in-IPv4 (and in UDPv4) are capable >> to deal with the problem of overlapping private IPv4 addressing you >> cite in the draft. Don't you think so? >> >> Please don't get me wrong. I think many forms of tunnelling are >> possible and that some decisions have already been made, and that >> GRE tunnelling is straight competitor to the ones I've listed. A >> dynamic method to choose between the available methods is probably >> useful. But I don't see why pushing solely GRE; again, where is >> GRE coming from into the PMIP picture? > > [Ahmad] GRE is widely deployed and used and I believe it has a use > case in Proxy MIP in general. But GRE has nothing to do with Mobile IPv6, do you agree. It may have something to do with MIP4 (and probably PMIPv4) but nothing to do with MIP6 no? I'm surprised you propose this... and I'm sure you'll talk me into this :-) Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 24 19:37:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgUZR-0007LG-W6; Tue, 24 Apr 2007 19:37:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgUZQ-0007DC-OW for mip6@ietf.org; Tue, 24 Apr 2007 19:37:16 -0400 Received: from yskfw1.ysknet.co.jp ([210.169.255.3] helo=ksns.ks.ysknet.co.jp) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HgUZP-0007es-3i for mip6@ietf.org; Tue, 24 Apr 2007 19:37:16 -0400 Received: (qmail 23821 invoked from network); 25 Apr 2007 08:37:11 +0900 Received: from (HELO MIP6-236) (@) by with SMTP; 25 Apr 2007 08:37:11 +0900 To: mip6@ietf.org, nemo@ietf.org From: "K.Kawaguchi" Message-Id: <200704250837.FJB13097.UHVLJBXB@ysknet.co.jp> X-Mailer: Winbiff [Version 2.43 PL1] X-Accept-Language: ja,en Date: Wed, 25 Apr 2007 08:37:08 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Subject: [Mip6] [Remainder] TAHI Event Registration will be closed !! X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Dear all, This is a remainder. The Registration for TAHI Interoperability Test Event will be closed on 27th Apr (17P.M. JST). If you are planning to participate to the Event, please make a registration as soon as possible. You can make a registration on http://www.tahi.org/inop/9thinterop.html Summary information of the event. - Venue: Nippon Convention Center (Makuhari Messe), Chiba, Japan. - Date: May 14 - May 18, 2007 - Registration & Information: http://www.tahi.org/inop/9thinterop.html We are looking forward to see you at 9th TAHI evnet! Best regards --- Kiyoaki KAWAGUCHI Best regards --- Kiyoaki KAWAGUCHI _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6