From mip6-bounces@ietf.org Tue Jan 02 04:44:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1gBd-0005C0-8O; Tue, 02 Jan 2007 04:44:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1gBc-0005Bi-3j for mip6@ietf.org; Tue, 02 Jan 2007 04:44:00 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H1gBa-0008Ts-Sj for mip6@ietf.org; Tue, 02 Jan 2007 04:44:00 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-15.tower-119.messagelabs.com!1167731038!17455102!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 5594 invoked from network); 2 Jan 2007 09:43:58 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-15.tower-119.messagelabs.com with SMTP; 2 Jan 2007 09:43:58 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l029hwdm022907; Tue, 2 Jan 2007 02:43:58 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id l029huhe029577; Tue, 2 Jan 2007 03:43:57 -0600 (CST) Message-ID: <459A295C.5000005@motorola.com> Date: Tue, 02 Jan 2007 10:43:56 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [Mip6] Non-tunnelled Echo Req MN to HA References: <45941828.6050803@azairenet.com> <45950851.1080706@motorola.com> <45956328.9090306@azairenet.com> In-Reply-To: <45956328.9090306@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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 Vijay Devarapalli wrote: > Alexandru Petrescu wrote: >> Vijay Devarapalli wrote: >>> Mondemu Sreenivasulu-A21119 wrote: >>>> Sorry, The small correction. It is not very clear from RFC 3775 >>>> whether it is a expected scenario. >>> >>> RFC 3775 requires the HA to send the Echo Reply back with a >>> routing header if the Echo request had the home address option. >> >> Yes, that's fine, 3775 clear on that. >> >> But does 3775 require the _HA_ to send a Binding Error to MN if it >> received an EchoReq with DO whose HoA is not in its BC? The TAHI >> certification tests seem to require this. > > No. The Binding Error message is sent only the CN. The TAHI test is > valid only if your HA is also a CN. Ok, so a HA not sending Binding Error to a MN it serves would still be TAHI-conformant? >> 3775 does require the _CN_ to do so. Would HA also send Binding >> Errors when EchoReq DO's has a HoA not present its BC? >> >> The 3775 Binding Error text seems to be only about CN, not HA. >> >> This again is a very needed clarification for anybody implementing >> an HA. This clarification is needed together with clarification >> whether HA sends Binding Refresh Request or not (3775 says CN >> does). > > If your HA implementation is strictly a home agent and does not > behave like a CN for a mobile node that it does not serve, then you > don't have to implement the Binding Error message. > > If your HA implementation behaves like a CN for a mobile node that it > does not serve, then it must send a Binding Error message to the > mobile node when it receives a packet with a home address option and > there is no corresponding binding cache entry. Makes sense. I mean a HA that does serve the MN and that is pinged by that MN. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jan 02 08:13:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1jSG-0007iv-FF; Tue, 02 Jan 2007 08:13:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1jSF-0007io-6J for mip6@ietf.org; Tue, 02 Jan 2007 08:13:23 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1jSE-00065x-CN for mip6@ietf.org; Tue, 02 Jan 2007 08:13:23 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 3A66B898C8; Tue, 2 Jan 2007 15:13:16 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id D9FA8898C6; Tue, 2 Jan 2007 15:13:15 +0200 (EET) Message-ID: <459A5A6C.5070602@piuha.net> Date: Tue, 02 Jan 2007 15:13:16 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.8 (X11/20061117) MIME-Version: 1.0 To: Mobile IPv6 Mailing List , Giaretta Gerardo Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e267523e0685e5aa2dbbdde4b659686 Cc: Subject: [Mip6] AD review of draft-ietf-mip6-bootstrapping-split 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, I have reviewed this specification. Overall, I like the basic approach and this will be very useful. The document is generally in good shape. However, there are a few technical issues that need to be resolved before we can move forward. In particular, the authorization steps need to be specified in greater detail, and I also had question marks about the particular approach to anycast. Also, I have asked the DNS directorate to review the DNS-relevant parts. Please find the detailed comments below: Technical: > This > implies that the mobility service is bootstrapped independently > from the authentication protocol for network access used (e.g. > PANA, EAP). Perhaps you should allow for the possibility that there is no access authorization. Suggested edit: "... from the security mechanisms used for network access (e.g., EAP or even open access) > Additionally, the ability to provide a mobile node with a > localized home agent (e.g. on the visited link) can help to > optimize handover signaling and improve routing efficiency in bi- > directional tunneling mode. There are a variety of ways this can > be achieved in an interoperable way. One way is to provision the > mobile node with an FQDN for a local home agent when it configures > for the local link. Another way is to specify an interoperable > naming convention for constructing home agent FQDNs based on > location. For example, an operator might assign the FQDN > "ha.locationA.operator.com" to the Home Agent located in "location > A" and the FQDN "ha.locationB.operator.com" to the Home Agent > located in "location B". If the Mobile Node wants to use a Home > Agent located in "location A", it will set the QNAME to > "ha.locationA.operator.com" in the DNS request. The exact way in > which localized Home Agents are configured is out of scope for > this draft. This part is rather handwavy. I could not implement anything interoperable based on it. I realize that we debated this in 2005, based on my earlier review of the same document. From the mailing list discussion that I went through, it seemed that there was some support in the WG for keeping the local assignments out of scope. Here's a suggested rewrite: Note that the configuration of a fixed home agent FQDN does allow dynamic assignment of a localized home agent. Such dynamic assignment would be useful, however, for instance from the point of view of improving routing efficiency in bidirectional tunneling mode. Enhancements or conventions for dynamic assignment are possible, but are outside the scope of this specification. > If an anycast address is returned in response to DNS resolution of > an FQDN, the IKEv2 transaction between the Mobile Node and Home > Agent is slightly modified. The Mobile Node sends the IKE_SA_INIT > request to the anycast address. The node which has the anycast > address assigned to one of its network interfaces selects a Home > Agent address from the set of Home Agents managed by the node, and > forwards the IKE_SA_INIT. If the set of Home Agents is empnty, the > node simply drops the packet. The Home Agent answers using its own > address, and includes an "under attack" cookie, in accordance with > RFC 4306 [7]. The Mobile Node notes the Home Agent address and > resends the IKE_SA_INIT message to the Home Agent, along with the > cookie. There are several issues in this. First, I think I understand at least one reason why the cookie exchange makes sense, but is that something that has to be mandated? What if the home network simply figures out what HA should be used and responds in the usual IKEv2 way? Secondly, responding with the home agent's own address is in violation of a MUST in RFC 4306, Section 2.11. I talked to one of the IKEv2 designers about this and his advice was that the MUST may have been a mistake. Or at least it should be limited to unicast addresses, and leave the behaviour for anycast addresses for future documents. In any case, this deviation from RFC 4306 should be highlighted and justified in the document. The third issue is the above notion of a node that owns an anycast address. How does this relate to the usual arrangement where the routing system handles the delivery of the anycast packets to the "closest" place that advertises that address? When you say "forwards", do you mean that the packet is forwarded unmodified, or that the particular home agent's address replaces the destination address? Do you allow each home agent to configure the same anycast address? Four: What happens when the IKE SA dies or is deleted, but a binding for the mobile node remains in the selected home agent? Will the mobile node re-establish the IKE SA using the anycast address, or the address of the selected home agent? Finally, I wonder how useful the anycast part of this spec is given that DNS can already provide a set of addresses. > o MN identity - the identity of the Mobile Node to be used by the > Home Agent to send a Dynamic DNS update. It is a variable > length field. What format is this in? Please specify. > The Home Agent MUST set up authorization by linking the home > address to the identity of the IPsec SAs used to authenticate the > Binding Update message. The linking MUST be done either during the > IKE_AUTH phase or CREATE_CHILD_SA phase when the IPsec SAs are > constructed. > > If the address is auto-configured, RFC 3775 requires the Home > Agent to proxy-defend the address on the home link after the > Mobile Node performs the initial Binding Update. Since it is not > currently possible to securely proxy CGAs using SEND, attacks on > address resolution for Neighbor Discovery listed in RFC 3756 are > possible on dynamically assigned home addresses that are proxied > by the Home Agent. I do not know what to implement based on the above description. Its clear that a link must be established between the IKE identity and the requested home address. But how? What should be done with the information about the link? By the way, why does the text say "identity of the IPsec SAs"? I believe you should talk about the identity used in the IKEv2 authentication process. There are other reasons beyond lack of SEND proxy mode that make the use of DAD for authorization bad. Its not reliable, not all nodes may be on or reachable at all times, etc. Here's a possible rewrite of the text. Let me know if this is what you intended to do: "The home agent MUST authorize each home address allocation and use. This authorization is based on linking the mobile node identity used in the IKEv2 authentication process and the home address. Home agents MUST support at least the following two modes of authorization: o Configured home address(es) for each mobile node. In this mode, the home agent or infrastructure nodes behind it know what addresses a specific mobile node is authorized to use. The mobile node is allowed to request these addresses, or if the mobile node requests any home address, these addresses are returned to it. o First-come-first-served (FCFS). In this mode, the home agent maintains a pool of "used" addresses, and allows mobile nodes to request any address, as long as it is not used by another mobile node. Addresses MUST be marked as used for at least as long as the binding exists, and are associated with the identity of the mobile node that made the allocation. In addition, the home agent MUST ensure that the requested address is not the authorized address of any other mobile node, if both FCFS and configured modes use the same address space." > Mobile IPv6 bootstrapping recommends the Home Agent to update the > Mobile Node's FQDN with a dynamically assigned home address rather > than have the Mobile Node itself do it (see Section 6 above). This > choice was motivated by a concern for preventing redirection-based > flooding attacks (see draft-ietf-mip6-ro-sec [21] for more > information about redirection-based flooding attacks and the role > preventing them played in the design of Mobile IPv6 route > optimization security). Exactly as for route optimization, it is > possible for a node that is the legitimate owner of a DNS FQDN - > in the sense that it has a security association with the DNS > server allowing it to perform dynamic DNS update of its FQDN - to > bind its FQDN to the address of a victim, then redirect large > volumes of traffic at the victim. The attack may be propagated > without the owner's knowledge, for example, if the node is > compromised by malware, or it may be intentional if the node > itself is the attacker. > > While it is possible to prevent redirection attacks through > ingress filtering on access routers, ISPs have little or no > incentive to deploy ingress filtering. In some cases, if an attack > could result in substantial financial gain, it is even possible > that a corrupt ISP may have an incentive not to deploy ingress > filters such as has been the case for spam. Consequently, the > security for dynamic Mobile Node FQDN update has been assigned to > the Home Agent, where active network administration and vigilant > defense measures are more likely to (but are not assured of) > mitigating problems, and the owner of the Mobile Node is more > likely to detect a problem if it occurs. There are good reasons why using a proxy to do the DynDNS update from your behalf makes sense. But I don't think the above is such a good reason. The route optimization redirect problem assumes that traffic from an ongoing session is suddenly moved to a new address. If you just change the DNS information, ongoing sessions are not affected, and all new sessions go through the usual TCP slow start etc. (A good reason why it makes sense to use a proxy is that then you just need a secret between the DNS server and the home agent, not between the DNS server and every mobile node.) > Notice that if certificates are used in > IKEv2, the authorization information about the FQDN for DNS update > MUST be present in the certificate provided by the Mobile Node. Yes -- but can you write this in more explicit form? For instance, I assume that you meant the FQDN must appear in some specific field in the certificate. > Regardless of whether the AAA server or Home Agent performs DNS > update, the authorization of the Mobile Node to update a FQDN MUST > be checked prior to the performance of the update. It is an > implementation issue as to how authorization is determined. > However, in order to allow this authorization step, the Mobile > Node MUST use a FQDN as the IDi in IKE_AUTH step of the IKEv2 > exchange. The FQDN MUST be the same that will be provided by the > Mobile Node in the DNS Update Option. This allows the Home Agent > to get authorization information about the Mobile Node's FQDN via > the AAA back end communication performed during IKEv2 exchange. > The outcome of this step will give the Home Agent the necessary > information to authorize the DNS update request of the Mobile > Node. See draft-ietf-mip6-aaa-ha-goals [14] for details about the > communication between the AAA server and the Home Agent needed to > perform the authorization. Notice that if certificates are used in > IKEv2, the authorization information about the FQDN for DNS update > MUST be present in the certificate provided by the Mobile Node. This is another case where I believe the important authorization step is underspecified, and needs to be specified in more detail to make sure people actually can implement it. And that they will get it right. Also, I am unsure if the requirement to use the FQDN in the IKEv2 exchange is helpful. If an FQDN X is used in the IKEv2 exchange, but the actual authentication employs IKEv2/EAP with a method that does its own identity exchange with FQDN Y, what happens? Also, you are preventing privacy NAI usage in the IKEv2 exchange. And if you use a FQDN (no "@", i.e., not a NAI) in the IKEv2 identity, how will the gateway be able to route the AAA request? One alternative approach would be to require the following: - If certificates are used, then the FQDN must appear there (but see my previous comment). - Otherwise, the mobile node's identity is taken as asserted in the EAP method where available and otherwise from the IKEv2 exchange. - Home agent must be able to match mobile node identities to allowed FQDNs. For certs, step 1 above suffices. In other cases its basically configured information. - The division of work between the home agent and AAA is outside the scope of this document. Note that there may be non-trivial issues, such as when the actual identity is end-to-end hidden between the mobile node and the AAA server. Editorial: > mobility service.. s/.././ > MSP. Figure 3 illustrates. s/illustrates/illustrates this/ > forwards the IKE_SA_INIT. If the set of Home Agents is empnty, the Typo > o Home Prefix (16 octets) - The prefix of the home link through > which the Mobile Node must auto-configure its Home Address. s/must/may/ -- there can be multiple such prefixes, so the mobile node cannot be mandated to use _this_ prefix. Alternatively, you can explain that the use of a particular prefix or auto-configuration is optional, but that if autoconfiguration is used, then one of the provided prefixes must be used. > Security considerations for discovering HA using DHCP are covered > in draft-jang-dhc-haopt-01 [15]. > [15] Koodli, R., Devarapalli, V., Perkins, C., Flinck, H., > "Solutions for IP Address Location Privacy in the presence > of IP Mobility", Internet-Draft, draft-koodli-mip6-location- > privacy-solutions-00, February 2005. I suppose referring to draft-jang is no longer necessary, if the contents are being moved to a MIP6 WG item draft. Also, the draft name and reference number do not match. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jan 02 15:50:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1qaQ-0004gt-Da; Tue, 02 Jan 2007 15:50:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1qaA-0004E9-ND; Tue, 02 Jan 2007 15:50:02 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1qaA-0002Sw-CN; Tue, 02 Jan 2007 15:50:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 56A1A328DA; Tue, 2 Jan 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H1qaA-0002n6-7F; Tue, 02 Jan 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 02 Jan 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: mip6@ietf.org Subject: [Mip6] I-D ACTION:draft-ietf-mip6-hiopt-01.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 : DHCP Option for Home Information Discovery in MIPv6 Author(s) : H. Jang, et al. Filename : draft-ietf-mip6-hiopt-01.txt Pages : 16 Date : 2007-1-2 This draft defines a DHCP-based scheme to enable dynamic discovery of Mobile IPv6 home agent address, home address, and home subnet. New DHCP options are defined to carry the information from a DHCP server to the DHCP client running on the mobile node. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-hiopt-01.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-hiopt-01.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-hiopt-01.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-1-2121334.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-hiopt-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-hiopt-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-2121334.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 Wed Jan 03 00:33:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1ykE-0007Xc-I7; Wed, 03 Jan 2007 00:32:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1ykC-0007Wu-Ld for mip6@ietf.org; Wed, 03 Jan 2007 00:32:56 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H1ykB-0004rd-AF for mip6@ietf.org; Wed, 03 Jan 2007 00:32:56 -0500 X-VirusChecked: Checked X-Env-Sender: msreeni@motorola.com X-Msg-Ref: server-13.tower-128.messagelabs.com!1167802370!12155359!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 841 invoked from network); 3 Jan 2007 05:32:50 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-13.tower-128.messagelabs.com with SMTP; 3 Jan 2007 05:32:50 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l035WnU2021755 for ; Tue, 2 Jan 2007 22:32:50 -0700 (MST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id l035WmS9004003 for ; Tue, 2 Jan 2007 23:32:49 -0600 (CST) 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] Non-tunnelled Echo Req MN to HA Date: Wed, 3 Jan 2007 13:32:42 +0800 Message-ID: In-Reply-To: <459A295C.5000005@motorola.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Non-tunnelled Echo Req MN to HA thread-index: AccuUogXPAfhh2ZjTdCoQVIy8FkYUAApbFig From: "Mondemu Sreenivasulu-A21119" To: "Petrescu Alexandru-AAP021" , "Vijay Devarapalli" X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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 Vijay & Alex, HA has to send Binding error message when it gets unrecognized MH type. Here I am cut and pasting the RFC statement "o The MH Type field MUST have a known value (Section 6.1.1). Otherwise, the node MUST discard the message and issue a Binding Error message as described in Section 9.3.3, with Status field set to 2 (unrecognized MH Type value). Thanks & regards Sreeni=20 -----Original Message----- From: Petrescu Alexandru-AAP021=20 Sent: Tuesday, January 02, 2007 3:14 PM To: Vijay Devarapalli Cc: Mondemu Sreenivasulu-A21119; mip6@ietf.org Subject: Re: [Mip6] Non-tunnelled Echo Req MN to HA Vijay Devarapalli wrote: > Alexandru Petrescu wrote: >> Vijay Devarapalli wrote: >>> Mondemu Sreenivasulu-A21119 wrote: >>>> Sorry, The small correction. It is not very clear from RFC 3775 =20 >>>> whether it is a expected scenario. >>>=20 >>> RFC 3775 requires the HA to send the Echo Reply back with a routing=20 >>> header if the Echo request had the home address option. >>=20 >> Yes, that's fine, 3775 clear on that. >>=20 >> But does 3775 require the _HA_ to send a Binding Error to MN if it =20 >> received an EchoReq with DO whose HoA is not in its BC? The TAHI =20 >> certification tests seem to require this. >=20 > No. The Binding Error message is sent only the CN. The TAHI test is=20 > valid only if your HA is also a CN. Ok, so a HA not sending Binding Error to a MN it serves would still be TAHI-conformant? >> 3775 does require the _CN_ to do so. Would HA also send Binding=20 >> Errors when EchoReq DO's has a HoA not present its BC? >>=20 >> The 3775 Binding Error text seems to be only about CN, not HA. >>=20 >> This again is a very needed clarification for anybody implementing an >> HA. This clarification is needed together with clarification whether >> HA sends Binding Refresh Request or not (3775 says CN does). >=20 > If your HA implementation is strictly a home agent and does not behave > like a CN for a mobile node that it does not serve, then you don't=20 > have to implement the Binding Error message. >=20 > If your HA implementation behaves like a CN for a mobile node that it > does not serve, then it must send a Binding Error message to the=20 > mobile node when it receives a packet with a home address option and=20 > there is no corresponding binding cache entry. Makes sense. I mean a HA that does serve the MN and that is pinged by that MN. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jan 03 01:21:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1zUz-0005Cj-Lr; Wed, 03 Jan 2007 01:21:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1zUx-00059B-Ou for mip6@ietf.org; Wed, 03 Jan 2007 01:21:15 -0500 Received: from mail2.azairenet.com ([66.92.223.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1zUw-0004P4-EG for mip6@ietf.org; Wed, 03 Jan 2007 01:21:15 -0500 Received: from [127.0.0.1] ([66.92.223.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Jan 2007 22:21:13 -0800 Message-ID: <459B4B56.9000707@azairenet.com> Date: Tue, 02 Jan 2007 22:21:10 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Mondemu Sreenivasulu-A21119 Subject: Re: [Mip6] Non-tunnelled Echo Req MN to HA References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Jan 2007 06:21:13.0138 (UTC) FILETIME=[5DF76120:01C72EFF] X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: mip6@ietf.org, Petrescu Alexandru-AAP021 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 Sreeni, Mondemu Sreenivasulu-A21119 wrote: > Hi Vijay & Alex, > > HA has to send Binding error message when it gets unrecognized MH type. > Here I am cut and pasting the RFC statement > > "o The MH Type field MUST have a known value (Section 6.1.1). > Otherwise, the node MUST discard the message and issue a Binding > Error message as described in Section 9.3.3, with Status field set > to 2 (unrecognized MH Type value). You are correct. The HA does send the binding error when it with status field set to 2. But it does not send a Binding error with status field set to 1, unless it is a CN for a mobile node that it does not serve. We were discussing the HA receiving a data packet with a home address option with no corresponding binding cache entry for the home address. Vijay > > Thanks & regards > Sreeni > > -----Original Message----- > From: Petrescu Alexandru-AAP021 > Sent: Tuesday, January 02, 2007 3:14 PM > To: Vijay Devarapalli > Cc: Mondemu Sreenivasulu-A21119; mip6@ietf.org > Subject: Re: [Mip6] Non-tunnelled Echo Req MN to HA > > Vijay Devarapalli wrote: >> Alexandru Petrescu wrote: >>> Vijay Devarapalli wrote: >>>> Mondemu Sreenivasulu-A21119 wrote: >>>>> Sorry, The small correction. It is not very clear from RFC 3775 >>>>> whether it is a expected scenario. >>>> RFC 3775 requires the HA to send the Echo Reply back with a routing >>>> header if the Echo request had the home address option. >>> Yes, that's fine, 3775 clear on that. >>> >>> But does 3775 require the _HA_ to send a Binding Error to MN if it >>> received an EchoReq with DO whose HoA is not in its BC? The TAHI >>> certification tests seem to require this. >> No. The Binding Error message is sent only the CN. The TAHI test is >> valid only if your HA is also a CN. > > Ok, so a HA not sending Binding Error to a MN it serves would still be > TAHI-conformant? > >>> 3775 does require the _CN_ to do so. Would HA also send Binding >>> Errors when EchoReq DO's has a HoA not present its BC? >>> >>> The 3775 Binding Error text seems to be only about CN, not HA. >>> >>> This again is a very needed clarification for anybody implementing an > >>> HA. This clarification is needed together with clarification whether > >>> HA sends Binding Refresh Request or not (3775 says CN does). >> If your HA implementation is strictly a home agent and does not behave > >> like a CN for a mobile node that it does not serve, then you don't >> have to implement the Binding Error message. >> >> If your HA implementation behaves like a CN for a mobile node that it > >> does not serve, then it must send a Binding Error message to the >> mobile node when it receives a packet with a home address option and >> there is no corresponding binding cache entry. > > Makes sense. I mean a HA that does serve the MN and that is pinged by > that MN. > > Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jan 03 06:15:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H244v-0002pX-43; Wed, 03 Jan 2007 06:14:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H244u-0002pO-2d for mip6@ietf.org; Wed, 03 Jan 2007 06:14:40 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H244p-0003FT-DP for mip6@ietf.org; Wed, 03 Jan 2007 06:14:40 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 7CE6C898D3; Wed, 3 Jan 2007 13:14:31 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 1DDA3898D2; Wed, 3 Jan 2007 13:14:31 +0200 (EET) Message-ID: <459B9019.8030301@piuha.net> Date: Wed, 03 Jan 2007 13:14:33 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.8 (X11/20061117) MIME-Version: 1.0 To: Francis Dupont , 'COMBES Jean-Michel RD-MAPS-ISS' Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Cc: Mobile IPv6 Mailing List Subject: [Mip6] re-review of mip6-cn-ipsec 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, I finally found time to come back to this document. Sorry for the delay. I like the new applicability statement and other changes you made in the draft. However, there are still some issues from my previous review that were not addressed, including for instance the normative references, negotiation of how this mechanism is turned on, and a more detailed explanation of the security implications of this mechanism. Details later in this e-mail. Also, as I went through the draft I wrote some edits that would satisfy my review and let this draft move forward. Feel free to use these as a starting point or make your own edits; they are provided as suggestions only: http://www.arkko.com/reviews/mip6/cn-ipsec-03-edits.txt http://www.arkko.com/reviews/mip6/cn-ipsec-03-edits-from-draft-ietf-mip6-cn-ipsec-03.diff.html Technical: > - when an alternate care-of address option is present and is not > checked using the state cookie mechanism [COOKIE], the alternate > care-of address MUST match the source address in the IP header or > the home address itself. Any binding update which does not > fulfill this requirement MUST be rejected. > - no care-of address test is required when ingress filtering can > reject fake care-of addresses from a rogue mobile node but a > correspondent node can use the return routability state cookie > procedure to get extra insurance as well as for the support of > real alternate care-of addresses. We already talked about this... I would suggest deleting the part about the cookie mechanism. This allows your draft to become an RFC without this IMHO normative reference. (And if/when you publish another RFC on the cookie mechanism, its OK for that draft to update this RFC. And I am willing to AD sponsor documents in this space. But I'd like to do that on a document-by-document basis, not by approving one document that points to all the others.) In any case, my suggested edits contain a new section about possible enhancements, with pointers to some ideas. This would be OK. > When the home address is bound to a public key, for instance when the > home address is a Cryptographically Generated Addresses [RFC3972], > the strong authentication MAY be replaced by an address ownership > proof as described for instance in [IKECGA]. As above. > IPsec is far more secure than the return routability procedure, thus > it should be used where it is applicable. So this document can > increase at least the overall security of Mobile IPv6. This document should specify how IPsec is better or different, not simply state its better. My suggested edits have one attempt at such a description. Semi-technical: > In binding updates the new requirements are: > - the H (home registration) and K (key management mobility > capability) bits MUST be cleared. The former does not appear to be a new requirement. Suggest deleting the entry, and stating later in the same section "The use of the K (key management mobility capability) bit with correspondent nodes is not defined. This bit is always set to zero." > - as ESP can only protect the payload, an alternate care-of address > option MUST be used in conjunction with ESP (cf. [RFC3775] section > 11.7.1). This is another requirement that is not new. Delete the item. > - "long" lifetime compatible with the IPsec policy (i.e., by default > up to the IPsec security association lifetime) MAY be granted. Perhaps you should classify this as something else than a new requirement, e.g., place it after the list and formulate as: "Note that a relatively "long" lifetime compatible with the IPsec policy (i.e., by default up to the IPsec security association lifetime) MAY be granted." > - in order to avoid granting any extra privilege by a side effect of > using IPsec, the peers (i.e., the mobile and correspondent nodes) > may restrict the traffic selectors to the protection of mobility > signaling only. This should be applied to any dubious cases, > including by default when security administration is known to be > too light. I still do not understand this. Furthermore, it seems to argue against the situation that you assumed in the applicability statement. That is, you use this method when you would be using IPsec anyway for some other reason. > When a packet carrying a home address option is protected by a > > suitable IPsec security association, the home address option SHOULD > > be considered valid. > > > I think there should be a discussion somewhere (perhaps Section 2) > about the type of SA creation procedure and trust that is required > to make the above decision. See RFC 4449 Section 2 first two bullet > items for an example, and consider saying something about whether > this mechanism is applicable with BTNS or opportunistic IPsec. > > The implications may also be different for triangular routing > and route optimization. It seems that all we need for triangular > routing is that the original address (the one that you send > traffic back to) was used in the IKE exchange. That is, a dynamic > SA is needed, but it can be of any type. For route optimization, > we'd like to know and trust the entity at the other end. > This comment from my previous review has not been addressed. > In binding updates the new requirements are: > > > I would like to understand what happens when the peers use RFC 3775 > while at the same time for other reasons use IPsec between themselves, > and ONE (not both) support the mechanism specified here. How do they > know what they should do? Is there a missing negotiation step somewhere? > As above. > If you cut away the state cookie reference (as suggested earlier), > I would suggest that you include a statement similar to RFC 4449 > about the trust needed to take care-of addresses without verifying > them. As above. Editorial: > But any stronger mechanism (i.e., more secure than the > return routability procedure) may be used, including of course IPsec > (cf. [RFC3775] Appendix 3 "New Authorization Methods"). For readability, you should rewrite this as "This document defines an alternative mechanism based on strong authentication and IPsec." > The purpose of this document is not to replace the [RFC3775] return > routability procedure by the use of IPsec/IKE which has some > authentication requirements which make its universal deployment more > than unrealistic. Again for readability, change to The purpose of this document is not to replace the [RFC3775] return routability procedure by the use of IPsec/IKE. It is unrealistic to expect credentials to be available for strong authentication between any pair of communication hosts. Finally, the document should be checked for correct capitalization of terms (such as message names) from RFC 3775. Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jan 03 10:56:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H28Sp-0006qp-Li; Wed, 03 Jan 2007 10:55:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H28So-0006pA-7O for mip6@ietf.org; Wed, 03 Jan 2007 10:55:38 -0500 Received: from web60324.mail.yahoo.com ([209.73.178.132]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H28Sl-0000Jh-Dj for mip6@ietf.org; Wed, 03 Jan 2007 10:55:38 -0500 Received: (qmail 98649 invoked by uid 60001); 3 Jan 2007 15:55:34 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=JU6hrL/wByQNU2lRfTtgRKFg/QIgKeANAry/l1nlk/wFloPC7s6dsvfVDbnXZuhl6/EMgW54YP1VyGwiWqr1Dw6SYkriIptibsZT915Suywm3bavwTzgQtglNW0mENcEuZ/8RnOMyLbQFuKBmjzM9ruUTrqA2RdAU3tF815w7AY= ; Message-ID: <20070103155534.98647.qmail@web60324.mail.yahoo.com> Received: from [12.129.211.52] by web60324.mail.yahoo.com via HTTP; Wed, 03 Jan 2007 07:55:34 PST Date: Wed, 3 Jan 2007 07:55:34 -0800 (PST) From: Behcet Sarikaya Subject: Re: [Mip6] re-review of mip6-cn-ipsec To: Jari Arkko , Francis Dupont , COMBES Jean-Michel RD-MAPS-ISS MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 27ec2ff0f5c3b18b49c722f4f1748838 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="===============0957205175==" Errors-To: mip6-bounces@ietf.org --===============0957205175== Content-Type: multipart/alternative; boundary="0-522313438-1167839734=:97671" --0-522313438-1167839734=:97671 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable Hi all,=0A Glancing through this draft, I noticed the following:=0ABy just= setting up an IPsec SA with the CN, the MN is able to send=0A packets di= rectly to the CN, i.e., triangular routing is enabled. =0A=0Ashouldn't it s= ay the triangular routing is disabled?=0A=0ARegards,=0A=0A--behcet=0A=0A---= -- Original Message ----=0AFrom: Jari Arkko =0ATo: Fr= ancis Dupont ; COMBES Jean-Michel RD-MAPS-ISS =0ACc: Mobile IPv6 Mailing List =0ASent: Wednesday, January 3, 2007 5:14:33 AM=0ASubject: [Mip6] re-revi= ew of mip6-cn-ipsec=0A=0A=0AHi all,=0A=0AI finally found time to come back = to this document.=0ASorry for the delay.=0A=0AI like the new applicability = statement and other=0Achanges you made in the draft. However, there=0Aare s= till some issues from my previous review=0Athat were not addressed, includi= ng for instance=0Athe normative references, negotiation of how=0Athis mecha= nism is turned on, and a more detailed=0Aexplanation of the security implic= ations of this=0Amechanism. Details later in this e-mail.=0A=0AAlso, as I w= ent through the draft I wrote some=0Aedits that would satisfy my review and= let this=0Adraft move forward. Feel free to use these=0Aas a starting poin= t or make your own edits;=0Athey are provided as suggestions only:=0A=0Ahtt= p://www.arkko.com/reviews/mip6/cn-ipsec-03-edits.txt=0Ahttp://www.arkko.com= /reviews/mip6/cn-ipsec-03-edits-from-draft-ietf-mip6-cn-ipsec-03.diff.html= =0A=0ATechnical:=0A> - when an alternate care-of address option is pres= ent and is not=0A> checked using the state cookie mechanism [COOKIE],= the alternate=0A> care-of address MUST match the source address in t= he IP header or=0A> the home address itself. Any binding update whic= h does not=0A> fulfill this requirement MUST be rejected.=0A> - n= o care-of address test is required when ingress filtering can=0A> rej= ect fake care-of addresses from a rogue mobile node but a=0A> corresp= ondent node can use the return routability state cookie=0A> procedure= to get extra insurance as well as for the support of=0A> real altern= ate care-of addresses.=0AWe already talked about this...=0A=0AI would sugge= st deleting the part about the cookie mechanism.=0AThis allows your draft t= o become an RFC without this IMHO normative=0Areference. (And if/when you p= ublish another RFC on the cookie=0Amechanism, its OK for that draft to upda= te this RFC. And I am=0Awilling to AD sponsor documents in this space. But = I'd like to=0Ado that on a document-by-document basis, not by approving=0Ao= ne document that points to all the others.)=0A=0AIn any case, my suggested = edits contain a new=0Asection about possible enhancements, with pointers=0A= to some ideas. This would be OK.=0A> When the home address is bound to a= public key, for instance when the=0A> home address is a Cryptographical= ly Generated Addresses [RFC3972],=0A> the strong authentication MAY be r= eplaced by an address ownership=0A> proof as described for instance in [= IKECGA].=0AAs above.=0A=0A> IPsec is far more secure than the return rou= tability procedure, thus=0A> it should be used where it is applicable. = So this document can=0A> increase at least the overall security of Mobil= e IPv6.=0AThis document should specify how IPsec is better or=0Adifferent, = not simply state its better.=0A=0AMy suggested edits have one attempt at su= ch=0Aa description.=0A=0ASemi-technical:=0A> In binding updates the new re= quirements are:=0A> - the H (home registration) and K (key management m= obility=0A> capability) bits MUST be cleared.=0AThe former does not a= ppear to be a new requirement. Suggest=0Adeleting the entry, and stating la= ter in the same section=0A"The use of the K (key management mobility capabi= lity)=0Abit with correspondent nodes is not defined. This bit=0Ais always s= et to zero."=0A=0A> - as ESP can only protect the payload, an alternate= care-of address=0A> option MUST be used in conjunction with ESP (cf.= [RFC3775] section=0A> 11.7.1).=0AThis is another requirement that is= not new. Delete the=0Aitem.=0A> - "long" lifetime compatible with the = IPsec policy (i.e., by default=0A> up to the IPsec security associati= on lifetime) MAY be granted.=0APerhaps you should classify this as somethin= g else=0Athan a new requirement, e.g., place it after the list=0Aand formul= ate as:=0A=0A"Note that a relatively "long" lifetime compatible with the IP= sec policy=0A(i.e., by default up to the IPsec security association lifetim= e) MAY=0Abe granted."=0A> - in order to avoid granting any extra privil= ege by a side effect of=0A> using IPsec, the peers (i.e., the mobile = and correspondent nodes)=0A> may restrict the traffic selectors to th= e protection of mobility=0A> signaling only. This should be applied = to any dubious cases,=0A> including by default when security administ= ration is known to be=0A> too light.=0AI still do not understand this= . Furthermore, it seems to=0Aargue against the situation that you assumed i= n the=0Aapplicability statement. That is, you use this method=0Awhen you wo= uld be using IPsec anyway for some other=0Areason.=0A=0A> When a packet car= rying a home address option is protected by a=0A> > suitable IPsec secur= ity association, the home address option SHOULD=0A> > be considered vali= d.=0A> =0A>=0A> I think there should be a discussion somewhere (perhaps S= ection 2)=0A> about the type of SA creation procedure and trust that is req= uired=0A> to make the above decision. See RFC 4449 Section 2 first two bull= et=0A> items for an example, and consider saying something about whether=0A= > this mechanism is applicable with BTNS or opportunistic IPsec.=0A>=0A> Th= e implications may also be different for triangular routing=0A> and route o= ptimization. It seems that all we need for triangular=0A> routing is that t= he original address (the one that you send=0A> traffic back to) was used in= the IKE exchange. That is, a dynamic=0A> SA is needed, but it can be of an= y type. For route optimization,=0A> we'd like to know and trust the entity = at the other end.=0A> =0AThis comment from my previous review has not=0Ab= een addressed.=0A=0A> In binding updates the new requirements are:=0A> = =0A>=0A> I would like to understand what happens when the peers use RFC 377= 5=0A> while at the same time for other reasons use IPsec between themselves= ,=0A> and ONE (not both) support the mechanism specified here. How do they= =0A> know what they should do? Is there a missing negotiation step somewher= e?=0A> =0AAs above.=0A=0A> If you cut away the state cookie reference (as= suggested earlier),=0A> I would suggest that you include a statement simil= ar to RFC 4449=0A> about the trust needed to take care-of addresses without= verifying=0A> them.=0AAs above.=0A=0A=0AEditorial:=0A=0A> But any stronger= mechanism (i.e., more secure than the=0A> return routability procedure) ma= y be used, including of course IPsec=0A> (cf. [RFC3775] Appendix 3 "New Aut= horization Methods").=0AFor readability, you should rewrite this as "This d= ocument=0Adefines an alternative mechanism based on strong authentication= =0Aand IPsec."=0A> The purpose of this document is not to replace the [R= FC3775] return=0A> routability procedure by the use of IPsec/IKE which h= as some=0A> authentication requirements which make its universal deploym= ent more=0A> than unrealistic.=0AAgain for readability, change to=0A=0A = The purpose of this document is not to replace the [RFC3775] return=0A = routability procedure by the use of IPsec/IKE. It is unrealistic to=0A ex= pect credentials to be available for strong authentication between=0A any= pair of communication hosts.=0A=0AFinally, the document should be checked = for correct=0Acapitalization of terms (such as message names) from=0ARFC 37= 75.=0A=0AJari=0A=0A=0A_______________________________________________=0AMip= 6 mailing list=0AMip6@ietf.org=0Ahttps://www1.ietf.org/mailman/listinfo/mip= 6 --0-522313438-1167839734=:97671 Content-Type: text/html; charset=ascii Content-Transfer-Encoding: quoted-printable
Hi all,
=0A
  Glancing through= this draft, I noticed the following:
=0A
By just settin=
g up an IPsec SA with the CN, the MN is able to send=0A   packets directly =
to the CN, i.e., triangular routing is enabled.
=0A
=
shouldn't it say the triangular routing is disabled?
=0A
=  
=0A
Regards,
=0A
 
=0A
----- Original Message ----
From: Jari = Arkko <jari.arkko@piuha.net>
To: Francis Dupont <Francis.Dupont= @fdupont.fr>; COMBES Jean-Michel RD-MAPS-ISS <jeanmichel.combes@orang= e-ft.com>
Cc: Mobile IPv6 Mailing List <mip6@ietf.org>
Sent:= Wednesday, January 3, 2007 5:14:33 AM
Subject: [Mip6] re-review of mip6= -cn-ipsec

=0A
Hi all,

I finally found time to come back t= o this document.
Sorry for the delay.

I like the new applicabilit= y statement and other
changes you made in the draft. However, there
a= re still some issues from my previous review
that were not addressed, in= cluding for instance
the normative references, negotiation of how
thi= s mechanism is turned on, and a more detailed
explanation of the securit= y implications of this
mechanism. Details later in this e-mail.

A= lso, as I went through the draft I wrote some
edits that would satisfy m= y review and let this
draft move forward. Feel free to use these
as a= starting point or make your own edits;
they are provided as suggestions= only:

http://www.arkko.com/reviews/mip6/cn-ipsec-03-edits.= txt
http://www.arkko.com/reviews/= mip6/cn-ipsec-03-edits-from-draft-ietf-mip6-cn-ipsec-03.diff.html
Technical:
>    -  when an alternate = care-of address option is present and is not
>    = ;   checked using the state cookie mechanism [COOKIE], the altern= ate
>       care-of address MUST match = the source address in the IP header or
>     = ;  the home address itself.  Any binding update which does n= ot
>       fulfill this requirement MUS= T be rejected.
>    -  no care-of addre= ss test is required when ingress filtering can
>   &nb= sp;   reject fake care-of addresses from a rogue mobile node but a
>       correspondent node can use t= he return routability state cookie
>     &nb= sp; procedure to get extra insurance as well as for the support of
>&= nbsp;      real alternate care-of addresses.
We= already talked about this...

I would suggest deleting the part abou= t the cookie mechanism.
This allows your draft to become an RFC without = this IMHO normative
reference. (And if/when you publish another RFC on t= he cookie
mechanism, its OK for that draft to update this RFC. And I am<= BR>willing to AD sponsor documents in this space. But I'd like to
do tha= t on a document-by-document basis, not by approving
one document that po= ints to all the others.)

In any case, my suggested edits contain a n= ew
section about possible enhancements, with pointers
to some ideas. = This would be OK.
>    When the home address is b= ound to a public key, for instance when the
>    home addr= ess is a Cryptographically Generated Addresses [RFC3972],
> &nbs= p;  the strong authentication MAY be replaced by an address owner= ship
>    proof as described for instance in [IKE= CGA].
As above.

>    IPsec is far more sec= ure than the return routability procedure, thus
>   &n= bsp;it should be used where it is applicable.  So this document c= an
>    increase at least the overall security of= Mobile IPv6.
This document should specify how IPsec is better or
dif= ferent, not simply state its better.

My suggested edits have one att= empt at such
a description.

Semi-technical:
>  In= binding updates the new requirements are:
>    -=   the H (home registration) and K (key management mobility
>       capability) bits MUST= be cleared.
The former does not appear to be a new requirement. Suggest=
deleting the entry, and stating later in the same section
"The use o= f the K (key management mobility capability)
bit with correspondent node= s is not defined. This bit
is always set to zero."

> &nbs= p;  -  as ESP can only protect the payload, an alternat= e care-of address
>       option MUST b= e used in conjunction with ESP (cf. [RFC3775] section
>  &n= bsp;    11.7.1).
This is another requirement that is not = new. Delete the
item.
>    -  "long"= lifetime compatible with the IPsec policy (i.e., by default
> &= nbsp;     up to the IPsec security association lifetime= ) MAY be granted.
Perhaps you should classify this as something else
= than a new requirement, e.g., place it after the list
and formulate as:

"No= te that a relatively "long" lifetime compatible with the IPsec policy
(i= .e., by default up to the IPsec security association lifetime) MAY
be gr= anted."
>    -  in order to avoid grant= ing any extra privilege by a side effect of
>    =    using IPsec, the peers (i.e., the mobile and correspondent nod= es)
>       may restrict the traffic se= lectors to the protection of mobility
>     =   signaling only.  This should be applied to any dubious cas= es,
>       including by default when s= ecurity administration is known to be
>     =   too light.
I still do not understand this. Furthermore, it seems = to
argue against the situation that you assumed in the
applicability = statement. That is, you use this method
when you would be using IPsec anyway for s= ome other
reason.

> When a packet carrying a home address opti= on is protected by a
> >    suitable IPsec sec= urity association, the home address option SHOULD
> >  &= nbsp; be considered valid.
>  
>
> I thin= k there should be a discussion somewhere (perhaps Section 2)
> about = the type of SA creation procedure and trust that is required
> to mak= e the above decision. See RFC 4449 Section 2 first two bullet
> items= for an example, and consider saying something about whether
> this m= echanism is applicable with BTNS or opportunistic IPsec.
>
> Th= e implications may also be different for triangular routing
> and rou= te optimization. It seems that all we need for triangular
> routing i= s that the original address (the one that you send
> traffic back to)= was used in the IKE exchange. That is, a dynamic
> SA is needed, but it can be o= f any type. For route optimization,
> we'd like to know and trust the= entity at the other end.
>  
This comment from my prev= ious review has not
been addressed.

> In binding updates the n= ew requirements are:
>  
>
> I would like to u= nderstand what happens when the peers use RFC 3775
> while at the sam= e time for other reasons use IPsec between themselves,
> and ONE (not= both) support the mechanism specified here. How do they
> know what = they should do? Is there a missing negotiation step somewhere?
> = ; 
As above.

> If you cut away the state cookie referenc= e (as suggested earlier),
> I would suggest that you include a statem= ent similar to RFC 4449
> about the trust needed to take care-of addr= esses without verifying
> them.
As above.


Editorial:
> But any stronger mechanism (i.e., more secure than the
> return routabil= ity procedure) may be used, including of course IPsec
> (cf. [RFC3775= ] Appendix 3 "New Authorization Methods").
For readability, you should r= ewrite this as "This document
defines an alternative mechanism based on = strong authentication
and IPsec."
>    The pur= pose of this document is not to replace the [RFC3775] return
> &= nbsp;  routability procedure by the use of IPsec/IKE which has so= me
>    authentication requirements which make it= s universal deployment more
>    than unrealistic= .
Again for readability, change to

   The purpose of th= is document is not to replace the [RFC3775] return
   routabil= ity procedure by the use of IPsec/IKE. It is unrealistic to
  = expect credentials to be available for strong authentication between
&n= bsp;  any pair of communication hosts.

Finally, the document should be ch= ecked for correct
capitalization of terms (such as message names) fromRFC 3775.

Jari


________________________________________= _______
Mip6 mailing list
Mip6@ietf.org
https://www1.ietf.org/mailman= /listinfo/mip6
=0A

--0-522313438-1167839734=:97671-- --===============0957205175== 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 --===============0957205175==-- From mip6-bounces@ietf.org Wed Jan 03 18:04:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2F9G-0001K7-KJ; Wed, 03 Jan 2007 18:03:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2F9F-0001K2-Gu for mip6@ietf.org; Wed, 03 Jan 2007 18:03:53 -0500 Received: from floor.dave.sonera.fi ([131.177.130.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2F9E-0000Dp-3e for mip6@ietf.org; Wed, 03 Jan 2007 18:03:53 -0500 Received: from floor.dave.sonera.fi (localhost [127.0.0.1]) by floor.dave.sonera.fi (Sendmail) with ESMTP id l03N3mQA022983 for ; Thu, 4 Jan 2007 01:03:48 +0200 (EET) Received: from [131.177.105.19] (ws19.secureuser.sonera.fi [131.177.105.19]) by floor.dave.sonera.fi (Sendmail) with ESMTP id l03N3hVp022972; Thu, 4 Jan 2007 01:03:43 +0200 (EET) Message-ID: <459C3647.4070402@teliasonera.com> Date: Thu, 04 Jan 2007 01:03:35 +0200 From: Jouni Korhonen User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "Chowdhury, Kuntal" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: mip6@ietf.org, "Tschofenig, Hannes" Subject: [Mip6] Questions on draft-ietf-mip6-radius-01 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 have few questions for clarifications on this draft. Section 8 and the associated notes give an impression that when a NAS suggest a local HA _both_ MIP6-HL-Prefix and MIP6-HOA must be present in the access-req. I assume this is not the intention as the same prefix information is anyway included in both attributes, no? Why section 9 is not actually referencing related MIP6 work in Dime for the possible Diameter translations? E.g. all attributes except MIP6-DNS-MO will be covered in Dime's NAS-HAAA document. In section 9 all AVPs have mandatory bit set in the flag rules table. I wonder if this is actually correct. E.g. integrated scenario Diameter case would reuse existing applications. Cheers, Jouni _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jan 03 23:07:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Jrs-0000MK-Ux; Wed, 03 Jan 2007 23:06:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Jrr-0000MF-Mw for mip6@ietf.org; Wed, 03 Jan 2007 23:06:15 -0500 Received: from wx-out-0506.google.com ([66.249.82.230]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2Jro-0001QR-GK for mip6@ietf.org; Wed, 03 Jan 2007 23:06:15 -0500 Received: by wx-out-0506.google.com with SMTP id h27so6461067wxd for ; Wed, 03 Jan 2007 20:06:12 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=lr8xXC/L44qXhktbTJgyM0OjuPggjtxK4zlexwd56zziL9mFHknLuA+xiMAE6V/xgx/rp2I038jYQcP5f/v9aKersHlds7W7SbGqqA5dBJpGIi/KalPqJUoEbv6UrZeG+o9ggOfLyZWicrJVJ5Pnf8myJWKivcEzh2vXTNM4r/8= Received: by 10.70.116.1 with SMTP id o1mr40022024wxc.1167883571780; Wed, 03 Jan 2007 20:06:11 -0800 (PST) Received: from ?203.178.143.234? ( [203.178.143.234]) by mx.google.com with ESMTP id i19sm41889146wxd.2007.01.03.20.06.09; Wed, 03 Jan 2007 20:06:10 -0800 (PST) In-Reply-To: <459505A6.4060501@motorola.com> References: <200612250833.kBP8XsHF012772@tao.fdupont.fr> <459505A6.4060501@motorola.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: RYUJI WAKIKAWA Subject: Re: [Mip6] Non-tunnelled Echo Req MN to HA Date: Thu, 4 Jan 2007 13:06:00 +0900 To: Alexandru Petrescu X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: mip6@ietf.org, Francis Dupont 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, On 2006/12/29, at 21:10, Alexandru Petrescu wrote: > Francis Dupont wrote: >> In your previous mail you wrote: >>> I'm trying to clarify the following ping scenario: MN sends an ICMP >>> Echo Request to its HA, as a non-tunnelled packet. Src: CoA, Dst: >>> HA@ and DO: HoA. >>> Remark this is a non-tunnelled packet. >> => in fact it is the standard way to send a direct packet from MN >> to HA (as the HA is a common CN for direct traffic). > > Yes, it is the standard way to communicate between MN and HA. I'm not > sure though what is meant by 'HA is a common CN' in usual discussion. > This is something we've discussed separately (eg does HA send a > BRR, as > a CN would) and there was no conclusive decision. This is something > needed very often in implementation. For example let's say I > embark in > implementing an HA. Should I make it send BRRs or not. Yes, you should if HA needs to communicate with MNs whose home prefix is other than the HA's one. HA always be HA only for own MNs, and can be correspondent node for other MNs. This is very clear from 3775. Of course, you can skip implementation of BRR if your HA never communicates with other MRs. ryuji > This pinging HA question also reflects a need for clarification. > >>> Should the HA simply send back ICMP echo replies to the CoA? Or >>> should the HA be bothered by the HoA in DO and send back the echo >>> reply _only_ if the corresponding binding cache entry (HoA-CoA) >>> exists, and otherwise send a Binding Error to MN? >> => none of them: the HA ICMP engine should send replies to the MN HoA >> and the MIPv6 code should add a type 2 RH through the registered CoA >> (which can be the same of a different address). > > Ok. > >>> I'm tempted to say that HA should ignore the HoA in DO and just >>> reply back to MN. MN and HA should still act as simple hosts and >>> ping each other non-tunnelled. >> => if you want that you must avoid the DO, usually it is done by >> forcing the source address to the CoA. > > Errr... I understand the principle: don't put DO in Echo Req and thus > the Echo Reply won't have an RH. (the src address _is_ the CoA). But > the ping program is not capable to optionally add DO or not. > >> Merry Christmas! > > Thanks ! Et Bonnes Fetes ! > > Alex > > _______________________________________________ > 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 Jan 04 06:39:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2QwI-0005hA-2c; Thu, 04 Jan 2007 06:39:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2QwF-0005LF-Kg for mip6@ietf.org; Thu, 04 Jan 2007 06:39:15 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H2QwD-0002Pg-7O for mip6@ietf.org; Thu, 04 Jan 2007 06:39:15 -0500 Received: (qmail invoked by alias); 04 Jan 2007 11:39:11 -0000 Received: from p549879CC.dip.t-dialin.net (EHLO [192.168.2.32]) [84.152.121.204] by mail.gmx.net (mp035) with SMTP; 04 Jan 2007 12:39:11 +0100 X-Authenticated: #29516787 Message-ID: <459CE76C.3070606@gmx.net> Date: Thu, 04 Jan 2007 12:39:24 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b1 (Windows/20061206) MIME-Version: 1.0 To: Jouni Korhonen Subject: Re: [Mip6] Questions on draft-ietf-mip6-radius-01 References: <459C3647.4070402@teliasonera.com> In-Reply-To: <459C3647.4070402@teliasonera.com> 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: 4adaf050708fb13be3316a9eee889caa Cc: mip6@ietf.org, "Tschofenig, Hannes" 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, Jouni Korhonen wrote: > Hi, > > I have few questions for clarifications on this draft. > > Section 8 and the associated notes give an impression that when a NAS > suggest a local HA _both_ MIP6-HL-Prefix and MIP6-HOA must be present > in the access-req. I assume this is not the intention as the same > prefix information is anyway included in both attributes, no? > > Why section 9 is not actually referencing related MIP6 work in Dime > for the possible Diameter translations? E.g. all attributes except > MIP6-DNS-MO will be covered in Dime's NAS-HAAA document. That's a mistake. I mentioned it during my presentation at the last IETF meeting in RADEXT. > > In section 9 all AVPs have mandatory bit set in the flag rules table. > I wonder if this is actually correct. E.g. integrated scenario > Diameter case would reuse existing applications. I think the table needs to be corrected. I also believe that most of the Diameter Considerations sections in various drafts (not only in this document) are actually wrong. If the design of a Diameter application would be so easy why do we need to discuss various aspects for a couple of months. Btw, the attribute format needs to be updated to meet the expectations of the RADEXT group. To summarize: As we move along with the DIME documents we need to get the documents in sync. Ciao Hannes > > Cheers, > Jouni > > > _______________________________________________ > 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 Jan 05 02:51:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2jqv-0002lQ-Qp; Fri, 05 Jan 2007 02:51:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2jqt-0002lA-KF for mip6@ietf.org; Fri, 05 Jan 2007 02:50:59 -0500 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 1H2jqr-0006oV-TX for mip6@ietf.org; Fri, 05 Jan 2007 02:50:59 -0500 Received: (qmail 16815 invoked from network); 5 Jan 2007 16:50:52 +0900 Received: from (HELO MIP6-236) (@) by with SMTP; 5 Jan 2007 16:50:52 +0900 To: alexandru.petrescu@motorola.com, vijay.devarapalli@AzaireNet.com Subject: Re: [Mip6] Non-tunnelled Echo Req MN to HA From: "K.Kawaguchi" References: <45941828.6050803@azairenet.com> <45950851.1080706@motorola.com> <45956328.9090306@azairenet.com> <459A295C.5000005@motorola.com> In-Reply-To: <459A295C.5000005@motorola.com> Message-Id: <200701051650.JGI82841.BJLHVUXB@ysknet.co.jp> X-Mailer: Winbiff [Version 2.43 PL1] X-Accept-Language: ja,en Date: Fri, 5 Jan 2007 16:50:52 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f 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, I am maintaining the TAHI MIPv6/NEMO comformance tool. If it is necessary, the tool will be corrected. Please let us confirm some. 1. The function of CN, HA, and MN is independent. Of course, some node can have functions(CN+HA, CN+MN). However, the function works alone in the following cases. HA(CN+HA) works as HA for MN that binds home registration. CN(CN+HA) works as CN for MN that binds correspondent registration. After the above-mentioned is based, HA and CN have the same function part. It is described in CN(section 9) of RFC3775, and is referred to in HA(section 10). Is this correct? 2. In HA(Section 10), BRR is not described. So, HA doesn't send BRR to MN. HA informs of the binding time with Lifetime or Binding Refresh Advice mobility option in BA. Is this correct? 3. HA might receive the packet with Home Address option from MN. But, in HA (Section 10), there is no description when the direct packet is received from MN to HA. What should HA work ? An opposite direction is described in 10.4.2 that refer to 9.3.2. 4. Additionally, if the operation of HA and CN is different. If (CN+HA) receives packet with invalid home address option, which operation should (CN+HA) take ? Best regards --- Kiyoaki KAWAGUCHI "Alexandru Petrescu " wrote: > Vijay Devarapalli wrote: > > Alexandru Petrescu wrote: > >> Vijay Devarapalli wrote: > >>> Mondemu Sreenivasulu-A21119 wrote: > >>>> Sorry, The small correction. It is not very clear from RFC 3775 > >>>> whether it is a expected scenario. > >>> > >>> RFC 3775 requires the HA to send the Echo Reply back with a > >>> routing header if the Echo request had the home address option. > >> > >> Yes, that's fine, 3775 clear on that. > >> > >> But does 3775 require the _HA_ to send a Binding Error to MN if it > >> received an EchoReq with DO whose HoA is not in its BC? The TAHI > >> certification tests seem to require this. > > > > No. The Binding Error message is sent only the CN. The TAHI test is > > valid only if your HA is also a CN. > > Ok, so a HA not sending Binding Error to a MN it serves would still be > TAHI-conformant? > > >> 3775 does require the _CN_ to do so. Would HA also send Binding > >> Errors when EchoReq DO's has a HoA not present its BC? > >> > >> The 3775 Binding Error text seems to be only about CN, not HA. > >> > >> This again is a very needed clarification for anybody implementing > >> an HA. This clarification is needed together with clarification > >> whether HA sends Binding Refresh Request or not (3775 says CN > >> does). > > > > If your HA implementation is strictly a home agent and does not > > behave like a CN for a mobile node that it does not serve, then you > > don't have to implement the Binding Error message. > > > > If your HA implementation behaves like a CN for a mobile node that it > > does not serve, then it must send a Binding Error message to the > > mobile node when it receives a packet with a home address option and > > there is no corresponding binding cache entry. > > Makes sense. I mean a HA that does serve the MN and that is pinged by > that MN. > > Alex > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > > Best regards --- Kiyoaki KAWAGUCHI _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jan 08 10:45:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3wg7-0007NI-Ju; Mon, 08 Jan 2007 10:44:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3wg5-0007Ln-HY for mip6@ietf.org; Mon, 08 Jan 2007 10:44:49 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H3wg0-0004fc-9z for mip6@ietf.org; Mon, 08 Jan 2007 10:44:49 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-10.tower-128.messagelabs.com!1168271083!2458897!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 26352 invoked from network); 8 Jan 2007 15:44:43 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-10.tower-128.messagelabs.com with SMTP; 8 Jan 2007 15:44:43 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l08FiQ0b018931; Mon, 8 Jan 2007 08:44:26 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id l08FiPx6014003; Mon, 8 Jan 2007 09:44:25 -0600 (CST) Message-ID: <45A266D9.80402@motorola.com> Date: Mon, 08 Jan 2007 16:44:25 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: RYUJI WAKIKAWA Subject: Re: [Mip6] Non-tunnelled Echo Req MN to HA References: <200612250833.kBP8XsHF012772@tao.fdupont.fr> <459505A6.4060501@motorola.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: mip6@ietf.org, Francis Dupont 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 RYUJI WAKIKAWA wrote: > Hi Alex, > > On 2006/12/29, at 21:10, Alexandru Petrescu wrote: > >> Francis Dupont wrote: >>> In your previous mail you wrote: >>>> I'm trying to clarify the following ping scenario: MN sends an >>>> ICMP Echo Request to its HA, as a non-tunnelled packet. Src: >>>> CoA, Dst: HA@ and DO: HoA. Remark this is a non-tunnelled >>>> packet. >>> => in fact it is the standard way to send a direct packet from MN >>> to HA (as the HA is a common CN for direct traffic). >> >> Yes, it is the standard way to communicate between MN and HA. I'm >> not sure though what is meant by 'HA is a common CN' in usual >> discussion. This is something we've discussed separately (eg does >> HA send a BRR, as a CN would) and there was no conclusive decision. >> This is something needed very often in implementation. For >> example let's say I embark in implementing an HA. Should I make it >> send BRRs or not. > > Yes, you should if HA needs to communicate with MNs whose home prefix > is other than the HA's one. HA always be HA only for own MNs, and > can be correspondent node for other MNs. This is very clear from > 3775. What's clear in 3775 is that CN sends BRR, not HA. It is good for HA to send BRR to its MNs (that do have same home prefix), because a renewing BU to HA (one that is sent right before the BC entry expires) can get lost; at that point the HA can send a BRR to its MN before deleting the BC entry. This is not specified in 3775. > Of course, you can skip implementation of BRR if your HA never > communicates with other MRs. Ok, but I think it makes sense for an HA that is not CN to anybody to send BRR to its own MNs. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jan 08 11:05:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3wzz-0007zf-Tt; Mon, 08 Jan 2007 11:05:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3wzy-0007zS-50 for mip6@ietf.org; Mon, 08 Jan 2007 11:05:22 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H3wzv-0003Ck-Jm for mip6@ietf.org; Mon, 08 Jan 2007 11:05:22 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-8.tower-128.messagelabs.com!1168272317!4791886!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 25330 invoked from network); 8 Jan 2007 16:05:17 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-8.tower-128.messagelabs.com with SMTP; 8 Jan 2007 16:05: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 l08G4whV026595; Mon, 8 Jan 2007 09:04:58 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l08G4uZ5018974; Mon, 8 Jan 2007 10:04:57 -0600 (CST) Message-ID: <45A26BA7.9060102@motorola.com> Date: Mon, 08 Jan 2007 17:04:55 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "K.Kawaguchi" Subject: Re: [Mip6] Non-tunnelled Echo Req MN to HA References: <45941828.6050803@azairenet.com> <45950851.1080706@motorola.com> <45956328.9090306@azairenet.com> <459A295C.5000005@motorola.com> <200701051650.JGI82841.BJLHVUXB@ysknet.co.jp> In-Reply-To: <200701051650.JGI82841.BJLHVUXB@ysknet.co.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: mip6@ietf.org, vijay.devarapalli@AzaireNet.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 K.Kawaguchi wrote: > Hi, > > I am maintaining the TAHI MIPv6/NEMO comformance tool. If it is > necessary, the tool will be corrected. Please let us confirm some. > > > 1. The function of CN, HA, and MN is independent. Of course, some > node can have functions(CN+HA, CN+MN). However, the function works > alone in the following cases. > > HA(CN+HA) works as HA for MN that binds home registration. CN(CN+HA) > works as CN for MN that binds correspondent registration. I understand, it's a new terminology. A CN(CN+HA) works as a CN for MN that binds correspondent registration - yes, it maintains a BC - but it doesn't do proxy ND for that MN. So one wouldn't call it CN(CN+HA) because that 'HA' word makes think it is a complete HA implementation, and a complete HA implementation does proxy ND. > After the above-mentioned is based, HA and CN have the same function > part. It is described in CN(section 9) of RFC3775, and is referred > to in HA(section 10). Is this correct? Mostly yes, but in detail half far from yes. Section 10 HA has 3 subsections (out of 6) that are specific parts to only a HA, and not to a CN. These HA-specific functions are MPD, DHAAD and proxyND. So a CN(CN+HA) does not do MPD, DHAAD nor proxyND; but the HA word in CN(CN+HA) makes think so. So I think instead of saying HAHACN binds home registration and HACNCN binds correspondent registration I think one should list the MH messages and operations that a HAHACN and a HACNCN should do. Or maybe you mean HAHACN does all section 10 while HACNCN does only 3 subsections of section 10? > 2. In HA(Section 10), BRR is not described. So, HA doesn't send BRR > to MN. HA informs of the binding time with Lifetime or Binding > Refresh Advice mobility option in BA. Is this correct? I guess so. But I think it makes sense for a full HA (or HAHACN) to send BRR, because it is useful when a BC entry expires and the BU is lost. Current 3775 doesn't seem to say so. > 3. HA might receive the packet with Home Address option from MN. But, > in HA (Section 10), there is no description when the direct packet > is received from MN to HA. What should HA work ? Good question. So text should be added to clarify? Also, about Binding Error. Section 9.2 Processing Mobility Headers says that _anybody_ processing a received Mobility Header whose Type is not understood should send a BErr. That means that a HA should too (not only a CN); and regardless of whether the originator of that message is a MN registered to the HA or not registered. > An opposite direction is described in 10.4.2 that refer to 9.3.2. > > > 4. Additionally, if the operation of HA and CN is different. If > (CN+HA) receives packet with invalid home address option, which > operation should (CN+HA) take ? Both HA and CN should be able to build BErr messages. If the document doesn't say so then it should. It is not enough to relegate this behaviour to a single statement in rfc "A CN can be a HA, or a HA can be a CN, or anybody should be send a BErr". It should clearly say "A HA should be able to send BErr". Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jan 09 02:53:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4Bn0-0004KN-Q7; Tue, 09 Jan 2007 02:52:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4Bmz-0004KF-VN for mip6@ietf.org; Tue, 09 Jan 2007 02:52:57 -0500 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 1H4Bmy-0005jP-7u for mip6@ietf.org; Tue, 09 Jan 2007 02:52:57 -0500 Received: (qmail 12926 invoked from network); 9 Jan 2007 16:52:42 +0900 Received: from (HELO MIP6-236) (@) by with SMTP; 9 Jan 2007 16:52:42 +0900 To: alexandru.petrescu@motorola.com Subject: Re: [Mip6] Non-tunnelled Echo Req MN to HA From: "K.Kawaguchi" References: <45950851.1080706@motorola.com> <45956328.9090306@azairenet.com> <459A295C.5000005@motorola.com> <200701051650.JGI82841.BJLHVUXB@ysknet.co.jp> <45A26BA7.9060102@motorola.com> In-Reply-To: <45A26BA7.9060102@motorola.com> Message-Id: <200701091652.AAH56236.XJVBUBLH@ysknet.co.jp> X-Mailer: Winbiff [Version 2.43 PL1] X-Accept-Language: ja,en Date: Tue, 9 Jan 2007 16:52:42 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: mip6@ietf.org, vijay.devarapalli@AzaireNet.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, "Alexandru Petrescu" wrote: > K.Kawaguchi wrote: > > Hi, > > > > I am maintaining the TAHI MIPv6/NEMO comformance tool. If it is > > necessary, the tool will be corrected. Please let us confirm some. > > > > > > 1. The function of CN, HA, and MN is independent. Of course, some > > node can have functions(CN+HA, CN+MN). However, the function works > > alone in the following cases. > > > > HA(CN+HA) works as HA for MN that binds home registration. CN(CN+HA) > > works as CN for MN that binds correspondent registration. > > I understand, it's a new terminology. > > A CN(CN+HA) works as a CN for MN that binds correspondent registration - > yes, it maintains a BC - but it doesn't do proxy ND for that MN. So one > wouldn't call it CN(CN+HA) because that 'HA' word makes think it is a > complete HA implementation, and a complete HA implementation does proxy ND. I didn't intend to define its new terminology. What I want to say is that X(CN+HA) works by either of HA or CN for MN. HA functions and CN functions are separated. Therefore, I think that a special specification of X(CN+HA) is unnecessary (The following 4 is excluded). > > > After the above-mentioned is based, HA and CN have the same function > > part. It is described in CN(section 9) of RFC3775, and is referred > > to in HA(section 10). Is this correct? > > Mostly yes, but in detail half far from yes. > > Section 10 HA has 3 subsections (out of 6) that are specific parts to > only a HA, and not to a CN. These HA-specific functions are MPD, DHAAD > and proxyND. > > So a CN(CN+HA) does not do MPD, DHAAD nor proxyND; but the HA word in > CN(CN+HA) makes think so. > > So I think instead of saying HAHACN binds home registration and HACNCN > binds correspondent registration I think one should list the MH messages > and operations that a HAHACN and a HACNCN should do. I see. I think that Section 9, 10, and 11 of RFC3775 are described by that intention. > > Or maybe you mean HAHACN does all section 10 while > HACNCN does only 3 subsections of section 10? > > > 2. In HA(Section 10), BRR is not described. So, HA doesn't send BRR > > to MN. HA informs of the binding time with Lifetime or Binding > > Refresh Advice mobility option in BA. Is this correct? > > I guess so. > > But I think it makes sense for a full HA (or HAHACN) to send BRR, > because it is useful when a BC entry expires and the BU is lost. > > Current 3775 doesn't seem to say so. OK, we need the sentence about BRR of HA-MN in RFC. (MUST,SHOULD,MAY,MUST NOT) Though this is a personal opinion. I guesses BRR to be only CN-MN from MN(section 11.7.4) in current RFC3775. CN and MN are equal in the communication. MN can arbitrarily do binding. I think that BRR was prepared so that CN may demand. On the other hand, MN must do binding to HA by own demand. I think that HA is enough to play a passive role for MN. I think that HA MUST NOT send BRR. > > > 3. HA might receive the packet with Home Address option from MN. But, > > in HA (Section 10), there is no description when the direct packet > > is received from MN to HA. What should HA work ? > > Good question. So text should be added to? Yes. I agree. Section like "Section 10.4.x Reciving Packets with Home Address Option" is necessary for HA(Section 10). > > Also, about Binding Error. Section 9.2 Processing Mobility Headers says > that _anybody_ processing a received Mobility Header whose Type is not > understood should send a BErr. That means that a HA should too (not > only a CN); and regardless of whether the originator of that message is > a MN registered to the HA or not registered. > > > An opposite direction is described in 10.4.2 that refer to 9.3.2. > > > > > > 4. Additionally, if the operation of HA and CN is different. If > > (CN+HA) receives packet with invalid home address option, which > > operation should (CN+HA) take ? > > Both HA and CN should be able to build BErr messages. If the document > doesn't say so then it should. > > It is not enough to relegate this behaviour to a single statement in rfc > "A CN can be a HA, or a HA can be a CN, or anybody should be send a > BErr". It should clearly say "A HA should be able to send BErr". I agree. I think that HA should process the packet w/ Home Address Option and the BE(status 1) like the first three paragraphs of Section 9.3.1. Best regards --- Kiyoaki KAWAGUCHI Best regards --- Kiyoaki KAWAGUCHI _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jan 09 08:37:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4H9U-0003cK-9B; Tue, 09 Jan 2007 08:36:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4H9S-0003c4-W1 for mip6@ietf.org; Tue, 09 Jan 2007 08:36:30 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H4H9R-0007NX-GJ for mip6@ietf.org; Tue, 09 Jan 2007 08:36:30 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-5.tower-128.messagelabs.com!1168349785!12654680!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 8378 invoked from network); 9 Jan 2007 13:36:26 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-5.tower-128.messagelabs.com with SMTP; 9 Jan 2007 13:36:26 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l09DaPcT010246; Tue, 9 Jan 2007 06:36:25 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id l09DaOUm020962; Tue, 9 Jan 2007 07:36:24 -0600 (CST) Message-ID: <45A39A57.4020801@motorola.com> Date: Tue, 09 Jan 2007 14:36:23 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "K.Kawaguchi" Subject: Re: [Mip6] Non-tunnelled Echo Req MN to HA References: <45950851.1080706@motorola.com> <45956328.9090306@azairenet.com> <459A295C.5000005@motorola.com> <200701051650.JGI82841.BJLHVUXB@ysknet.co.jp> <45A26BA7.9060102@motorola.com> <200701091652.AAH56236.XJVBUBLH@ysknet.co.jp> In-Reply-To: <200701091652.AAH56236.XJVBUBLH@ysknet.co.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Cc: mip6@ietf.org, vijay.devarapalli@AzaireNet.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 K.Kawaguchi wrote: > Hi, > > "Alexandru Petrescu" wrote: >> K.Kawaguchi wrote: >>> Hi, >>> >>> I am maintaining the TAHI MIPv6/NEMO comformance tool. If it is >>> necessary, the tool will be corrected. Please let us confirm >>> some. >>> >>> >>> 1. The function of CN, HA, and MN is independent. Of course, some >>> node can have functions(CN+HA, CN+MN). However, the function >>> works alone in the following cases. >>> >>> HA(CN+HA) works as HA for MN that binds home registration. >>> CN(CN+HA) works as CN for MN that binds correspondent >>> registration. >> I understand, it's a new terminology. >> >> A CN(CN+HA) works as a CN for MN that binds correspondent >> registration - yes, it maintains a BC - but it doesn't do proxy ND >> for that MN. So one wouldn't call it CN(CN+HA) because that 'HA' >> word makes think it is a complete HA implementation, and a >> complete HA implementation does proxy ND. > > I didn't intend to define its new terminology. What I want to say is > that X(CN+HA) works by either of HA or CN for MN. HA functions and CN > functions are separated. Therefore, I think that a special > specification of X(CN+HA) is unnecessary (The following 4 is > excluded). Ok. To my reading it is important to list what functionalities a certain entity implements - in the document. For example, say that HA(CN+HA) does proxy ND but a CN(CN+HA) doesn't. Should be clear from reading short paragraphs. >>> After the above-mentioned is based, HA and CN have the same >>> function part. It is described in CN(section 9) of RFC3775, and >>> is referred to in HA(section 10). Is this correct? >> Mostly yes, but in detail half far from yes. >> >> Section 10 HA has 3 subsections (out of 6) that are specific parts >> to only a HA, and not to a CN. These HA-specific functions are >> MPD, DHAAD and proxyND. >> >> So a CN(CN+HA) does not do MPD, DHAAD nor proxyND; but the HA word >> in CN(CN+HA) makes think so. >> >> So I think instead of saying HAHACN binds home registration and >> HACNCN binds correspondent registration I think one should list the >> MH messages and operations that a HAHACN and a HACNCN should do. > > I see. I think that Section 9, 10, and 11 of RFC3775 are described by > that intention. > > >> Or maybe you mean HAHACN does all section 10 while HACNCN does only >> 3 subsections of section 10? >> >>> 2. In HA(Section 10), BRR is not described. So, HA doesn't send >>> BRR to MN. HA informs of the binding time with Lifetime or >>> Binding Refresh Advice mobility option in BA. Is this correct? >> I guess so. >> >> But I think it makes sense for a full HA (or HAHACN) to send BRR, >> because it is useful when a BC entry expires and the BU is lost. >> >> Current 3775 doesn't seem to say so. > > OK, we need the sentence about BRR of HA-MN in RFC. > (MUST,SHOULD,MAY,MUST NOT) I agree the document should say something about HA and BRR, without need to browse back and forth for hints on whether a CN can be a HA and under what circumstances. > Though this is a personal opinion. I guesses BRR to be only CN-MN > from MN(section 11.7.4) in current RFC3775. CN and MN are equal in > the communication. MN can arbitrarily do binding. I think that BRR > was prepared so that CN may demand. On the other hand, MN must do > binding to HA by own demand. I think that HA is enough to play a > passive role for MN. I think that HA MUST NOT send BRR. I think it should, personal opinion. In any case, the document should be clear whether HA sends or not the BRR. It's not good to just rely on the fact that sometimes HA can be a CN for unregistered MNs, because this doesn't say whether HA sends or not BRR to its registered MNs. >>> 3. HA might receive the packet with Home Address option from MN. >>> But, in HA (Section 10), there is no description when the direct >>> packet is received from MN to HA. What should HA work ? >> Good question. So text should be added to? > > Yes. I agree. Section like "Section 10.4.x Reciving Packets with Home > Address Option" is necessary for HA(Section 10). > > >> Also, about Binding Error. Section 9.2 Processing Mobility Headers >> says that _anybody_ processing a received Mobility Header whose >> Type is not understood should send a BErr. That means that a HA >> should too (not only a CN); and regardless of whether the >> originator of that message is a MN registered to the HA or not >> registered. >> >>> An opposite direction is described in 10.4.2 that refer to 9.3.2. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> 4. Additionally, if the operation of HA and CN is different. If >>> (CN+HA) receives packet with invalid home address option, which >>> operation should (CN+HA) take ? >> Both HA and CN should be able to build BErr messages. If the >> document doesn't say so then it should. >> >> It is not enough to relegate this behaviour to a single statement >> in rfc "A CN can be a HA, or a HA can be a CN, or anybody should be >> send a BErr". It should clearly say "A HA should be able to send >> BErr". > > I agree. I think that HA should process the packet w/ Home Address > Option and the BE(status 1) like the first three paragraphs of > Section 9.3.1. YEs, an easy way to accomplish this is to have 3 paragraphs. Each paragraph lists the messages an entity sends and the messages it receives. A sort of summary. For example: HA sends BErr, BAck, MPD Adv, etc and receives BU, MPD Sol, etc. This kind of summary could be useful for someone planning on implementing Mobile IPv6. This summary avoids the reader the effort to browse back and forth in the document during the essential planning phase. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jan 12 12:13:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Py1-0002Sg-JH; Fri, 12 Jan 2007 12:13:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Pxz-0002RX-QN; Fri, 12 Jan 2007 12:13:23 -0500 Received: from tmailer.gwdg.de ([134.76.10.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5Pxv-0004j1-Ai; Fri, 12 Jan 2007 12:13:23 -0500 Received: from s5.ifi.informatik.uni-goettingen.de ([134.76.81.25] helo=[172.22.0.58]) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1H5Pxr-0000Xr-VE; Fri, 12 Jan 2007 18:13:16 +0100 Message-ID: <45A7C1A8.5060805@cs.uni-goettingen.de> Date: Fri, 12 Jan 2007 18:13:12 +0100 From: Xiaoming Fu Organization: University of Goettingen, Germany User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: mipshop@ietf.org, mobopts@irtf.org, mip4@ietf.org, mip6@ietf.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Authenticated: Id:xfu X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie X-Spam-Score: 0.5 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: Subject: [Mip6] CFP: MobiArch'07 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 [Apologies if you receive multiple copies of this CFP] -------------------------------------------------------------------- The Second International Workshop on Mobility in the Evolving Internet Architecture (MobiArch 2007) Kyoto, Japan, August 27, 2007 (to be held with ACM SIGCOMM 2007, August 27-31, 2007) http://user.informatik.uni-goettingen.de/~mobiarch/2007 -------------------------------------------------------------------- With the recent development of technologies in wireless access and mobile devices, user, terminal, and network mobility has become an indispensable component of today's Internet vision, and it is likely to continue in the near future, while affecting the whole architectural design of the future Internet. Yet, issues like efficient mobility management and optimization, locator-identifier split, multihoming, security, and related operational/deployment concerns are still in their early stages of development. Moreover, the Internet architecture, its end-to-end principles, and business models will require rethinking due to the massive penetration of mobility into the Internet. MobiArch'07 welcomes submissions, from both researchers and practitioners, in exploration of recent advances in architectures, protocols, and experiences with emerging technologies on wireless and mobility over the Internet, with an emphasis on wireless infrastructures and mobility patterns for mobility support, new mobility protocols, service discovery, routing and location management, mobile network performance evaluation and modeling, multi-homing, security, architectural impacts and deployment considerations. Topics of Interest: ================== Topics of MobiArch’07 cover all aspects of architectural issues and system support for wireless and mobility in the Internet, including but not limited to: - Impacts of new wireless technologies/services and mobility patterns on the Internet architecture - Architectures and protocols for mobility support in the Internet, ranging from approaches in link, network, transport to session/application layers and cross-layer design - Location management, positioning and data management systems for wireless and mobility - Routing and addressing, including locator/identifier split issues and their impacts to the Internet architecture - IP multihoming including flow distribution and load sharing for wireless and mobility - Performance evaluation, experimentation and modeling of mobility in the Internet - Accounting, access control, security and privacy issues and impacts to Internet architecture - Economic, scalability and deployment issues of mobility infrastructure design - Mechanisms and issues with connecting developing regions into the Internet Following the success of MobiArch'06, the MobiArch'07 workshop will be a single-track one-day workshop. Early stages, position papers, systems and measurement papers will be particularly welcome. The proceedings will be published by the ACM and ACM digital library. Submissions: =========== Submissions must be made to MobiArch'07 EDAS entry: http://edas.info/5238, following the guidelines in MobiArch'07 webpage: http://user.informatik.uni-goettingen.de/~mobiarch/2007 Important Dates: =============== Abstract registration: March 20, 2007 Submission Deadline: March 27, 2007 Acceptance Notification: May 15, 2007 Camera-ready version due: June 12, 2007 MobiArch'07 Workshop: August 27, 2007 SIGCOMM'07: August 27-31, 2007 PROGRAM CO-CHAIRS ================= Xiaoming Fu, University of Goettingen (Germany) Katherine Guo, Bell Labs (USA) Sue Moon, KAIST (Korea) Ryuji Wakikawa, Keio University (Japan) PUBLICITY CHAIR =============== Jon Crowcroft, University of Cambridge (UK) QUESTIONS ========= Please consult the Program Co-Chairs (mobiarch@informatik.uni-goettingen.de) if you are uncertain whether your paper falls within the scope of the workshop. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Jan 14 06:11:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H63GA-0006OP-KB; Sun, 14 Jan 2007 06:10:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H63G8-0006Hp-VM for mip6@ietf.org; Sun, 14 Jan 2007 06:10:44 -0500 Received: from mail.unilim.fr ([164.81.1.45] helo=smtp.unilim.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H63G8-0006M1-6m for mip6@ietf.org; Sun, 14 Jan 2007 06:10:44 -0500 Received: from [192.168.0.3] (lns-bzn-24-82-64-175-37.adsl.proxad.net [82.64.175.37]) (authenticated bits=0) by smtp.unilim.fr (8.13.1/8.13.1) with ESMTP id l0EBAd7j024274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 14 Jan 2007 12:10:40 +0100 Message-ID: <45AA0FB0.4080208@xlim.fr> Date: Sun, 14 Jan 2007 12:10:40 +0100 From: Damien Sauveron User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: fr, en MIME-Version: 1.0 To: mip6@ietf.org Content-Type: text/plain; charset=windows-1252; format=flowed X-Univ-Limoges-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (smtp.unilim.fr [164.81.1.45]); Sun, 14 Jan 2007 12:10:40 +0100 (CET) X-Univ-Limoges-MailScanner-Information: Serveur Anti-virus Please contact the SCI, Univ. of Limoges, for more information X-Univ-Limoges-MailScanner: Found to be clean X-Univ-Limoges-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (cached, score=-106.399, requis 6, autolearn=not spam, ALL_TRUSTED -1.80, BAYES_00 -2.60, CALL_FOR_PAPER -3.00, MY_DSL 1.00, SMTP_AUTH -100.00) X-Univ-Limoges-MailScanner-Envelope-From: damien.sauveron@xlim.fr Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by smtp.unilim.fr id l0EBAd7j024274 X-Spam-Score: 0.0 (/) X-Scan-Signature: 681e62a2ce9b0804b459fe780d892beb Subject: [Mip6] [WISTP2007] Third Call for Papers X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: wistp2007sec@xlim.fr List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org ******************************************************************* We apologize in advance if you receive multiple copies of this CFP. Please disseminate it to your colleagues that could be interested. ******************************************************************* Workshop in Information Security Theory and Practices 2007: Smart Cards, Mobile and Ubiquitous Computing Systems && A networking meeting to discuss proposals for the EU FP7 Heraklion, Crete, Greece May 9-11, 2007 Workshop URL: http://wistp2007.xlim.fr/ ******************************************************* WISTP2007 is: - Co-Sponsored by IFIP TC6 Communications Systems - Co-Sponsored by IFIP WG 8.8 Smart Cards - Co-Sponsored by IFIP WG 11.2 Small System Security - Co-Sponsored by The British Computer Society - In Cooperation with the IEEE Computer Society, Technical Committee on Security and Privacy (TCSP) - In Cooperation with the IEEE Computer Society, Task Force on Information Assurance (TFIA) - In Cooperation with the IEEE Systems, Man, and Cybernetics Society, Technical Committee on Information Assurance & Intelligent Multimedia-Mobile Communications - In Cooperation with the IEEE Systems, Man, and Cybernetics Society, Technical Committee on Systems Safety and Security - In Cooperation with the IEEE Vehicular Technology Society - Supported by the IEEE France Section - Supported by the IEEE UKRI Section & by the IEEE UKRI Section - Compute= r Society Chapter - Supported by the IEEE Greece Section - Communications Society & Compute= r Society & VT&AESS Chapters - Supported by the EuroSys (European ACM SIGOPS Chapter) - Supported by the ASF (French ACM SIGOPS Chapter) - Supported by the Greek Computer Society - Supported by the ASTI - Supported by the Institute for Systems and Technologies of Information, Control and Communication (INSTICC) - Supported by the SEE - Supported by the GDR CNRS ASR - Supported by the VDE ITG ******************************************************* WISTP2007 Background and Goals: With the rapid technological development of information technologies, computer systems and especially embedded systems are becoming more mobile and ubiquitous, increasingly interfacing with the physical world. Ensuring the security of these complex and yet, resource constraint systems has emerged as one of the most pressing challenges. The aim of this first workshop is to bring together researchers and practitioners in related areas and to encourage interchange and cooperation between the research community and the industrial/consumer community. The workshop will consist of technical paper presentations, one special session for student papers and five invited talks. To contribute to the structuring of the community, a networking meeting to discuss EU FP7 projects proposals will take place just after the workshop. ******************************************************* Topics of interest include, but are not limited to: A. Smart Cards and Trusted Devices Security * Biometrics, National ID cards * Embedded Systems Security and TPMs * Interplay of TPMs and Smart Cards * New Applications for Secure RFID Systems * RFID Systems Security * Smart Card Security * Smart Card Applications B. Ad Hoc and Mobile Networks Security * Ad Hoc Networks Security * Delay-Tolerant Network Security * Domestic Network Security * Mobile Codes Security * Mobile Devices Security * Security Issues in Mobile and Ubiquitous Networks * Security of GSM/GPRS/UMTS Systems * Sensor Networks Security * Vehicular Network Security * Wireless Communication Security (WiFi, WiMAX, WiMedia, others) C. Ubiquitous Computing Systems Security * Distributed Systems Security * Grid Computing Security * Intrusion Detection and Information Filtering * Peer-to-Peer Networks Security D. Security Protocols, Policies and Management for Mobility * Critical Infrastructure (e.g. for Medical or Military Applications) Security * Digital Rights Management (DRM) * Industrial and Multimedia Applications * Information Assurance * Localization Systems Security (Tracking of People and Goods) * New Applications of Secure Systems * Public Administration and Governmental Services * Security Models and Architecture * Security Policies (Human-Computer Interaction and Human Behavior Impact) * Security Protocols (for Identification and Authentication, Confidentiality and Privacy, and Integrity) * Security Measurements * Trust Management ******************************************************* Submission Details: Authors are invited to submit original papers (written in english) not previously published nor submitted in parallel for publication to any other conference, workshop or journal. All submissions will be subjected to thorough blind review by at least three reviewers (if the paper involved a Program Committee member, the paper will be reviewed at least by five reviewers). All submitted papers should be anonymous with no author(s) names, affiliations, acknowledgments, nor obvious references. Each paper should begin with a title, a short abstract, and a list of keywords, following the template indicated by Springer at: http://www.springer.de/comp/lncs/authors.html The papers will be in .pdf format, at most 10 pages long excluding bibliography and well-marked appendices, and at most 14 pages long in total, using at least 11-point fonts with reasonable margins. As the reader should not be required to read any appendices, the paper should be intelligible even without them. 20 papers will be accepted for presentation at the workshop (they will be included in the proceedings) and 12 additional papers will be selected to be presented as A1 poster at the workshop (they will NOT be included in the proceedings). At least one author of each accepted paper is required to register with the Conference and present the paper. For authors presenting multiple papers, one normal registration is valid for up to two papers. For electronic paper submission please use the following URL: https://wistp2007.xlim.fr/wistp2007/iChair/ ******************************************************* Awards: * Best student paper: 400=80 + a CD-Rom version of the Handbook of Information Security * Best workshop paper: 400=80 + a CD-Rom version of the Handbook of Information Security * Best innovative technology: Gift + a CD-Rom version of the Handboo= k of Information Security Authors of the best works in the Smart Card domain selected by the PC co-chairs of the international conference Cardis'2008 (Fran=E7ois-Xavier Standaert, Gilles Grimaud) will be encouraged to submit extended and significantly revised versions at Cardis'2008. Some accepted papers written by French-speaking authors will be published in a journal of the SEE (in a french version). ******************************************************* Important Dates: - Intention of submission: ASAP. Send a mail to wistp2007sec@xlim.fr - Intention of attendance: ASAP. Send a mail to wistp2007sec@xlim.fr - Paper submission: January 26th, 2007 - Notification: March 1st, 2007 - Author Registration: March 3rd, 2007 - Camera-ready papers: March 5th, 2007 ******************************************************* WISTP2007 Committees and Chairs: - Workshop Organization Chair: Damien Sauveron. XLIM, University of Limoges, France - Workshop Organizing Committee: Angelos Bilas. FORTH-ICS & University of Crete, Greece Konstantinos Markantonakis. ISG-SCC, Royal Holloway University of London, UK Damien Sauveron. XLIM, University of Limoges, France - Workshop co-chairs: Jean-Jacques Quisquater. DICE, Catholic University of Louvain, Belgium Konstantinos Markantonakis. ISG-SCC, Royal Holloway University of London, UK - Workshop Program Committee: Fran=E7ois Arnault. XLIM, University of Limoges, France Angelos Bilas. FORTH-ICS & University of Crete, Greece Christophe Bidan, SSIR, Sup=E9lec, France Pierre-Fran=E7ois Bonnefoi. XLIM, University of Limoges, France Serge Chaumette. LaBRI, University Bordeaux 1, France Pierre Dusart. XLIM, University of Limoges, France Eduardo Fern=E1ndez-Medina Pat=F3n. Alarcos Research Group, University= of Castilla-La Mancha, Spain Theodoulos Garefalakis, Department of Mathematics, University of Crete, Greece Dieter Gollmann. Security in Distributed Applications, Institutes of the TU Hamburg-Harburg, Germany Stefanos Gritzalis. Info-Sec-Lab, University of the Aegean, Greece Olivier Heen. Security Laboratory, Thomson R&D, France Sokratis Katsikas. Info-Sec-Lab, University of the Aegean, Greece Javier Lopez. Computer Science Department, University of Malaga, Spain Konstantinos Markantonakis. ISG-SCC, Royal Holloway University of London, UK Evangelos P. Markatos. FORTH-ICS & University of Crete, Greece Fabio Martinelli. Information Security Group, IIT-CNR, Italy Keith Mayes. ISG-SCC, Royal Holloway University of London, UK Jan de Meer. smartspacelab.eu, Brandenburg Technical University (BTU), Germany Pierre Paradinas. CEDRIC, CNAM, France Kenny Paterson. ISG, Royal Holloway University of London, UK Joachim Posegga, Security in Distributed Systems, University of Hamburg, Germany Jean-Jacques Quisquater. DICE, Catholic University of Louvain, Belgium Pierangela Samarati. Department of Information Technologies, University of Milan, Italy Damien Sauveron. XLIM, University of Limoges, France Paulo Jorge Esteves Ver=EDssimo, LASIGE, University of Lisboa, Portuga= l ******************************************************* Keynote Speakers: - Professor Fred Piper, ISG (Information Security Group), Royal Holloway University of London, UK - Professor Jean-Pierre Hubaux, LCA ( Laboratory for computer Communicati= ons and Applications), EPFL, Switzerland - Stephanie Manning, Chief Engineer, Research and Development, Vodafone Group Services Limited - TBA ******************************************************* Opportunities for students: To help the students looking for a PhD thesis or a postdoctoral position, we will propose them to add a colorized sticker on their badge. In the same way, we will propose to persons offering these positions to add a sticker with a different color. We hope this mechanism will help to support the exchanges between young and senior researchers. ******************************************************* Thanks to our main sponsors: Crisp Telecom Eurosmart Elopsys Limousin Expansion Nokia Vodafone WILEY ******************************************************* We hope you will be interested by this event. For further inquiries, please contact the secretariat at wistp2007sec@xlim.fr Best regards, --=20 Damien Sauveron _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jan 15 16:29:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6ZO1-0007LS-Gk; Mon, 15 Jan 2007 16:29:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6ZNy-0007HA-Oo; Mon, 15 Jan 2007 16:28:58 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6ZNx-0006sy-CC; Mon, 15 Jan 2007 16:28:58 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 53643329D6; Mon, 15 Jan 2007 21:28:57 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H6ZNx-0004Uo-7W; Mon, 15 Jan 2007 16:28:57 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 15 Jan 2007 16:28:57 -0500 X-Spam-Score: -2.8 (--) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: mip6 mailing list , mip6 chair , Internet Architecture Board , RFC Editor Subject: [Mip6] Protocol Action: 'Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture' to Proposed Standard 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 IESG has approved the following document: - 'Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture ' as a Proposed Standard This document is the product of the Mobility for IPv6 Working Group. The IESG contact persons are Jari Arkko and Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-ikev2-ipsec-08.txt Technical Summary This document describes Mobile IPv6 operation with the revised IPsec architecture and IKEv2. The MIP6 RFCs 3775 and 3776 are based on IKE. This I-D explains MIP6 operation and establishment of the IPsec SA between the MN and HA using IKEv2. Working Group Summary The WG has been keen on ensuring a solution for MIP6 with IKEv2 is specified. There is overall consensus on the need for this specification and is widely supported. This I-D has undergone two WG last calls and has been discussed at several MIP6 WG meetings. Protocol Quality This specification has been reviewed by Jari Arkko for the IESG. AD review revealed a concern that the specification of IPsec policies might not be fully RFC 4301 compliant. The IETF Last Call period was used to work together with the secdir to look into this. Extensive comments were received, and document was revised accordingly. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jan 15 17:52:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6agX-0003vk-O1; Mon, 15 Jan 2007 17:52:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6agW-0003qP-T7; Mon, 15 Jan 2007 17:52:12 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6agV-0001l5-5H; Mon, 15 Jan 2007 17:52:12 -0500 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l0FMpjE1012826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 15 Jan 2007 14:51:46 -0800 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l0FMpiW8025353; Mon, 15 Jan 2007 14:51:44 -0800 (PST) Received: from NAEX16.na.qualcomm.com ([10.47.6.157]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Jan 2007 14:51:44 -0800 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, 15 Jan 2007 14:51:46 -0800 Message-ID: <2309978910A6A6478C2C7585692B0AF414ABFC@NAEX16.na.qualcomm.com> In-Reply-To: <4595284F.5000204@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] AD review of draft-ietf-mip6-dsmip-problem-02.txt Thread-Index: AccrWMLmUC/HMw1WSIazDa0UeulA9gNntGfA From: "Tsirtsis, George" To: "Jari Arkko" , "Soliman, Hesham" X-OriginalArrivalTime: 15 Jan 2007 22:51:44.0098 (UTC) FILETIME=[BA893420:01C738F7] X-Spam-Score: 0.0 (/) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f Cc: Mobile IPv6 Mailing List , Mobile IPv4 Mailing List Subject: [Mip6] RE: [Mip4] AD review of draft-ietf-mip6-dsmip-problem-02.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 Jari, thanks for the review and sorry for the long delay in replying. I am going over your comments and revising the draft so I think I will come up with a new draft soon. Thanks again for the thorough review. George > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Friday, December 29, 2006 9:38 AM > To: Soliman, Hesham; Tsirtsis, George > Cc: Mobile IPv6 Mailing List; Mobile IPv4 Mailing List > Subject: [Mip4] AD review of draft-ietf-mip6-dsmip-problem-02.txt >=20 > Hi all, >=20 > I reviewed this document. While I agree with > its conclusions, the draft still needs another > revision. >=20 > Here are the detailed comments: >=20 > Technical: > > - Double the amount of configuration in the mobile node and the home > > > > agent (e.g., security associations). > ... and later ... > > In addition, deploying both protocols will require duplication of > > security credentials on mobile nodes and home agents. This includes, > > IPsec security associations, keying material, and new authentication > > protocols for Mobile IPv6, in addition to the security credentials > > and associations required by Mobile IPv4. Such duplication is again > > significant with no gain to the operator or the mobile node. >=20 > Is this true under all circumstances? For instance, > is it true if one uses RFC 4285 or EAP for Mobile IPv6 > authentication? >=20 > Depending on the answer, please reword > and add the necessary explanations. > > - Local network optimizations for handovers will also need to be > > duplicated. > Only insofar as they are bound to the mobility > protocol. There are a large number of optimizations > (L2 pre-auth etc) that deal with other aspects of the > handover problem and do not impact what happens > at IP or IP mobility layers. >=20 > Please reword. > > 3.1. Implementation burdens > > > > As mentioned above, a node that is IPv4 and IPv6 capable must also be > > > > MIPv4 and MIPv6 capable to roam within the Internet. Clearly this > > will add implementation efforts, which, we argue, are not necessary. > > > > > > In addition to the implementation efforts, some vendors may not > > support both protocols in either mobile nodes or home agents. > > Although this is more of a commercial issue, it does affect the > > large-scale deployment of mobile devices on the Internet. > > > I'm not sure this section reflects the complete > picture. In a situation where host vendors > are independent of those who deploy the > mobility infrastructure, for instance, its > not clear that there is any reduction in > implementation effort. >=20 > Please reword for better balance. >=20 > > Checking nits according to http://www.ietf.org/ID-Checklist.html: > > * The document seems to lack a Security Considerations section. > > >=20 > This is needed (not just the section but the > content as well). >=20 > > Further work in this area, possibly independent of Mobile IP, may > > also be of interest to some parties in which case it should be dealt > > with separately from the incremental Mobile IP based changes. > This statement seems out of place. Or at least I could > not think of what specific further work you were thinking > of. > > 3.0 Problem description > I am missing an explanation of why various existing, > non-mobility related transition mechanisms are insufficient > for solving the issues listed in this document. I believe > they are insufficient, but the document needs to explain > why. >=20 > Please add the explanation. >=20 > Editorial: >=20 > Overall, this document needs an editorial > cleanup and better formatting. Random > linefeeds in particular are making it hard > to read. > > 1. Terminology > > > > In addition to [KEYWORDS], this draft uses the following terms as > You do not use any keywords. > > * The document seems to lack an IANA Considerations section. > > > This is optional, but I normally insert a "There are no IANA > considerations." text just to make it clear that the IANA does > not have to read the entire document. > > * The document seems to lack separate sections for > Informative/Normative > > References. > > > This is needed. > > > > Checking conformance with RFC 3978/3979 boilerplate... > > > > * The document seems to lack an RFC 3978 Section 5.5 Disclaimer -- > however, > > there's a paragraph with a matching beginning. Boilerplate error? > > * The document seems to lack an RFC 3979 Section 5, para 1 IPR > Disclosure > > Acknowledgement -- however, there's a paragraph with a matching > beginning. > > Boilerplate error? > > * The document seems to lack an RFC 3979 Section 5, para 2 IPR > Disclosure > > Acknowledgement -- however, there's a paragraph with a matching > beginning. > > Boilerplate error? > > > > Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: > > * The document seems to lack a 1id_guidelines paragraph about > > Internet-Drafts being working documents -- however, there's a > paragraph > > with a matching beginning. Boilerplate error? > > * The document seems to lack a 1id_guidelines paragraph about 6 months > > document validity -- however, there's a paragraph with a matching > > beginning. Boilerplate error? > > * The document seems to lack a 1id_guidelines paragraph about the list > of > > current Internet-Drafts -- however, there's a paragraph with a > matching > > beginning. Boilerplate error? > > - The page length should not exceed 58 lines per page, but there was 7 > > longer pages, the longest (page 6) being 68 lines > > - It seems as if not all pages are separated by form feeds - found 0 > form > > feeds but 7 pages > > > Hesham, please, move to xml2rfc. Its so much easier > for everyone. You don't need any software, btw, > you can convert to text at xml.resource.org. > > Miscellaneous warnings: > > - The "Author's Address" (or "Authors' Addresses") section title is > > misspelled. > > > Please fix. >=20 > > We argue that all of the above will hinder the deployment of Mobile > > IPv6 as well as any dual stack solution in a mobile environment. We > I would suggest saying "makes harder to deploy ..." instead > of "will hinder". This could be just a language issue, but > my understanding is that "hinder" can be interpreted > as "block" -- and I'm not sure I would agree with such > a strong statement. > > clearly inefficient since it requires: > s/clearly// (better style) >=20 > > Each of these systems > > requiring their own sets of optimizations that may include > > hierarchical Mobile IPv4, hierarchical Mobile IPv6 and Fast > > Handoffs for Mobile IPv4, mechanisms that are currently in > > development in the IETF. > The list seems a bit out of place, and somewhat arbitrary. > I would suggest s/optimizations .*/optimizations./ >=20 > > Deploying both in a dual stack mobile node > > introduces a number of inefficiencies. > s/inefficiencies/problems/ (a pure mip6+mip4 solution > would block either v4 or v6 communications, depending > on which type of access network you are in) > > The draft > > also hints on how the current [MIPv4] and [MIPv6] protocols could be > > extended so that they can support mobility management for a dual > > stack node. > References in abstract. >=20 > Also, I'm not sure you really talk or should talk about the "how" > part. Suggested rewording: "The draft also discusses requirements > for the Mobile IPv4 and Mobile IPv6 protocols so that they can > support ..." >=20 > > 2. Introduction and motivation > This section focuses on the argument that we need > to have one mobility protocol handle both protocol > versions. I would suggest the addition of the basic > connectivity problem explanation before bullet > list. > > 3.4. The impossibility of maintaining IP connectivity > I would start with this in Section 3. >=20 > --Jari >=20 >=20 > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jan 16 00:34:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6gwm-0001ug-KD; Tue, 16 Jan 2007 00:33:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6gwm-0001sw-0j for mip6@ietf.org; Tue, 16 Jan 2007 00:33:24 -0500 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 1H6gwl-0004na-0s for mip6@ietf.org; Tue, 16 Jan 2007 00:33:24 -0500 Received: (qmail 27038 invoked from network); 16 Jan 2007 14:33:17 +0900 Received: from (HELO MIP6-236) (@) by with SMTP; 16 Jan 2007 14:33:17 +0900 To: mip6@ietf.org Subject: Re: [Mip6] Non-tunnelled Echo Req MN to HA From: "K.Kawaguchi" References: <459A295C.5000005@motorola.com> <200701051650.JGI82841.BJLHVUXB@ysknet.co.jp> <45A26BA7.9060102@motorola.com> <200701091652.AAH56236.XJVBUBLH@ysknet.co.jp> <45A39A57.4020801@motorola.com> In-Reply-To: <45A39A57.4020801@motorola.com> Message-Id: <200701161433.JBD35485.HLJBVUXB@ysknet.co.jp> X-Mailer: Winbiff [Version 2.43 PL1] X-Accept-Language: ja,en Date: Tue, 16 Jan 2007 14:33:16 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c 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, Please let me announce the TAHI conformance tool because the tool was referred in the this discussion. (Though this might repeat my description.) TAHI conformance test tool keeps the present test specification. (We wish that the HA specifications be more clear when updating RFC in the future.) The test specification interprets RFC3775 as follows now. a) Whether HA transmits BRR or not. => HA doesn't send BRR. Not describing the BRR function in HA shows that HA doesn't tacitly have the BRR function. Because HA is passive compared with MN, and has Lifetime and Binding Refresh Advice mobility option of BA, it is thought that there is no necessity. b) How should HA do, when HA receives the packet of Echo Request with Home Address destination option from MN where HA has the binding cache entry. => HA replies Echo Reply wtih type2 routing headr. When HA sends the packet to MN, the processing of HA is the same as CN (10.4.2 refer to 9.3.2 in RFC3775). In view of the situation, when HA receives the packet from MN, the processing of HA is the same as CN (so 10.4.x seems to have missed the reference to 9.3.1.). c) How should HA do, when HA receives the packet of Echo Request with Home Address destination option from node where HA hasn't the binding cache entry. => HA replies Binding Error(status 1). The reason is the same as b). Best regards --- Kiyoaki KAWAGUCHI "Alexandru Petrescu " wrote: > K.Kawaguchi wrote: > > Hi, > > > > "Alexandru Petrescu" wrote: > >> K.Kawaguchi wrote: > >>> Hi, > >>> > >>> I am maintaining the TAHI MIPv6/NEMO comformance tool. If it is > >>> necessary, the tool will be corrected. Please let us confirm > >>> some. > >>> > >>> > >>> 1. The function of CN, HA, and MN is independent. Of course, some > >>> node can have functions(CN+HA, CN+MN). However, the function > >>> works alone in the following cases. > >>> > >>> HA(CN+HA) works as HA for MN that binds home registration. > >>> CN(CN+HA) works as CN for MN that binds correspondent > >>> registration. > >> I understand, it's a new terminology. > >> > >> A CN(CN+HA) works as a CN for MN that binds correspondent > >> registration - yes, it maintains a BC - but it doesn't do proxy ND > >> for that MN. So one wouldn't call it CN(CN+HA) because that 'HA' > >> word makes think it is a complete HA implementation, and a > >> complete HA implementation does proxy ND. > > > > I didn't intend to define its new terminology. What I want to say is > > that X(CN+HA) works by either of HA or CN for MN. HA functions and CN > > functions are separated. Therefore, I think that a special > > specification of X(CN+HA) is unnecessary (The following 4 is > > excluded). > > Ok. To my reading it is important to list what functionalities a certain > entity implements - in the document. For example, say that HA(CN+HA) > does proxy ND but a CN(CN+HA) doesn't. Should be clear from reading > short paragraphs. > > >>> After the above-mentioned is based, HA and CN have the same > >>> function part. It is described in CN(section 9) of RFC3775, and > >>> is referred to in HA(section 10). Is this correct? > >> Mostly yes, but in detail half far from yes. > >> > >> Section 10 HA has 3 subsections (out of 6) that are specific parts > >> to only a HA, and not to a CN. These HA-specific functions are > >> MPD, DHAAD and proxyND. > >> > >> So a CN(CN+HA) does not do MPD, DHAAD nor proxyND; but the HA word > >> in CN(CN+HA) makes think so. > >> > >> So I think instead of saying HAHACN binds home registration and > >> HACNCN binds correspondent registration I think one should list the > >> MH messages and operations that a HAHACN and a HACNCN should do. > > > > I see. I think that Section 9, 10, and 11 of RFC3775 are described by > > that intention. > > > > > >> Or maybe you mean HAHACN does all section 10 while HACNCN does only > >> 3 subsections of section 10? > >> > >>> 2. In HA(Section 10), BRR is not described. So, HA doesn't send > >>> BRR to MN. HA informs of the binding time with Lifetime or > >>> Binding Refresh Advice mobility option in BA. Is this correct? > >> I guess so. > >> > >> But I think it makes sense for a full HA (or HAHACN) to send BRR, > >> because it is useful when a BC entry expires and the BU is lost. > >> > >> Current 3775 doesn't seem to say so. > > > > OK, we need the sentence about BRR of HA-MN in RFC. > > (MUST,SHOULD,MAY,MUST NOT) > > I agree the document should say something about HA and BRR, without need > to browse back and forth for hints on whether a CN can be a HA and under > what circumstances. > > > Though this is a personal opinion. I guesses BRR to be only CN-MN > > from MN(section 11.7.4) in current RFC3775. CN and MN are equal in > > the communication. MN can arbitrarily do binding. I think that BRR > > was prepared so that CN may demand. On the other hand, MN must do > > binding to HA by own demand. I think that HA is enough to play a > > passive role for MN. I think that HA MUST NOT send BRR. > > I think it should, personal opinion. > > In any case, the document should be clear whether HA sends or not the > BRR. It's not good to just rely on the fact that sometimes HA can be a > CN for unregistered MNs, because this doesn't say whether HA sends or > not BRR to its registered MNs. > > >>> 3. HA might receive the packet with Home Address option from MN. > >>> But, in HA (Section 10), there is no description when the direct > >>> packet is received from MN to HA. What should HA work ? > >> Good question. So text should be added to? > > > > Yes. I agree. Section like "Section 10.4.x Reciving Packets with Home > > Address Option" is necessary for HA(Section 10). > > > > > >> Also, about Binding Error. Section 9.2 Processing Mobility Headers > >> says that _anybody_ processing a received Mobility Header whose > >> Type is not understood should send a BErr. That means that a HA > >> should too (not only a CN); and regardless of whether the > >> originator of that message is a MN registered to the HA or not > >> registered. > >> > >>> An opposite direction is described in 10.4.2 that refer to 9.3.2. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> 4. Additionally, if the operation of HA and CN is different. If > >>> (CN+HA) receives packet with invalid home address option, which > >>> operation should (CN+HA) take ? > >> Both HA and CN should be able to build BErr messages. If the > >> document doesn't say so then it should. > >> > >> It is not enough to relegate this behaviour to a single statement > >> in rfc "A CN can be a HA, or a HA can be a CN, or anybody should be > >> send a BErr". It should clearly say "A HA should be able to send > >> BErr". > > > > I agree. I think that HA should process the packet w/ Home Address > > Option and the BE(status 1) like the first three paragraphs of > > Section 9.3.1. > > YEs, an easy way to accomplish this is to have 3 paragraphs. Each > paragraph lists the messages an entity sends and the messages it > receives. A sort of summary. For example: HA sends BErr, BAck, MPD > Adv, etc and receives BU, MPD Sol, etc. > > This kind of summary could be useful for someone planning on > implementing Mobile IPv6. This summary avoids the reader the effort to > browse back and forth in the document during the essential planning phase. > > Alex > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jan 17 05:12:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H77mN-0005Fd-RN; Wed, 17 Jan 2007 05:12:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H77mN-0005FV-BE; Wed, 17 Jan 2007 05:12:27 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H77mJ-00012I-LH; Wed, 17 Jan 2007 05:12:27 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l0HACGZH010069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 17 Jan 2007 02:12:16 -0800 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l0HACFSG001177; Wed, 17 Jan 2007 02:12:15 -0800 Received: from NAEX16.na.qualcomm.com ([10.47.6.157]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Jan 2007 02:12:15 -0800 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: Wed, 17 Jan 2007 02:12:06 -0800 Message-ID: <2309978910A6A6478C2C7585692B0AF41FF800@NAEX16.na.qualcomm.com> In-Reply-To: <4595284F.5000204@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] AD review of draft-ietf-mip6-dsmip-problem-02.txt Thread-Index: AccrWMLmUC/HMw1WSIazDa0UeulA9gNV0KOA From: "Tsirtsis, George" To: "Jari Arkko" , "Soliman, Hesham" X-OriginalArrivalTime: 17 Jan 2007 10:12:15.0012 (UTC) FILETIME=[F611FE40:01C73A1F] X-Spam-Score: 0.0 (/) X-Scan-Signature: e16ce0269ccb2f59707d16700199d13b Cc: Mobile IPv6 Mailing List , Mobile IPv4 Mailing List Subject: [Mip6] RE: [Mip4] AD review of draft-ietf-mip6-dsmip-problem-02.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 Hi Jari, Thanks again for the review. Please find some comments below as well as some suggestions about how to deal with some of your comments. If you are ok with these I will publish a new version early next week. Regards George > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Friday, December 29, 2006 9:38 AM > To: Soliman, Hesham; Tsirtsis, George > Cc: Mobile IPv6 Mailing List; Mobile IPv4 Mailing List > Subject: [Mip4] AD review of draft-ietf-mip6-dsmip-problem-02.txt >=20 > Hi all, >=20 > I reviewed this document. While I agree with > its conclusions, the draft still needs another > revision. >=20 > Here are the detailed comments: >=20 > Technical: > > - Double the amount of configuration in the mobile node and the home > > > > agent (e.g., security associations). > ... and later ... > > In addition, deploying both protocols will require duplication of > > security credentials on mobile nodes and home agents. This includes, > > IPsec security associations, keying material, and new authentication > > protocols for Mobile IPv6, in addition to the security credentials > > and associations required by Mobile IPv4. Such duplication is again > > significant with no gain to the operator or the mobile node. >=20 > Is this true under all circumstances? For instance, > is it true if one uses RFC 4285 or EAP for Mobile IPv6 > authentication? >=20 > Depending on the answer, please reword > and add the necessary explanations. GT> I believe that, assuming nothing is changed, what the draft says is accurate since typically applications/protocols can not share keys unless security is implemented at a lower layer than that of the application/protocol. Still, I will add something to indicate that for some of the mechanisms listed and with further work, it might be possible to optimize operations. > > - Local network optimizations for handovers will also need to be > > duplicated. > Only insofar as they are bound to the mobility > protocol. There are a large number of optimizations > (L2 pre-auth etc) that deal with other aspects of the > handover problem and do not impact what happens > at IP or IP mobility layers. >=20 > Please reword. GT> I will clarify that we are talking about IP layer optimizations > > 3.1. Implementation burdens > > > > As mentioned above, a node that is IPv4 and IPv6 capable must also be > > > > MIPv4 and MIPv6 capable to roam within the Internet. Clearly this > > will add implementation efforts, which, we argue, are not necessary. > > > > > > In addition to the implementation efforts, some vendors may not > > support both protocols in either mobile nodes or home agents. > > Although this is more of a commercial issue, it does affect the > > large-scale deployment of mobile devices on the Internet. > > > I'm not sure this section reflects the complete > picture. In a situation where host vendors > are independent of those who deploy the > mobility infrastructure, for instance, its > not clear that there is any reduction in > implementation effort. >=20 > Please reword for better balance. >=20 GT> OK, I will clarify=20 > > Checking nits according to http://www.ietf.org/ID-Checklist.html: > > * The document seems to lack a Security Considerations section. > > >=20 > This is needed (not just the section but the > content as well). >=20 > > Further work in this area, possibly independent of Mobile IP, may > > also be of interest to some parties in which case it should be dealt > > with separately from the incremental Mobile IP based changes. > This statement seems out of place. Or at least I could > not think of what specific further work you were thinking > of. GT> Ok, I think we can remove this. > > 3.0 Problem description > I am missing an explanation of why various existing, > non-mobility related transition mechanisms are insufficient > for solving the issues listed in this document. I believe > they are insufficient, but the document needs to explain > why. >=20 > Please add the explanation. GT> It is a bit difficult to write general negative statements like this. I will add a section on this and add something generic about the fact that current transition mechanisms do not seem to deal with mobility.=20 >=20 > Editorial: >=20 > Overall, this document needs an editorial > cleanup and better formatting. Random > linefeeds in particular are making it hard > to read. GT> Yes, the XML template corrected all this, sorry about that. > > 1. Terminology > > > > In addition to [KEYWORDS], this draft uses the following terms as > You do not use any keywords. > > * The document seems to lack an IANA Considerations section. > > > This is optional, but I normally insert a "There are no IANA > considerations." text just to make it clear that the IANA does > not have to read the entire document. GT> I added this in a new IANA section. > > * The document seems to lack separate sections for > Informative/Normative > > References. > > > This is needed. > > GT> fixed > > Checking conformance with RFC 3978/3979 boilerplate... > > > > * The document seems to lack an RFC 3978 Section 5.5 Disclaimer -- > however, > > there's a paragraph with a matching beginning. Boilerplate error? > > * The document seems to lack an RFC 3979 Section 5, para 1 IPR > Disclosure > > Acknowledgement -- however, there's a paragraph with a matching > beginning. > > Boilerplate error? GT> Fixed > > * The document seems to lack an RFC 3979 Section 5, para 2 IPR > Disclosure > > Acknowledgement -- however, there's a paragraph with a matching > beginning. > > Boilerplate error? > > GT> Fixed > > Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: > > * The document seems to lack a 1id_guidelines paragraph about > > Internet-Drafts being working documents -- however, there's a > paragraph > > with a matching beginning. Boilerplate error? GT> Fixed > > * The document seems to lack a 1id_guidelines paragraph about 6 months > > document validity -- however, there's a paragraph with a matching > > beginning. Boilerplate error? GT> Fixed > > * The document seems to lack a 1id_guidelines paragraph about the list > of > > current Internet-Drafts -- however, there's a paragraph with a > matching > > beginning. Boilerplate error? GT> Fixed > > - The page length should not exceed 58 lines per page, but there was 7 > > longer pages, the longest (page 6) being 68 lines GT> Fixed > > - It seems as if not all pages are separated by form feeds - found 0 > form > > feeds but 7 pages > > GT> Fixed > Hesham, please, move to xml2rfc. Its so much easier > for everyone. You don't need any software, btw, > you can convert to text at xml.resource.org. > > Miscellaneous warnings: > > - The "Author's Address" (or "Authors' Addresses") section title is > > misspelled. > > > Please fix. >=20 GT> Fixed > > We argue that all of the above will hinder the deployment of Mobile > > IPv6 as well as any dual stack solution in a mobile environment. We > I would suggest saying "makes harder to deploy ..." instead > of "will hinder". This could be just a language issue, but > my understanding is that "hinder" can be interpreted > as "block" -- and I'm not sure I would agree with such > a strong statement. GT> OK > > clearly inefficient since it requires: > s/clearly// (better style) >=20 GT> OK > > Each of these systems > > requiring their own sets of optimizations that may include > > hierarchical Mobile IPv4, hierarchical Mobile IPv6 and Fast > > Handoffs for Mobile IPv4, mechanisms that are currently in > > development in the IETF. > The list seems a bit out of place, and somewhat arbitrary. > I would suggest s/optimizations .*/optimizations./ >=20 GT> I will remove the list. > > Deploying both in a dual stack mobile node > > introduces a number of inefficiencies. > s/inefficiencies/problems/ (a pure mip6+mip4 solution > would block either v4 or v6 communications, depending > on which type of access network you are in) > > The draft > > also hints on how the current [MIPv4] and [MIPv6] protocols could be > > extended so that they can support mobility management for a dual > > stack node. > References in abstract. >=20 GT> Removed > Also, I'm not sure you really talk or should talk about the "how" > part. Suggested rewording: "The draft also discusses requirements > for the Mobile IPv4 and Mobile IPv6 protocols so that they can > support ..." >=20 GT> OK > > 2. Introduction and motivation > This section focuses on the argument that we need > to have one mobility protocol handle both protocol > versions. I would suggest the addition of the basic > connectivity problem explanation before bullet > list. GT> Added > > 3.4. The impossibility of maintaining IP connectivity > I would start with this in Section 3. >=20 GT> Done > --Jari >=20 >=20 > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jan 17 06:19:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H78pO-0006m7-7V; Wed, 17 Jan 2007 06:19:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H78pN-0006lD-8D; Wed, 17 Jan 2007 06:19:37 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H78pL-00089e-Q7; Wed, 17 Jan 2007 06:19:37 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id F2EAB198767; Wed, 17 Jan 2007 13:19:34 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id ADEAB198766; Wed, 17 Jan 2007 13:19:34 +0200 (EET) Message-ID: <45AE0648.5060204@piuha.net> Date: Wed, 17 Jan 2007 13:19:36 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: "Tsirtsis, George" References: <2309978910A6A6478C2C7585692B0AF41FF800@NAEX16.na.qualcomm.com> In-Reply-To: <2309978910A6A6478C2C7585692B0AF41FF800@NAEX16.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: Mobile IPv6 Mailing List , Mobile IPv4 Mailing List Subject: [Mip6] Re: [Mip4] AD review of draft-ietf-mip6-dsmip-problem-02.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 George, >> Is this true under all circumstances? For instance, >> is it true if one uses RFC 4285 or EAP for Mobile IPv6 >> authentication? >> >> Depending on the answer, please reword >> and add the necessary explanations. >> > > > GT> I believe that, assuming nothing is changed, what the draft says is > accurate since typically applications/protocols can not share keys > unless security is implemented at a lower layer than that of the > application/protocol. Still, I will add something to indicate that for > some of the mechanisms listed and with further work, it might be > possible to optimize operations. > Do you have text? We are not talking about typical applications, we are talking about a very specific case. And there are many applications that can share the same credentials through, say, AAA. >>> - Local network optimizations for handovers will also need to be >>> duplicated. >>> >> Only insofar as they are bound to the mobility >> protocol. There are a large number of optimizations >> (L2 pre-auth etc) that deal with other aspects of the >> handover problem and do not impact what happens >> at IP or IP mobility layers. >> >> Please reword. >> > > GT> I will clarify that we are talking about IP layer optimizations > Ok. >>> 3.1. Implementation burdens >>> >>> As mentioned above, a node that is IPv4 and IPv6 capable mustalso be >>> >>> MIPv4 and MIPv6 capable to roam within the Internet. Clearly this >>> will add implementation efforts, which, we argue, are not necessary. >>> >>> In addition to the implementation efforts, some vendors may not >>> support both protocols in either mobile nodes or home agents. >>> Although this is more of a commercial issue, it does affect the >>> large-scale deployment of mobile devices on the Internet. >>> >>> >> I'm not sure this section reflects the complete >> picture. In a situation where host vendors >> are independent of those who deploy the >> mobility infrastructure, for instance, its >> not clear that there is any reduction in >> implementation effort. >> >> Please reword for better balance. >> >> > > GT> OK, I will clarify > Good. Again, I would like to see the text... >>> Further work in this area, possibly independent of Mobile IP, may >>> also be of interest to some parties in which case it should be dealt >>> >>> with separately from the incremental Mobile IP based changes. >>> >> This statement seems out of place. Or at least I could >> not think of what specific further work you were thinking >> of. >> > > GT> Ok, I think we can remove this. > Good. >>> 3.0 Problem description >>> >> I am missing an explanation of why various existing, >> non-mobility related transition mechanisms are insufficient >> for solving the issues listed in this document. I believe >> they are insufficient, but the document needs to explain >> why. >> >> Please add the explanation. >> > > GT> It is a bit difficult to write general negative statements like > this. I will add a section on this and add something generic about the > fact that current transition mechanisms do not seem to deal with > mobility. > Ok. Text needed. Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jan 17 06:30:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H78zX-00022p-AT; Wed, 17 Jan 2007 06:30:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H78zW-000213-EB; Wed, 17 Jan 2007 06:30:06 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H78zS-0002YR-I0; Wed, 17 Jan 2007 06:30:06 -0500 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l0HBTntK012772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 17 Jan 2007 03:29:50 -0800 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l0HBTmP3022157; Wed, 17 Jan 2007 03:29:49 -0800 Received: from NAEX16.na.qualcomm.com ([10.47.6.157]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Jan 2007 03:29:48 -0800 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: Wed, 17 Jan 2007 03:29:52 -0800 Message-ID: <2309978910A6A6478C2C7585692B0AF41FF808@NAEX16.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] AD review of draft-ietf-mip6-dsmip-problem-02.txt Thread-Index: Acc6KWnMd7SVRMnQRUaOr9EY2gScdQAAJnoA From: "Tsirtsis, George" To: "Jari Arkko " X-OriginalArrivalTime: 17 Jan 2007 11:29:48.0592 (UTC) FILETIME=[CBD1F300:01C73A2A] X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: Mobile IPv6 Mailing List , Mobile IPv4 Mailing List Subject: [Mip6] FW: [Mip4] AD review of draft-ietf-mip6-dsmip-problem-02.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 Jari, See below the text requested for some of your requests. George -----Original Message----- From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 Sent: Wednesday, January 17, 2007 6:20 AM To: Tsirtsis, George Cc: Soliman, Hesham; Mobile IPv6 Mailing List; Mobile IPv4 Mailing List Subject: Re: [Mip4] AD review of draft-ietf-mip6-dsmip-problem-02.txt George, >> Is this true under all circumstances? For instance, >> is it true if one uses RFC 4285 or EAP for Mobile IPv6 >> authentication? >> >> Depending on the answer, please reword >> and add the necessary explanations. >> =20 > > > GT> I believe that, assuming nothing is changed, what the draft says is > accurate since typically applications/protocols can not share keys > unless security is implemented at a lower layer than that of the > application/protocol. Still, I will add something to indicate that for > some of the mechanisms listed and with further work, it might be > possible to optimize operations. > =20 Do you have text? We are not talking about typical applications, we are talking about a very specific case. And there are many applications that can share the same credentials through, say, AAA. GT> Here is what I have.=20 " In addition, deploying both protocols will require duplication of security credentials on mobile nodes and home agents. This includes, IPsec security associations, keying material, and new authentication protocols for Mobile IPv6, in addition to the security credentials and associations required by Mobile IPv4. Depending on the security mechanisms used and with some further work it might be possible to optimize some of these processes. Assuming nothing else changes, however, such duplication is again significant with no gain to the operator or the mobile node." >>> - Local network optimizations for handovers will also need to be >>> duplicated. >>> =20 >> Only insofar as they are bound to the mobility >> protocol. There are a large number of optimizations >> (L2 pre-auth etc) that deal with other aspects of the >> handover problem and do not impact what happens >> at IP or IP mobility layers. >> >> Please reword. >> =20 > > GT> I will clarify that we are talking about IP layer optimizations > =20 Ok. >>> 3.1. Implementation burdens >>> >>> As mentioned above, a node that is IPv4 and IPv6 capable mustalso be >>> =20 >>> MIPv4 and MIPv6 capable to roam within the Internet. Clearly this >>> will add implementation efforts, which, we argue, are not necessary. >>> =20 >>> In addition to the implementation efforts, some vendors may not >>> support both protocols in either mobile nodes or home agents. >>> Although this is more of a commercial issue, it does affect the >>> large-scale deployment of mobile devices on the Internet. >>> >>> =20 >> I'm not sure this section reflects the complete >> picture. In a situation where host vendors >> are independent of those who deploy the >> mobility infrastructure, for instance, its >> not clear that there is any reduction in >> implementation effort. >> >> Please reword for better balance. >> >> =20 > > GT> OK, I will clarify=20 > =20 Good. Again, I would like to see the text... GT> Here it is: " As mentioned above, a node that is IPv4 and IPv6 capable must also be MIPv4 and MIPv6 capable to roam within the Internet. Clearly this increases the complexity of implementations for vendors that decide to support both protocols. Some vendors, however, may not support both protocols in either mobile nodes or home agents. Although this is more of a commercial issue, it does affect the large-scale deployment of mobile devices on the Internet." >>> Further work in this area, possibly independent of Mobile IP, may >>> also be of interest to some parties in which case it should be dealt >>> =20 >>> with separately from the incremental Mobile IP based changes. >>> =20 >> This statement seems out of place. Or at least I could >> not think of what specific further work you were thinking >> of. >> =20 > > GT> Ok, I think we can remove this. > =20 Good. >>> 3.0 Problem description >>> =20 >> I am missing an explanation of why various existing, >> non-mobility related transition mechanisms are insufficient >> for solving the issues listed in this document. I believe >> they are insufficient, but the document needs to explain >> why. >> >> Please add the explanation. >> =20 > > GT> It is a bit difficult to write general negative statements like > this. I will add a section on this and add something generic about the > fact that current transition mechanisms do not seem to deal with > mobility.=20 > =20 Ok. Text needed. GT> Here it is:=20 "4.5. IPv4 to IPv6 Transition Mechanisms The IETF has standardized a number of transition mechanisms to allow networks and end nodes to gain IPv6 connectivity while the Internet is migrating from IPv4 to IPv6. A cursory examination of such transition mechanisms indicates that none of them is designed to deal with mobile nodes. While some transition mechanisms can be combined with Mobile IPv4 or Mobile IPv6, non of the known mechanisms have been shown to assist with the issues described in this document." Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jan 18 09:09:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Xwh-0003QI-FS; Thu, 18 Jan 2007 09:08:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Xwg-0003Q8-0u for mip6@ietf.org; Thu, 18 Jan 2007 09:08:50 -0500 Received: from mail125.messagelabs.com ([85.158.136.35]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H7Xwe-0002WT-JW for mip6@ietf.org; Thu, 18 Jan 2007 09:08:50 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-14.tower-125.messagelabs.com!1169129326!15036574!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 8153 invoked from network); 18 Jan 2007 14:08:46 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-14.tower-125.messagelabs.com with SMTP; 18 Jan 2007 14:08:46 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l0IE8j13012493; Thu, 18 Jan 2007 07:08:45 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id l0IE8iYc021313; Thu, 18 Jan 2007 08:08:45 -0600 (CST) Message-ID: <45AF7F6C.20303@motorola.com> Date: Thu, 18 Jan 2007 15:08:44 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "K.Kawaguchi" Subject: Re: [Mip6] Non-tunnelled Echo Req MN to HA References: <459A295C.5000005@motorola.com> <200701051650.JGI82841.BJLHVUXB@ysknet.co.jp> <45A26BA7.9060102@motorola.com> <200701091652.AAH56236.XJVBUBLH@ysknet.co.jp> <45A39A57.4020801@motorola.com> <200701161433.JBD35485.HLJBVUXB@ysknet.co.jp> In-Reply-To: <200701161433.JBD35485.HLJBVUXB@ysknet.co.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 Kiyoaki, thanks for the response and action. K.Kawaguchi wrote: > Hi, > > Please let me announce the TAHI conformance tool because the tool was > referred in the this discussion. > (Though this might repeat my description.) Yes, thanks for clarification. On a tangent note, can I ask what's the relationship between TAHI conformance tool and IPv6 Gold Logo? Does the clarification you made about the TAHI conformance tool equally apply to IPv6 Gold Logo? Is this the intention? > TAHI conformance test tool keeps the present test specification. > (We wish that the HA specifications be more clear when updating RFC in > the future.) > > The test specification interprets RFC3775 as follows now. > > a) Whether HA transmits BRR or not. > > => HA doesn't send BRR. > Not describing the BRR function in HA shows that HA doesn't > tacitly have the BRR function. Because HA is passive compared > with MN, and has Lifetime and Binding Refresh Advice mobility > option of BA, it is thought that there is no necessity. Depending on the relationship with the IPv6 Gold Logo, should I deduce that a Gold Logo certified HA that does (a1) 'basic features' will not have to send BRR? If HA does send BRR does it mean it implements (a2) 'advanced feature'? Or does it mean it's a 'rankC' testing (non basic, non advanced features, a 'MAY' in RFC). > b) How should HA do, when HA receives the packet of Echo Request with > Home Address destination option from MN where HA has the binding > cache entry. > > => HA replies Echo Reply wtih type2 routing headr. > When HA sends the packet to MN, the processing of HA is the same > as CN (10.4.2 refer to 9.3.2 in RFC3775). > In view of the situation, when HA receives the packet from MN, > the processing of HA is the same as CN (so 10.4.x seems to have > missed the reference to 9.3.1.). Ok, I think this is agreed by several persons, myself included. > c) How should HA do, when HA receives the packet of Echo Request with > Home Address destination option from node where HA hasn't the binding > cache entry. > > => HA replies Binding Error(status 1). > The reason is the same as b). I agree, HA should send Binding Errors, even to nodes it does manage but for which it doesn't have a BC entry. Thanks, Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jan 18 12:19:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7auY-0001Ig-GA; Thu, 18 Jan 2007 12:18:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7auX-0001IS-DX for mip6@ietf.org; Thu, 18 Jan 2007 12:18:49 -0500 Received: from atlrel9.hp.com ([156.153.255.214]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7auW-0000W3-Gr for mip6@ietf.org; Thu, 18 Jan 2007 12:18:49 -0500 Received: from smtp2.fc.hp.com (smtp2.fc.hp.com [15.11.136.114]) by atlrel9.hp.com (Postfix) with ESMTP id E7B9538AF6; Thu, 18 Jan 2007 12:18:47 -0500 (EST) Received: from [16.116.114.13] (spaceshipone.zko.hp.com [16.116.114.13]) by smtp2.fc.hp.com (Postfix) with ESMTP id 51F9A1617F2; Thu, 18 Jan 2007 17:18:47 +0000 (UTC) Message-ID: <45AFABF6.5020508@hp.com> Date: Thu, 18 Jan 2007 12:18:46 -0500 From: Brian Haley Organization: Open Source and Linux Organization User-Agent: Thunderbird 1.5.0.9 (X11/20070103) MIME-Version: 1.0 To: Sri Gundavelli References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bdfdd9dd835c9bb499f7c92933fef080 Cc: Mobile IPv6 Mailing List Subject: [Mip6] Re: I-D ACTION:draft-sgundave-mip6-proxymip6-01.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 Hi Sri, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Proxy Mobile IPv6 > Author(s) : S. Gundavelli, et al. > Filename : draft-sgundave-mip6-proxymip6-01.txt > Pages : 39 > Date : 2007-1-5 > > This specification describes a network-based mobility management > protocol. It is called Proxy Mobile IPv6 (PMIPv6) and is based on > Mobile IPv6. This protocol is for providing mobility support to any > IPv6 host within a restricted and topologically localized portion of > the network and with out requiring the participation of the host in > any mobility related signaling. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-sgundave-mip6-proxymip6-01.txt I tried to go through the whole draft again, might have missed a few spots... -Brian Some edits below, in some cases I just re-wrote the whole paragraph. > 5.5. Sequencing Number Considerations > > Sequence number is typically used by two communication end points as > a means to establish order of the exchanged packets. Mobile IPv6 > uses the Sequence Number field in the registrations messages. The > home agent and the mobile are required to manage this counter. Mobile IPv6 uses the Sequence Number field in registration messages as a way to ensure the correct packet ordering. The home agent and mobile node are required to manage this counter over the lifetime of a binding. > In Proxy Mobile IPv6, the Binding Update messages that the home agent > receives on behalf of a specific mobile, may not be from the same > proxy mobile agent and thus the sequence number value in these > messages will have little meaning and the home agent will not be > predictably order the messages and thus may end up processing an > older message while ignoring the latest binding update message. In Proxy Mobile IPv6, the Binding Update messages that the home agent receives on behalf of a specific mobile node may not be from the same proxy mobile agent. In this case, the sequence number value in these messages will have little meaning, and the home agent will not be able to predictably order the messages. This could lead to the home agent processing an older message, while ignoring the latest binding update message. > In the Proxy Mobile IP model, where the ordering of packets have to > established when multiple senders are involved, sequence number > scheme in the absence of time context transfers will not work. A > global scale such as a time stamp is the right way to ensure order of > packets. This document proposes the use of time stamp in all the > Binding Update messages sent by proxy mobile agents. By leveraging > NTP [RFC-1305] service, all the entities in the Proxy Mobile IP > Network will be able to synchronize the clocks and a time stamp field > in the Binding Update message will enable the home agent to > predictable identify the latest messages from a list of messages > delivered in a out of order fashion. In the Proxy Mobile IPv6 model, the ordering of packets has to be established when multiple senders are involved. The sequence number scheme as specified in [RFC-3775] will not work. A global solution, such as a time stamp, is a way to ensure the correct ordering of packets. This document proposes the use of a new Time Stamp Option, specified in Section 8.4, in all Binding Update messages sent by proxy mobile agents. By leveraging the NTP [RFC-1305] service, all the entities in Proxy Mobile IPv6 should be able to synchronize their respective clocks. Having a time stamp option in Binding Update messages will enable the home agent to predictably identify the latest message from a list of messages delivered in an out-of-order fashion. > The Proxy Mobile IP model, defined in this document requires the > Binding Update messages sent by the proxy mobile agent to have the > time stamp option. The home agent processing a proxy registration > MUST ignore the sequence number field and SHOULD use the value from > the Time Stamp option to establish ordering of the received Binding > Update messages. If the home agent receives a Binding Update message > with a invalid time stamp, the registration request MUST be rejected > and a Binding Acknowledgement must be sent with the status "Invalid > Time Stamp" and with the Time Stamp option. If the home agent receives a Binding Update message with an invalid Time Stamp Option, the Binding Update MUST be rejected and a Binding Acknowledgement MUST be returned in which the Status field is set to 148 (invalid time stamp option). I don't think we need to send the Time Stamp option back, unless we're sending one with the current time, right? > 5.6. IPv4 Home Address Mobility Support > > The transition from IPv4 to IPv6 is a long process and during this > period of transition, both the protocols will be enabled over the > same infrastructure. It is reasonable to assume that the mobile node > and the home agent are IPv4 and IPv6 enabled and further it is also > reasonable to expect the same mobility infrastructure to provide IPv4 > and IPv6 address mobility. The Proxy Mobile IPv6 scheme defined in > this document allows the mobile node to obtain a IPv4 address and to > roam in the network using the same address. s/obtain a IPv4/obtain an IPv4/ > A mobile node attached to a proxy mobile agent, when it sends a DHCP > request, the network will ensure it gets a IPv4 address from its home > address prefix. The DHCP Relay Agent on the access router will tag > the DHCP request from the mobile node with its home prefix hint and > the DHCP server will allocate an address from that prefix. The proxy > mobile agent will send this information in the option, IPv4 Home > Network Prefix Option as part of the Binding Update message. Upon > accepting the registration for the mobile from the proxy mobile > agent, the home address will add IPv4 host route over the tunnel to > the proxy mobile agent. Any IPv4 packets that the home agent > receives from the corresponding node will be routed to the proxy > mobile agent over the IPv6/IPv6 tunnel and any IPv4 packets that it > receives over the tunnel will be routed after removing the tunnel > header. I was confused with this paragraph, I think in one case you used IPv4 when you meant IPv6? When a mobile node attached to a proxy mobile agent sends a DHCP request, the network will ensure it gets an IPv6 address from its home address prefix. The DHCP Relay Agent on the access router will tag the DHCP request from the mobile node with its home prefix hint and the DHCP server will allocate an address from that prefix. The proxy mobile agent will send this information in a new option called a Home Network Prefix Option, defined in Section 8.3, along with the Binding Update message. Upon accepting the registration for the mobile node from the proxy mobile agent, the home agent will add an IPv4 host route over the tunnel to the proxy mobile agent. Any IPv4 packets that the home agent receives from a correspondent node will be tunneled to the proxy mobile agent over the IPv6/IPv6 tunnel, and then routed accordingly after removing the tunnel header. > 5.7. Route Optimizations Considerations > > Mobile IPv6 route optimization, as defined in [RFC-3775], enables a > mobile node to communicate with a corresponding node directly using > its care-of address and further the Return Routability procedure > enables the corresponding node to have reasonable trust that the > mobile node owns both the home address and care-of address. Mobile IPv6 route optimization, as defined in [RFC-3775], enables a mobile node to communicate with a correspondent node directly using its care-of address, the Return Routability procedure establishes reasonable trust that the mobile node owns both the home address and care-of address. > In the Proxy Mobile IPv6 model, the mobile is not involved in any > mobility related signaling and also it does not operate in the dual- > address mode. Hence, the return routability procedure as defined in > RFC-3775 is not applicable for the proxy model. This document does > not address the Route Optimization problem and leaves this work item > for future enhancements. In the Proxy Mobile IPv6 model, the mobile node is not involved in any mobility related signaling, therefore the return routability procedure as defined in [RFC-3775] is not applicable. I think you can delete that last sentence because this document *is* addressing the Route Optimization problem a little bit, right? :) > This specification further recommends that the home agent MUST drop > all HoTI messages received from a home address that has corresponding > Binding Cache entry with the proxy registration flag set. "Recommends" implies SHOULD, I'd change it: Proxy Mobile IPv6 home agents MUST drop all HoTI messages received from a home address that has corresponding Binding Cache entry with the proxy registration flag set. And should it send an error? > 5.9. Home Agent Operation Summary [...] > For supporting this scheme, the home agent MUST satisfy all the > requirements listed in Section 8.4 of [1]. The key differences of > this scheme for the Per-MN-Prefix configuration mode, when compared > to the base protocol is as follows: [1] doesn't have any meaning, maybe you meant [RFC-3775] ? > The mobile node is not anchored on any physical interface on the home > agent. Thus the home agent is not required to perform any proxy ND > operations for defending the home address on the home link. The home > agent is required to manage a binding cache entry for managing the > session state and a routing state for properly routing the packets > destined to the mobile node. I thought it needed to do proxy ND... > Each mobile node has a home address in a prefix that is created > exclusively for that mobile node and no other mobile node will share > its home address from this prefix. > > The route entry specifying that the mobile node's home prefix is > reachable via the tunnel is created as supposed to creating an route > entry just for the mobile node's home address. s/as supposed to creating an/as opposed to creating a/ I also have another question about these three paragraphs. Back in Section 5 (and 6.1) it's said that there are two models - Per-MN-Prefix and the "usual" Shared-Prefix, these paragraphs don't allow for a Shared-Prefix model. [...] > 8.1. Proxy Binding Update A new flag (P) is included in the Binding Update to indicate to the Home Agent whether the Binding Update is coming from a Proxy Mobile Agent and not from a mobile node. The rest of the Binding Update format remains the same as defined in [RFC-3775]. > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sequence # | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |A|H|L|K|M|R|P| Reserved | Lifetime | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 8: Proxy Binding Update Message > > A new flag, the 'P' flag, is added to the Binding Update message > [RFC-3775]. The 'P' flag indicates that the registration is a Proxy > Registration. When a proxy mobile agent sends a registration to the > home agent, the P flag MUST be set to value of 1, to indicate to the > home agent that this registration is a proxy registration sent by a > proxy mobile agent on behalf of a mobile node. Proxy Registration Flag (P) The Proxy Registration Flag is set to indicate to the Home Agent that the Binding Update is from a Proxy Mobile Agent acting on behalf of a Mobile Node. When a Proxy Mobile Agent sends a Binding Update to a Home Agent, it MUST set this flag to 1. > For descriptions of other fields present in this message, refer to > [RFC3775]. RFC-3775 only defined AHLK, you should add a reference to NEMO [RFC-3963] for R, but I can't think of the other. > 8.2. Proxy Binding Acknowledgment A new flag (P) is included in the Binding Acknowledgement to indicate that the Home Agent that processed the corresponding Binding Update supports Proxy Registrations. The flag is set only if the corresponding Binding Update had the Proxy Registration Flag (P) set to 1. The rest of the Binding Acknowledgement format remains the same, as defined in [RFC-3775]. > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Status |K|R|P|Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sequence # | Lifetime | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 9: Proxy Binding Acknowledgment Message > > Proxy Registration Flag (P) > > A new flag, the 'P' flag, is added to the Binding Acknowledgement > message [RFC-3775]. The Proxy Registration Flag is set to a value of > 1, to indicate that the home agent that processed the Proxy Binding > Update supports Proxy Registration. This flag value is set only if > the corresponding Proxy Binding Update had the Proxy Registration > Flag set. Proxy Registration Flag (P) The Proxy Registration Flag is set to indicate that the Home Agent that processed the Binding Update supports Proxy Registrations. It is set to 1 only if the corresponding Binding Update had the Proxy Registration Flag set to 1. > For descriptions of other fields present in this message, refer to > [RFC3775]. and [RFC-3963]. > 8.3. Home Network Prefix Option > > A new option, Home Network Prefix Option is defined for using it in > the Proxy Binding Update and Acknowledgment messages exchanged > between the home agent to the proxy mobile agent. This option can be > used for exchanging the mobile node's home prefix and home address > information. The Home Network Prefix Option is included in Proxy Binding Update and Acknowledgement messages to indicate the home prefix information or home address for the mobile node. > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Reserved | Prefix Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + + > | | > + Local Network Prefix + > | | > + + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ s/Local Network Prefix/Home Network Prefix/ > Length > > Eight-bit unsigned integer indicating the length in octets of > the option, excluding the type and length fields. Set to 18. s/Eight-bit/8-bit s/Set to 18/This field MUST be set to 18/ (I can now tell the NEMO RFC was copy/pasted :) > Reserved > > This field is unused for now. The value MUST be initialized > to 0 by the sender and MUST be ignored by the receiver. > Prefix Length > > Eight-bit unsigned integer indicating the prefix length of > the IPv6 prefix contained in the option. If the prefix length > is set to the value 128, indicates the presence of the > mobile's home address. s/Eight-bit/8-bit > Home Network Prefix > > A sixteen-byte field containing the Home Network Prefix Contains either the Home Network Prefix or a Home Address. The Time Stamp Option needs similar changes (like Length) as above. > 8.5. Status Codes > > Binding Acknowledgment Status Values > > The following status code values are defined for using them in the > Binding Acknowledgment message when using PMIPv6 protocol. You can replace both with: This document defines the following new Binding Acknowledgement status values: _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jan 18 21:43:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7jiw-0005TO-3V; Thu, 18 Jan 2007 21:43:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7jiu-0005TJ-7n for mip6@ietf.org; Thu, 18 Jan 2007 21:43:24 -0500 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 1H7jis-0003XR-IY for mip6@ietf.org; Thu, 18 Jan 2007 21:43:24 -0500 Received: (qmail 27546 invoked from network); 19 Jan 2007 11:43:17 +0900 Received: from (HELO MIP6-236) (@) by with SMTP; 19 Jan 2007 11:43:17 +0900 To: alexandru.petrescu@motorola.com Subject: Re: [Mip6] Non-tunnelled Echo Req MN to HA From: "K.Kawaguchi" References: <45A26BA7.9060102@motorola.com> <200701091652.AAH56236.XJVBUBLH@ysknet.co.jp> <45A39A57.4020801@motorola.com> <200701161433.JBD35485.HLJBVUXB@ysknet.co.jp> <45AF7F6C.20303@motorola.com> In-Reply-To: <45AF7F6C.20303@motorola.com> Message-Id: <200701191143.FFC17618.JXUHVLBB@ysknet.co.jp> X-Mailer: Winbiff [Version 2.43 PL1] X-Accept-Language: ja,en Date: Fri, 19 Jan 2007 11:43:17 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) 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 Hi, "Alexandru Petrescu" wrote: > Kiyoaki, thanks for the response and action. > > K.Kawaguchi wrote: > > Hi, > > > > Please let me announce the TAHI conformance tool because the tool was > > referred in the this discussion. > > (Though this might repeat my description.) > > Yes, thanks for clarification. On a tangent note, can I ask what's the > relationship between TAHI conformance tool and IPv6 Gold Logo? Does the > clarification you made about the TAHI conformance tool equally apply to > IPv6 Gold Logo? Is this the intention? Yes. We have already offered the TAHI tool as a conformance test of IPv6 Ready Phase-2(Gold) Logo. The specification interpretation that I described is consistent with present Logo conformance test specification. The TAHI tool follows the Logo conformance test specification. > > TAHI conformance test tool keeps the present test specification. > > (We wish that the HA specifications be more clear when updating RFC in > > the future.) > > > > The test specification interprets RFC3775 as follows now. > > > > a) Whether HA transmits BRR or not. > > > > => HA doesn't send BRR. > > Not describing the BRR function in HA shows that HA doesn't > > tacitly have the BRR function. Because HA is passive compared > > with MN, and has Lifetime and Binding Refresh Advice mobility > > option of BA, it is thought that there is no necessity. > > Depending on the relationship with the IPv6 Gold Logo, should I deduce > that a Gold Logo certified HA that does (a1) 'basic features' will not > have to send BRR? > > If HA does send BRR does it mean it implements (a2) 'advanced feature'? > Or does it mean it's a 'rankC' testing (non basic, non advanced > features, a 'MAY' in RFC). Now, there are no test item of BRR in the HA test specification. However, BRR should not be sent in the HA conformance test. When the message that HA is not to send is detected, it is judged a fail. I think that BRR in HA is interpreted as a local additional function now. It is necessary to disable BRR in Logo conformance test. Best regards --- Kiyoaki KAWAGUCHI > > > b) How should HA do, when HA receives the packet of Echo Request with > > Home Address destination option from MN where HA has the binding > > cache entry. > > > > => HA replies Echo Reply wtih type2 routing headr. > > When HA sends the packet to MN, the processing of HA is the same > > as CN (10.4.2 refer to 9.3.2 in RFC3775). > > In view of the situation, when HA receives the packet from MN, > > the processing of HA is the same as CN (so 10.4.x seems to have > > missed the reference to 9.3.1.). > > Ok, I think this is agreed by several persons, myself included. > > > c) How should HA do, when HA receives the packet of Echo Request with > > Home Address destination option from node where HA hasn't the binding > > cache entry. > > > > => HA replies Binding Error(status 1). > > The reason is the same as b). > > I agree, HA should send Binding Errors, even to nodes it does manage but > for which it doesn't have a BC entry. > > Thanks, > > Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jan 18 23:51:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7liF-0000j8-Gs; Thu, 18 Jan 2007 23:50:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7liD-0000hp-RB; Thu, 18 Jan 2007 23:50:49 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7liB-0005Pg-Rk; Thu, 18 Jan 2007 23:50:49 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 18 Jan 2007 20:50:47 -0800 X-IronPort-AV: i="4.13,208,1167638400"; d="scan'208"; a="356896535:sNHT75240864" 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 l0J4olmb015716; Thu, 18 Jan 2007 20:50:47 -0800 Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.70.65.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0J4okDl010786; Thu, 18 Jan 2007 20:50:46 -0800 (PST) Date: Thu, 18 Jan 2007 20:50:46 -0800 (PST) From: Sri Gundavelli To: Brian Haley In-Reply-To: <45AFABF6.5020508@hp.com> Message-ID: References: <45AFABF6.5020508@hp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=19736; t=1169182247; x=1170046247; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20Re=3A=20I-D=20ACTION=3Adraft-sgundave-mip6-proxymip6-01.txt |Sender:=20; bh=RPn2Ex2BXpAOhizP9BkM5JLZ4Dx7y5exVs8GTjIKnFw=; b=N7LA4U+JQj78/fTptTcO+QPOfoNkmd/5g6io2j2/C9pZl7OfiPackY042uZrmxZMRVsWztln FDOAlInYqkSAYdDH2WSAQ9F8MQTdMzsWQycSZw5aYsr6mpxHOJv8Rt2R; 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: 4de5d7f989d6c039c8b887f1940f36ab Cc: Mobile IPv6 Mailing List , netlmm@ietf.org Subject: [Mip6] Re: I-D ACTION:draft-sgundave-mip6-proxymip6-01.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 Hi Brian, Thanks for such detailed review. Comments inline .. (Moving the thread to netlmm ml) On Thu, 18 Jan 2007, Brian Haley wrote: > Hi Sri, > > Internet-Drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Proxy Mobile IPv6 >> Author(s) : S. Gundavelli, et al. >> Filename : draft-sgundave-mip6-proxymip6-01.txt >> Pages : 39 >> Date : 2007-1-5 >> >> This specification describes a network-based mobility management >> protocol. It is called Proxy Mobile IPv6 (PMIPv6) and is based on >> Mobile IPv6. This protocol is for providing mobility support to any >> IPv6 host within a restricted and topologically localized portion of >> the network and with out requiring the participation of the host in >> any mobility related signaling. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-sgundave-mip6-proxymip6-01.txt > > I tried to go through the whole draft again, might have missed a few spots... > > -Brian > > > Some edits below, in some cases I just re-wrote the whole paragraph. > Thanks Brian. Appreciate it. I should give the xml version :) >> 5.5. Sequencing Number Considerations >> >> Sequence number is typically used by two communication end points as >> a means to establish order of the exchanged packets. Mobile IPv6 >> uses the Sequence Number field in the registrations messages. The >> home agent and the mobile are required to manage this counter. > > Mobile IPv6 uses the Sequence Number field in registration messages > as a way to ensure the correct packet ordering. The home agent and > mobile node are required to manage this counter over the lifetime of > a binding. > Ok. >> In Proxy Mobile IPv6, the Binding Update messages that the home agent >> receives on behalf of a specific mobile, may not be from the same >> proxy mobile agent and thus the sequence number value in these >> messages will have little meaning and the home agent will not be >> predictably order the messages and thus may end up processing an >> older message while ignoring the latest binding update message. > > In Proxy Mobile IPv6, the Binding Update messages that the home > agent receives on behalf of a specific mobile node may not be from > the same proxy mobile agent. In this case, the sequence number > value in these messages will have little meaning, and the home agent > will not be able to predictably order the messages. This could lead > to the home agent processing an older message, while ignoring the > latest binding update message. > >> In the Proxy Mobile IP model, where the ordering of packets have to >> established when multiple senders are involved, sequence number >> scheme in the absence of time context transfers will not work. A >> global scale such as a time stamp is the right way to ensure order of >> packets. This document proposes the use of time stamp in all the >> Binding Update messages sent by proxy mobile agents. By leveraging >> NTP [RFC-1305] service, all the entities in the Proxy Mobile IP >> Network will be able to synchronize the clocks and a time stamp field >> in the Binding Update message will enable the home agent to >> predictable identify the latest messages from a list of messages >> delivered in a out of order fashion. > > In the Proxy Mobile IPv6 model, the ordering of packets has to be > established when multiple senders are involved. The sequence number > scheme as specified in [RFC-3775] will not work. A global solution, > such as a time stamp, is a way to ensure the correct ordering of > packets. This document proposes the use of a new Time Stamp Option, > specified in Section 8.4, in all Binding Update messages sent by > proxy mobile agents. By leveraging the NTP [RFC-1305] service, all > the entities in Proxy Mobile IPv6 should be able to synchronize > their respective clocks. Having a time stamp option in Binding > Update messages will enable the home agent to predictably identify > the latest message from a list of messages delivered in an > out-of-order fashion. > Ok. >> The Proxy Mobile IP model, defined in this document requires the >> Binding Update messages sent by the proxy mobile agent to have the >> time stamp option. The home agent processing a proxy registration >> MUST ignore the sequence number field and SHOULD use the value from >> the Time Stamp option to establish ordering of the received Binding >> Update messages. If the home agent receives a Binding Update message >> with a invalid time stamp, the registration request MUST be rejected >> and a Binding Acknowledgement must be sent with the status "Invalid >> Time Stamp" and with the Time Stamp option. > > If the home agent receives a Binding Update message > with an invalid Time Stamp Option, the Binding Update MUST be > rejected and a Binding Acknowledgement MUST be returned in which the > Status field is set to 148 (invalid time stamp option). > > I don't think we need to send the Time Stamp option back, unless we're > sending one with the current time, right? > Yes. But, if need be, we can return the correct time for the proxy to sync up. >> 5.6. IPv4 Home Address Mobility Support >> >> The transition from IPv4 to IPv6 is a long process and during this >> period of transition, both the protocols will be enabled over the >> same infrastructure. It is reasonable to assume that the mobile node >> and the home agent are IPv4 and IPv6 enabled and further it is also >> reasonable to expect the same mobility infrastructure to provide IPv4 >> and IPv6 address mobility. The Proxy Mobile IPv6 scheme defined in >> this document allows the mobile node to obtain a IPv4 address and to >> roam in the network using the same address. > > s/obtain a IPv4/obtain an IPv4/ > Ok. >> A mobile node attached to a proxy mobile agent, when it sends a DHCP >> request, the network will ensure it gets a IPv4 address from its home >> address prefix. The DHCP Relay Agent on the access router will tag >> the DHCP request from the mobile node with its home prefix hint and >> the DHCP server will allocate an address from that prefix. The proxy >> mobile agent will send this information in the option, IPv4 Home >> Network Prefix Option as part of the Binding Update message. Upon >> accepting the registration for the mobile from the proxy mobile >> agent, the home address will add IPv4 host route over the tunnel to >> the proxy mobile agent. Any IPv4 packets that the home agent >> receives from the corresponding node will be routed to the proxy >> mobile agent over the IPv6/IPv6 tunnel and any IPv4 packets that it >> receives over the tunnel will be routed after removing the tunnel >> header. > > I was confused with this paragraph, I think in one case you used IPv4 when > you meant IPv6? > This is for the HoA support. We tried to explain how the IPv4 packets need to be routed. The Routing Considerations covered the specifics of the routing state. The home agent with its IPv4 address is the default IPv4 gateway for the mobile's IPv4 traffic. The proxy mobile agent does the proxy arp for the home agent on the access link and thus it receives all the IPv4 traffic that the mobile sends. That traffic needs to be sent over IPv6 transport i.e in the IPv6 tunnel. Will try to explain this better. > When a mobile node attached to a proxy mobile agent sends a DHCP > request, the network will ensure it gets an IPv6 address from its > home address prefix. The DHCP Relay Agent on the access router will > tag the DHCP request from the mobile node with its home prefix hint > and the DHCP server will allocate an address from that prefix. The > proxy mobile agent will send this information in a new option called > a Home Network Prefix Option, defined in Section 8.3, along with the > Binding Update message. Upon accepting the registration for the > mobile node from the proxy mobile agent, the home agent will add an > IPv4 host route over the tunnel to the proxy mobile agent. Any IPv4 > packets that the home agent receives from a correspondent node will > be tunneled to the proxy mobile agent over the IPv6/IPv6 tunnel, and > then routed accordingly after removing the tunnel header. > >> 5.7. Route Optimizations Considerations >> >> Mobile IPv6 route optimization, as defined in [RFC-3775], enables a >> mobile node to communicate with a corresponding node directly using >> its care-of address and further the Return Routability procedure >> enables the corresponding node to have reasonable trust that the mobile >> node owns both the home address and care-of address. > > Mobile IPv6 route optimization, as defined in [RFC-3775], enables a > mobile node to communicate with a correspondent node directly using > its care-of address, the Return Routability procedure establishes > reasonable trust that the mobile node owns both the home address and > care-of address. > Ok >> In the Proxy Mobile IPv6 model, the mobile is not involved in any >> mobility related signaling and also it does not operate in the dual- >> address mode. Hence, the return routability procedure as defined in >> RFC-3775 is not applicable for the proxy model. This document does >> not address the Route Optimization problem and leaves this work item >> for future enhancements. > > In the Proxy Mobile IPv6 model, the mobile node is not involved in > any mobility related signaling, therefore the return routability > procedure as defined in [RFC-3775] is not applicable. > > I think you can delete that last sentence because this document *is* > addressing the Route Optimization problem a little bit, right? :) > The document is not supporting RO. Ok, we should remove that. >> This specification further recommends that the home agent MUST drop >> all HoTI messages received from a home address that has corresponding >> Binding Cache entry with the proxy registration flag set. > > "Recommends" implies SHOULD, I'd change it: > > Proxy Mobile IPv6 home agents MUST drop all HoTI messages received > from a home address that has corresponding Binding Cache entry with > the proxy registration flag set. > Ok. > And should it send an error? > I dont think this is covered in 3775. Not sure, what the behaviour should be when this is dropped ? Administrative reason ? Will check the spec. >> 5.9. Home Agent Operation Summary > [...] >> For supporting this scheme, the home agent MUST satisfy all the >> requirements listed in Section 8.4 of [1]. The key differences of >> this scheme for the Per-MN-Prefix configuration mode, when compared >> to the base protocol is as follows: > > [1] doesn't have any meaning, maybe you meant [RFC-3775] ? Yes. [1] should be RFC-3775. We will fix this. > >> The mobile node is not anchored on any physical interface on the home >> agent. Thus the home agent is not required to perform any proxy ND >> operations for defending the home address on the home link. The home >> agent is required to manage a binding cache entry for managing the >> session state and a routing state for properly routing the packets >> destined to the mobile node. > > I thought it needed to do proxy ND... > In PMIP, the mobile's home prefixes are typically configured on a virtual link. There is no phsical home. So, Proxy ND is not required. >> Each mobile node has a home address in a prefix that is created >> exclusively for that mobile node and no other mobile node will share >> its home address from this prefix. >> >> The route entry specifying that the mobile node's home prefix is >> reachable via the tunnel is created as supposed to creating an route >> entry just for the mobile node's home address. > > s/as supposed to creating an/as opposed to creating a/ > Sure. > I also have another question about these three paragraphs. Back in Section 5 > (and 6.1) it's said that there are two models - Per-MN-Prefix and the "usual" > Shared-Prefix, these paragraphs don't allow for a Shared-Prefix model. > The doc evolved from Per-MN-Prefix ... we need to add more text where ever needed. > [...] > >> 8.1. Proxy Binding Update > > A new flag (P) is included in the Binding Update to indicate to the > Home Agent whether the Binding Update is coming from a Proxy Mobile > Agent and not from a mobile node. The rest of the Binding Update > format remains the same as defined in [RFC-3775]. > >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Sequence # | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | A|H|L|K|M|R|P| Reserved | Lifetime | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Figure 8: Proxy Binding Update Message >> >> A new flag, the 'P' flag, is added to the Binding Update message >> [RFC-3775]. The 'P' flag indicates that the registration is a Proxy >> Registration. When a proxy mobile agent sends a registration to the >> home agent, the P flag MUST be set to value of 1, to indicate to the >> home agent that this registration is a proxy registration sent by a >> proxy mobile agent on behalf of a mobile node. > > Proxy Registration Flag (P) > > The Proxy Registration Flag is set to indicate to the Home Agent > that the Binding Update is from a Proxy Mobile Agent acting on > behalf of a Mobile Node. When a Proxy Mobile Agent sends a > Binding Update to a Home Agent, it MUST set this flag to 1. > >> For descriptions of other fields present in this message, refer to >> [RFC3775]. > > RFC-3775 only defined AHLK, you should add a reference to NEMO [RFC-3963] for > R, but I can't think of the other. > Flags from HMIP and NEMO. >> 8.2. Proxy Binding Acknowledgment > > A new flag (P) is included in the Binding Acknowledgement to indicate > that the Home Agent that processed the corresponding Binding Update > supports Proxy Registrations. The flag is set only if the > corresponding Binding Update had the Proxy Registration Flag (P) set > to 1. The rest of the Binding Acknowledgement format remains the > same, as defined in [RFC-3775]. > >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Status |K|R|P|Reserved | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Sequence # | Lifetime | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Figure 9: Proxy Binding Acknowledgment Message >> >> Proxy Registration Flag (P) >> >> A new flag, the 'P' flag, is added to the Binding Acknowledgement >> message [RFC-3775]. The Proxy Registration Flag is set to a value of >> 1, to indicate that the home agent that processed the Proxy Binding >> Update supports Proxy Registration. This flag value is set only if >> the corresponding Proxy Binding Update had the Proxy Registration >> Flag set. > > Proxy Registration Flag (P) > > The Proxy Registration Flag is set to indicate that the Home > Agent that processed the Binding Update supports Proxy > Registrations. It is set to 1 only if the corresponding Binding > Update had the Proxy Registration Flag set to 1. > Ok >> For descriptions of other fields present in this message, refer to >> [RFC3775]. > > and [RFC-3963]. > Ok >> 8.3. Home Network Prefix Option >> >> A new option, Home Network Prefix Option is defined for using it in >> the Proxy Binding Update and Acknowledgment messages exchanged >> between the home agent to the proxy mobile agent. This option can be >> used for exchanging the mobile node's home prefix and home address >> information. > > The Home Network Prefix Option is included in Proxy Binding Update > and Acknowledgement messages to indicate the home prefix information > or home address for the mobile node. > >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Type | Length | Reserved | Prefix Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | >> + + >> | | >> + Local Network Prefix + >> | | >> + + >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > s/Local Network Prefix/Home Network Prefix/ > Ok. >> Length >> >> Eight-bit unsigned integer indicating the length in octets of >> the option, excluding the type and length fields. Set to 18. > > s/Eight-bit/8-bit > s/Set to 18/This field MUST be set to 18/ > > (I can now tell the NEMO RFC was copy/pasted :) > Guilty ! For this MNP option. >> Reserved >> >> This field is unused for now. The value MUST be initialized >> to 0 by the sender and MUST be ignored by the receiver. > >> Prefix Length >> >> Eight-bit unsigned integer indicating the prefix length of >> the IPv6 prefix contained in the option. If the prefix length >> is set to the value 128, indicates the presence of the >> mobile's home address. > > s/Eight-bit/8-bit > Ok > >> Home Network Prefix >> >> A sixteen-byte field containing the Home Network Prefix > > Contains either the Home Network Prefix or a Home Address. > > The Time Stamp Option needs similar changes (like Length) as above. ?? > >> 8.5. Status Codes >> >> Binding Acknowledgment Status Values >> >> The following status code values are defined for using them in the >> Binding Acknowledgment message when using PMIPv6 protocol. > > You can replace both with: > > This document defines the following new Binding Acknowledgement > status values: > > Ok Again, thanks for the review. Regards Sri _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jan 22 08:50:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8zZ8-0000IZ-Gj; Mon, 22 Jan 2007 08:50:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8zZ6-0000Gy-Sh for mip6@ietf.org; Mon, 22 Jan 2007 08:50:28 -0500 Received: from mail.um.es ([155.54.212.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8zZ5-00061O-B5 for mip6@ietf.org; Mon, 22 Jan 2007 08:50:28 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.um.es (Postfix) with ESMTP id C5F3023CC0C for ; Mon, 22 Jan 2007 14:50:26 +0100 (CET) Received: from mail.um.es ([127.0.0.1]) by localhost (xenon2 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 18861-01-89 for ; Mon, 22 Jan 2007 14:50:26 +0100 (CET) Received: from [155.54.205.230] (inf-205-230.um.es [155.54.205.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.um.es (Postfix) with ESMTP id A33B423CBC7 for ; Mon, 22 Jan 2007 14:50:26 +0100 (CET) Message-ID: <45B4C126.1090207@dif.um.es> Date: Mon, 22 Jan 2007 14:50:30 +0100 From: "Pedro M. Ruiz" User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mip6@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at telemat.um.es X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Subject: [Mip6] CFP: ACM MobiCom 2007, September 4-9 2007, Montreal, QC, Canada 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 Apologies if you receive multiple copies of this message. CALL FOR PAPERS MobiCom 2007 The Thirteenth Annual International Conference on Mobile Computing and Networking September 9-14, 2007 Montreal, QC, Canada http://www.sigmobile.org/mobicom/2007/ Sponsored by ACM SIGMOBILE ACM MobiCom is the premier international conference dedicated to addressing the challenges in the areas of mobile computing and wireless and mobile networking. It has served as an exciting international forum since 1995, addressing networks, systems, algorithms, and applications that support the symbiosis of mobile computers and wireless networks. MobiCom is a highly selective conference focusing on all issues in mobile computing and wireless and mobile networking at the link layer and above. New this year, Mobicom will be jointly held with ACM Mobihoc. The two conferences will run in parallel, and will have many joint plenary sessions (such as the keynote, panels, and welcoming reception). Authors are invited to submit full papers, challenges papers, student posters, and research demos and exhibits, presenting new research related to the theory or practice of mobile computing and/or wireless and mobile networking. All submissions must describe original research, not published or currently under review for another conference or journal. Areas of interest include, but are not limited to: * Architectures, protocols, and algorithms to cope with mobility, limited bandwidth, limited power and/or intermittent connectivity * Applications and services for mobile users * Cyber-physical computing and networking * Delay/disruption tolerant networks * Fundamental understanding of mobile computing and wireless networking * Implementations and experimental testbeds for mobile/wireless networks * Integration and interworking of wired and wireless networks * Modeling, measurement and simulation of mobile networks * Mobile ad hoc and sensor networks * Operating system and middleware support for mobile computing and networking * Performance evaluation of mobile and wireless networks and systems * Protocols exploiting dynamic spectrum, UWB, MIMO, directional antennas * Resource management and quality-of-service for real-time traffic support * Security, privacy, and fault-tolerance of mobile/wireless systems * Wireless access technologies (e.g., mesh networks, personal area networks) Submission Instructions Detailed instructions on how and where to submit your paper can be found at http://www.sigmobile.org/mobicom/2007/cfp.html Panel proposals must be submitted by February 23 to either of the panel co-chairs: Martha Steenstrup (steenie@rcn.com) Ioanis Nikolaidis (yannis@cs.ualberta.ca) Important Dates Abstracts submission due: February 23, 2007 Panel proposals submission due: February 23, 2007 Paper submissions due: March 2, 2007 Notification of acceptance: June 4, 2007 Camera-ready version due: June 29, 2007 General Chair: Evangelos Kranakis, kranakis@scs.carleton.ca Technical Co-Chairs: Jennifer C. Hou, jhou@cs.uiuc.edu Ram Ramanathan, ramanath@bbn.com FOR MORE INFORMATION: Please contact the General Chair or Program Co-Chairs for more information. For information on ACM SIGMOBILE and the MobiCom series of conferences, see http://www.sigmobile.org/ or contact mobicom_info@acm.org. -- --------------------------------------------------------------------- Pedro M. Ruiz, Ph.D. E-mail: pedrom@dif.um.es Fac. Informatica, Univ. of Murcia Phone: +34968364335 Campus de Espinardo s/n Fax: +34968364151 E-30100, Espinardo, Murcia www: ants.dif.um.es/~pedrom/ SPAIN --------------------------------------------------------------------- _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jan 22 15:50:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H967V-0007MT-FA; Mon, 22 Jan 2007 15:50:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9679-00078Q-Dq; Mon, 22 Jan 2007 15:50:03 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9679-0007BB-1X; Mon, 22 Jan 2007 15:50:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 7B51C26EB9; Mon, 22 Jan 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H9678-00082E-43; Mon, 22 Jan 2007 15:50:02 -0500 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, 22 Jan 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: mip6@ietf.org Subject: [Mip6] I-D ACTION:draft-ietf-mip6-dsmip-problem-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 : Problem Statement: Dual Stack Mobility Author(s) : H. Soliman, G. Tsirtsis Filename : draft-ietf-mip6-dsmip-problem-03.txt Pages : 15 Date : 2007-1-22 This draft discusses the issues associated with mobility management for dual stack mobile nodes. Currently, two mobility management protocols are defined for IPv4 and IPv6. Deploying both in a dual stack mobile node introduces a number of problems. Deployment and operational issues motivate the use of a single mobility management protocol. This draft discusses such motivations. The draft also discusses requirements for the Mobile IPv4 and Mobile IPv6 protocol so that they can support mobility management for a dual stack node. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-dsmip-problem-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-dsmip-problem-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-dsmip-problem-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-1-22141851.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-dsmip-problem-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-dsmip-problem-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-22141851.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 Tue Jan 23 22:03:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9YPe-0000ha-29; Tue, 23 Jan 2007 22:03:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9YPc-0000gt-0l; Tue, 23 Jan 2007 22:03:00 -0500 Received: from mailhub.hp.com ([192.151.27.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9YP9-0003UM-2q; Tue, 23 Jan 2007 22:02:35 -0500 Received: from [192.168.1.100] (c-24-91-248-53.hsd1.ma.comcast.net [24.91.248.53]) by mailhub.hp.com (Postfix) with ESMTP id B89C72710F; Tue, 23 Jan 2007 22:02:22 -0500 (EST) Message-ID: <45B6CC6B.9000902@hp.com> Date: Tue, 23 Jan 2007 22:03:07 -0500 From: Brian Haley Organization: Open Source and Linux Organization User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Sri Gundavelli Subject: Re: [Mip6] Re: I-D ACTION:draft-sgundave-mip6-proxymip6-01.txt References: <45AFABF6.5020508@hp.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: Mobile IPv6 Mailing List , netlmm@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 Sri, Sri Gundavelli wrote: >>> A mobile node attached to a proxy mobile agent, when it sends a DHCP >>> request, the network will ensure it gets a IPv4 address from its >>> home >>> address prefix. The DHCP Relay Agent on the access router will tag >>> the DHCP request from the mobile node with its home prefix hint and >>> the DHCP server will allocate an address from that prefix. The >>> proxy >>> mobile agent will send this information in the option, IPv4 Home >>> Network Prefix Option as part of the Binding Update message. Upon >>> accepting the registration for the mobile from the proxy mobile >>> agent, the home address will add IPv4 host route over the tunnel to >>> the proxy mobile agent. Any IPv4 packets that the home agent >>> receives from the corresponding node will be routed to the proxy >>> mobile agent over the IPv6/IPv6 tunnel and any IPv4 packets that it >>> receives over the tunnel will be routed after removing the tunnel >>> header. >> >> I was confused with this paragraph, I think in one case you used IPv4 >> when you meant IPv6? > > This is for the HoA support. We tried to explain how the IPv4 > packets need to be routed. The Routing Considerations covered > the specifics of the routing state. The home agent with its > IPv4 address is the default IPv4 gateway for the mobile's IPv4 > traffic. The proxy mobile agent does the proxy arp for the home > agent on the access link and thus it receives all the IPv4 traffic > that the mobile sends. That traffic needs to be sent over IPv6 > transport i.e in the IPv6 tunnel. Will try to explain this better. So now I have a larger-scope question - should a Proxy Mobile IPv6 draft even be defining how IPv4 addresses will be supported? Maybe an appendix area could state how this *might* work? >>> This specification further recommends that the home agent MUST drop >>> all HoTI messages received from a home address that has >>> corresponding >>> Binding Cache entry with the proxy registration flag set. >> >> "Recommends" implies SHOULD, I'd change it: >> >> Proxy Mobile IPv6 home agents MUST drop all HoTI messages received >> from a home address that has corresponding Binding Cache entry with >> the proxy registration flag set. >> > > Ok. > >> And should it send an error? > > I dont think this is covered in 3775. Not sure, what the > behaviour should be when this is dropped ? Administrative > reason ? Will check the spec. I don't think 3775 defines anything, just that HoTIs are dropped if it has a HAOption. I guess you could just say it MUST be silently ignored. >> The Time Stamp Option needs similar changes (like Length) as above. > > ?? I meant this: > Length > > Eight-bit unsigned integer indicating the length in octets of > the option, excluding the type and length fields. Set to 18. s/Eight-bit/8-bit s/Set to 18/This field MUST be set to 18/ > Timestamp > > 64bit time stamp s/64bit/64-bit -Brian _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jan 23 22:23:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9YjO-0000u6-Qr; Tue, 23 Jan 2007 22:23:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9YjN-0000ty-TG; Tue, 23 Jan 2007 22:23:25 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9YjM-0001t6-JE; Tue, 23 Jan 2007 22:23:25 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 23 Jan 2007 19:23:24 -0800 X-IronPort-AV: i="4.13,227,1167638400"; d="scan'208"; a="104790052:sNHT43715718" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l0O3NNuI030572; Tue, 23 Jan 2007 19:23:23 -0800 Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.70.65.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0O3NMDl007380; Tue, 23 Jan 2007 19:23:22 -0800 (PST) Date: Tue, 23 Jan 2007 19:23:22 -0800 (PST) From: Sri Gundavelli To: Brian Haley Subject: Re: [Mip6] Re: I-D ACTION:draft-sgundave-mip6-proxymip6-01.txt In-Reply-To: <45B6CC6B.9000902@hp.com> Message-ID: References: <45AFABF6.5020508@hp.com> <45B6CC6B.9000902@hp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2335; t=1169609004; x=1170473004; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20Re=3A=20[Mip6]=20Re=3A=20I-D=20ACTION=3Adraft-sgundave-mip6-p roxymip6-01.txt |Sender:=20; bh=sGufEzQciJmXKgQiSeIx8aV8bThGm1/G3PP6oMxTHhs=; b=ZuoFUxLLSdd25Ct5/nMLX4O9BTqbWZkFvXMgzSnYOpvWz1FoPFMYBUkQyQazg8W09FZCum2f WgfOF5wq4wFkPllDavpPphYzZiZst6c7yD1pW/MVOf0qajNnh5hEhf1G; Authentication-Results: sj-dkim-3; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: Mobile IPv6 Mailing List , netlmm@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 Brian, On Tue, 23 Jan 2007, Brian Haley wrote: >> This is for the HoA support. We tried to explain how the IPv4 >> packets need to be routed. The Routing Considerations covered >> the specifics of the routing state. The home agent with its >> IPv4 address is the default IPv4 gateway for the mobile's IPv4 >> traffic. The proxy mobile agent does the proxy arp for the home >> agent on the access link and thus it receives all the IPv4 traffic >> that the mobile sends. That traffic needs to be sent over IPv6 >> transport i.e in the IPv6 tunnel. Will try to explain this better. > > So now I have a larger-scope question - should a Proxy Mobile IPv6 draft even > be defining how IPv4 addresses will be supported? Maybe an appendix area > could state how this *might* work? > There seems to be lot of interest for IPv4 addressing and transport. We can safely assume most mobiles that are IPv6 capable will have IPv4 support and since we cannot expect the operator to deploy two mobility management systems for managing IPv4 and IPv6 HoA mobility, this appears to be an important problem. And the adoption of DSMIP4 and DSMIP6 in the WG, suggest the same and so wanted to address this in detail. Support for IPv4 HoA, is more than the creating a entry in the BCE, there are details on how the proxy mobile agent has to proxy ARP for the default router ..etc. So, we put it in the main part of the document. >> > And should it send an error? >> >> I dont think this is covered in 3775. Not sure, what the >> behaviour should be when this is dropped ? Administrative >> reason ? Will check the spec. > > I don't think 3775 defines anything, just that HoTIs are dropped if it has a > HAOption. I guess you could just say it MUST be silently ignored. > Ok. That should work. >> > The Time Stamp Option needs similar changes (like Length) as above. >> >> ?? > > I meant this: > >> Length >> >> Eight-bit unsigned integer indicating the length in octets of >> the option, excluding the type and length fields. Set to 18. > > s/Eight-bit/8-bit > s/Set to 18/This field MUST be set to 18/ > >> Timestamp >> >> 64bit time stamp > > s/64bit/64-bit > Sure. Ok. Thanks for the review. Sri _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jan 26 17:24:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAZU2-0001lk-MM; Fri, 26 Jan 2007 17:23:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAZU0-0001cQ-6D for mip6@ietf.org; Fri, 26 Jan 2007 17:23:44 -0500 Received: from mail.unilim.fr ([164.81.1.45] helo=smtp.unilim.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAZTs-0002Mj-Tg for mip6@ietf.org; Fri, 26 Jan 2007 17:23:44 -0500 Received: from [192.168.0.2] ([84.4.52.120]) (authenticated bits=0) by smtp.unilim.fr (8.13.1/8.13.1) with ESMTP id l0QMNSJg007796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 26 Jan 2007 23:23:28 +0100 Message-ID: <45BA7F60.7020205@xlim.fr> Date: Fri, 26 Jan 2007 23:23:28 +0100 From: Damien Sauveron User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: fr, en MIME-Version: 1.0 To: mip6@ietf.org Content-Type: text/plain; charset=windows-1252; format=flowed X-Univ-Limoges-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (smtp.unilim.fr [164.81.1.45]); Fri, 26 Jan 2007 23:23:29 +0100 (CET) X-Univ-Limoges-MailScanner-Information: Serveur Anti-virus Please contact the SCI, Univ. of Limoges, for more information X-Univ-Limoges-MailScanner: Found to be clean X-Univ-Limoges-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (cached, score=-104.389, requis 6, autolearn=not spam, ALL_TRUSTED -1.80, BAYES_00 -2.60, NO_RDNS2 0.01, SMTP_AUTH -100.00) X-Univ-Limoges-MailScanner-Envelope-From: damien.sauveron@xlim.fr Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by smtp.unilim.fr id l0QMNSJg007796 X-Spam-Score: 0.0 (/) X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 Subject: [Mip6] [WISTP2007] Deadline extended to February 1st X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: wistp2007sec@xlim.fr List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Due to several requests, the deadline is extended to February 1st (firm deadline) ******************************************************************* We apologize in advance if you receive multiple copies of this CFP. Please disseminate it to your colleagues that could be interested. ******************************************************************* Workshop in Information Security Theory and Practices 2007: Smart Cards, Mobile and Ubiquitous Computing Systems && A networking meeting to discuss proposals for the EU FP7 Heraklion, Crete, Greece May 9-11, 2007 Workshop URL: http://wistp2007.xlim.fr/ ******************************************************* WISTP2007 is: - Co-Sponsored by IFIP TC6 Communications Systems - Co-Sponsored by IFIP WG 8.8 Smart Cards - Co-Sponsored by IFIP WG 11.2 Small System Security - Co-Sponsored by The British Computer Society - In Cooperation with the IEEE Computer Society, Technical Committee on Security and Privacy (TCSP) - In Cooperation with the IEEE Computer Society, Task Force on Information Assurance (TFIA) - In Cooperation with the IEEE Systems, Man, and Cybernetics Society, Technical Committee on Information Assurance & Intelligent Multimedia-Mobile Communications - In Cooperation with the IEEE Systems, Man, and Cybernetics Society, Technical Committee on Systems Safety and Security - In Cooperation with the IEEE Vehicular Technology Society - Supported by the IEEE France Section - Supported by the IEEE UKRI Section & by the IEEE UKRI Section - Compute= r Society Chapter - Supported by the IEEE Greece Section - Communications Society & Compute= r Society & VT&AESS Chapters - Supported by the EuroSys (European ACM SIGOPS Chapter) - Supported by the ASF (French ACM SIGOPS Chapter) - Supported by the Greek Computer Society - Supported by the ASTI - Supported by the Institute for Systems and Technologies of Information, Control and Communication (INSTICC) - Supported by the SEE - Supported by the GDR CNRS ASR - Supported by the VDE ITG ******************************************************* WISTP2007 Background and Goals: With the rapid technological development of information technologies, computer systems and especially embedded systems are becoming more mobile and ubiquitous, increasingly interfacing with the physical world. Ensuring the security of these complex and yet, resource constraint systems has emerged as one of the most pressing challenges. The aim of this first workshop is to bring together researchers and practitioners in related areas and to encourage interchange and cooperation between the research community and the industrial/consumer community. The workshop will consist of technical paper presentations, one special session for student papers and five invited talks. To contribute to the structuring of the community, a networking meeting to discuss EU FP7 projects proposals will take place just after the workshop. ******************************************************* Topics of interest include, but are not limited to: A. Smart Cards and Trusted Devices Security * Biometrics, National ID cards * Embedded Systems Security and TPMs * Interplay of TPMs and Smart Cards * New Applications for Secure RFID Systems * RFID Systems Security * Smart Card Security * Smart Card Applications B. Ad Hoc and Mobile Networks Security * Ad Hoc Networks Security * Delay-Tolerant Network Security * Domestic Network Security * Mobile Codes Security * Mobile Devices Security * Security Issues in Mobile and Ubiquitous Networks * Security of GSM/GPRS/UMTS Systems * Sensor Networks Security * Vehicular Network Security * Wireless Communication Security (WiFi, WiMAX, WiMedia, others) C. Ubiquitous Computing Systems Security * Distributed Systems Security * Grid Computing Security * Intrusion Detection and Information Filtering * Peer-to-Peer Networks Security D. Security Protocols, Policies and Management for Mobility * Critical Infrastructure (e.g. for Medical or Military Applications) Security * Digital Rights Management (DRM) * Industrial and Multimedia Applications * Information Assurance * Localization Systems Security (Tracking of People and Goods) * New Applications of Secure Systems * Public Administration and Governmental Services * Security Models and Architecture * Security Policies (Human-Computer Interaction and Human Behavior Impact) * Security Protocols (for Identification and Authentication, Confidentiality and Privacy, and Integrity) * Security Measurements * Trust Management ******************************************************* Submission Details: Authors are invited to submit original papers (written in english) not previously published nor submitted in parallel for publication to any other conference, workshop or journal. All submissions will be subjected to thorough blind review by at least three reviewers (if the paper involved a Program Committee member, the paper will be reviewed at least by five reviewers). All submitted papers should be anonymous with no author(s) names, affiliations, acknowledgments, nor obvious references. Each paper should begin with a title, a short abstract, and a list of keywords, following the template indicated by Springer at: http://www.springer.de/comp/lncs/authors.html The papers will be in .pdf format, at most 10 pages long excluding bibliography and well-marked appendices, and at most 14 pages long in total, using at least 11-point fonts with reasonable margins. As the reader should not be required to read any appendices, the paper should be intelligible even without them. 20 papers will be accepted for presentation at the workshop (they will be included in the proceedings) and 12 additional papers will be selected to be presented as A1 poster at the workshop (they will NOT be included in the proceedings). If a submitted paper is mainly the result of the work of a student author, this paper could have the chance to be selected as "Best student paper" (even if the paper has been written with senior co-authors). To participate to this selection process, please add the word "STUDENT" in the affiliation field in the submission form. At least one author of each accepted paper is required to register with the Conference and present the paper. For authors presenting multiple papers, one normal registration is valid for up to two papers. For electronic paper submission please use the following URL: https://wistp2007.xlim.fr/wistp2007/iChair/ ******************************************************* Awards: * Best student paper: 400=80 + a CD-Rom version of the Handbook of Information Security * Best workshop paper: 400=80 + a CD-Rom version of the Handbook of Information Security * Best innovative technology: Gift + a CD-Rom version of the Handbook of Information Security Authors of the best works in the Smart Card domain selected by the PC co-chairs of the international conference Cardis'2008 (Fran=E7ois-Xavier Standaert, Gilles Grimaud) will be encouraged to submit extended and significantly revised versions at Cardis'2008. Some accepted papers written by French-speaking authors will be published in a journal of the SEE (in a french version). ******************************************************* Important Dates: - Intention of submission: ASAP. Send a mail to wistp2007sec@xlim.fr - Intention of attendance: ASAP. Send a mail to wistp2007sec@xlim.fr - Paper submission: February 1st, 2007 (23h59 UTC) - firm - - Notification: March 1st, 2007 - Author Registration: March 3rd, 2007 - Camera-ready papers: March 5th, 2007 ******************************************************* WISTP2007 Committees and Chairs: - Workshop Organization Chair: Damien Sauveron. XLIM, University of Limoges, France - Workshop Organizing Committee: Angelos Bilas. FORTH-ICS & University of Crete, Greece Konstantinos Markantonakis. ISG-SCC, Royal Holloway University of London, UK Damien Sauveron. XLIM, University of Limoges, France - Workshop co-chairs: Jean-Jacques Quisquater. DICE, Catholic University of Louvain, Belgium Konstantinos Markantonakis. ISG-SCC, Royal Holloway University of London, UK - Workshop Program Committee: Fran=E7ois Arnault. XLIM, University of Limoges, France Angelos Bilas. FORTH-ICS & University of Crete, Greece Christophe Bidan, SSIR, Sup=E9lec, France Pierre-Fran=E7ois Bonnefoi. XLIM, University of Limoges, France Serge Chaumette. LaBRI, University Bordeaux 1, France Pierre Dusart. XLIM, University of Limoges, France Eduardo Fern=E1ndez-Medina Pat=F3n. Alarcos Research Group, University= of Castilla-La Mancha, Spain Theodoulos Garefalakis, Department of Mathematics, University of Crete, Greece Dieter Gollmann. Security in Distributed Applications, Institutes of the TU Hamburg-Harburg, Germany Stefanos Gritzalis. Info-Sec-Lab, University of the Aegean, Greece Olivier Heen. Security Laboratory, Thomson R&D, France Sokratis Katsikas. Info-Sec-Lab, University of the Aegean, Greece Javier Lopez. Computer Science Department, University of Malaga, Spain Konstantinos Markantonakis. ISG-SCC, Royal Holloway University of London, UK Evangelos P. Markatos. FORTH-ICS & University of Crete, Greece Fabio Martinelli. Information Security Group, IIT-CNR, Italy Keith Mayes. ISG-SCC, Royal Holloway University of London, UK Jan de Meer. smartspacelab.eu, Brandenburg Technical University (BTU), Germany Pierre Paradinas. CEDRIC, CNAM, France Kenny Paterson. ISG, Royal Holloway University of London, UK Joachim Posegga, Security in Distributed Systems, University of Hamburg, Germany Jean-Jacques Quisquater. DICE, Catholic University of Louvain, Belgium Pierangela Samarati. Department of Information Technologies, University of Milan, Italy Damien Sauveron. XLIM, University of Limoges, France Paulo Jorge Esteves Ver=EDssimo, LASIGE, University of Lisboa, Portuga= l ******************************************************* Keynote Speakers: - Professor Fred Piper, ISG (Information Security Group), Royal Holloway University of London, UK - Professor Jean-Pierre Hubaux, LCA ( Laboratory for computer Communicati= ons and Applications), EPFL, Switzerland - Stephanie Manning, Chief Engineer, Research and Development, Vodafone Group Services Limited - TBA ******************************************************* Opportunities for students: To help the students looking for a PhD thesis or a postdoctoral position, we will propose them to add a colorized sticker on their badge. In the same way, we will propose to persons offering these positions to add a sticker with a different color. We hope this mechanism will help to support the exchanges between young and senior researchers. ******************************************************* Thanks to our main sponsors: Crisp Telecom Eurosmart Elopsys Limousin Expansion Nokia Vodafone WILEY ******************************************************* We hope you will be interested by this event. For further inquiries, please contact the secretariat at wistp2007sec@xlim.fr Best regards, --=20 Damien Sauveron _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jan 30 18:31:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC2RX-0007W5-Fe; Tue, 30 Jan 2007 18:31:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC2RW-0007W0-3s for mip6@ietf.org; Tue, 30 Jan 2007 18:31:14 -0500 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HC2RU-0005g4-8Z for mip6@ietf.org; Tue, 30 Jan 2007 18:31:14 -0500 Received: from ep_mmp2 (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 <0JCP00CKBFZY6L@mailout1.samsung.com> for mip6@ietf.org; Wed, 31 Jan 2007 08:31:10 +0900 (KST) Received: from your655e9d6f61 ([168.219.198.109]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0JCP009WPFZY1U@mmp2.samsung.com> for mip6@ietf.org; Wed, 31 Jan 2007 08:31:10 +0900 (KST) Date: Wed, 31 Jan 2007 08:30:59 +0900 From: Daniel Park To: MIP6 WG Message-id: <00de01c744c6$b34bef60$6dc6dba8@your655e9d6f61> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Subject: [Mip6] Fw: I-D ACTION:draft-daniel-mip-link-characteristic-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 FYI. This document introduces a model for link characteristic information delivery from the mobile node to the home agent and correspondent node(s). This model allows the home agent and correspondent node(s) to know the characteristics of the link the mobile node is currently attached to. Based on this information, the home agent and correspondent node(s) may shape ongoing traffic according to the current available link capacity (e.g. bandwidth) to the mobile node. Comments are highly welcome. Daniel (Soohong Daniel Park) Mobile Convergence Laboratory, SAMSUNG Electronics. ----- Original Message ----- From: To: Sent: Wednesday, January 31, 2007 5:50 AM Subject: I-D ACTION:draft-daniel-mip-link-characteristic-03.txt >A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Link Characteristics Information for Mobile IP > Author(s) : S. Park, et al. > Filename : draft-daniel-mip-link-characteristic-03.txt > Pages : 12 > Date : 2007-1-30 > > This document introduces a model for link characteristic information > delivery from the mobile node to the home agent and correspondent > node(s). This model allows the home agent and correspondent node(s) > to know the characteristics of the link the mobile node is currently > attached to. Based on this information, the home agent and > correspondent node(s) may shape ongoing traffic according to the > current available link capacity (e.g. bandwidth) to the mobile node. > This model can be applicable for Mobile IPv4 as well as Mobile IPv6. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-daniel-mip-link-characteristic-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-daniel-mip-link-characteristic-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-daniel-mip-link-characteristic-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. > -------------------------------------------------------------------------------- > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jan 30 18:52:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC2m3-0003sm-7a; Tue, 30 Jan 2007 18:52:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC2m1-0003se-6q; Tue, 30 Jan 2007 18:52:25 -0500 Received: from smtp19.orange.fr ([80.12.242.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HC2lw-0003Wi-UP; Tue, 30 Jan 2007 18:52:25 -0500 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf1917.orange.fr (SMTP Server) with ESMTP id 63F5B1C000B1; Wed, 31 Jan 2007 00:52:20 +0100 (CET) Received: from xpsp2-271b552dc.lan (LPuteaux-151-41-30-75.w217-128.abo.wanadoo.fr [217.128.82.75]) by mwinf1917.orange.fr (SMTP Server) with ESMTP id 24AC81C0008F; Wed, 31 Jan 2007 00:52:20 +0100 (CET) X-ME-UUID: 20070130235220150.24AC81C0008F@mwinf1917.orange.fr From: Guillaume FORTAINE Organization: Power.org To: sigtran@ietf.org Date: Wed, 31 Jan 2007 00:52:15 +0100 User-Agent: KMail/1.9.5 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200701310052.16023.guillaume.fortaine@wanadoo.fr> X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: mip6@ietf.org Subject: [Mip6] SCTP - Mobile Ipv6 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 Misters, Happy New Year to you. Would not it be SCTP the best Transport protocol for NGNs ? http://www.tml.tkk.fi/Studies/T-110.551/2004/papers/Ratola.pdf Maybe we should merge the best of SCTP and Mobile Ipv6 under a common name ? Which starting point could be the best : msctp or cstp ? I look forward to your answer, Best Regards, =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Guillaume _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jan 31 03:51:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCBAQ-0002DY-AS; Wed, 31 Jan 2007 03:50:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCBAO-0002DI-7S for mip6@ietf.org; Wed, 31 Jan 2007 03:50:08 -0500 Received: from otm-mgo00.iij.ad.jp ([210.138.20.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCBAM-0000It-Kl for mip6@ietf.org; Wed, 31 Jan 2007 03:50:08 -0500 Received: OTM-MO(otm-mgo00) id l0V8o4J4055462; Wed, 31 Jan 2007 17:50:04 +0900 (JST) Received: OTM-MIX(otm-mix00) id l0V8o4Wp048313; Wed, 31 Jan 2007 17:50:04 +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 l0V8o3l6093886 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 31 Jan 2007 17:50:04 +0900 (JST) Mime-Version: 1.0 (Apple Message framework v752.3) To: mip6@ietf.org Message-Id: <249F62F0-967F-40F7-9A94-61AFA92AE595@iijlab.net> From: Keiichi SHIMA Date: Wed, 31 Jan 2007 17:50:05 +0900 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: Kazunori MIYAZAWA Subject: [Mip6] Question about draft-sugimoto-mip6-pfkey-migrate 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="===============0892810605==" Errors-To: mip6-bounces@ietf.org --===============0892810605== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-15-800160949; protocol="application/pkcs7-signature" --Apple-Mail-15-800160949 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hello, I have a question about the PF_KEY extension draft (draft-sugimoto- mip6-pfkey-migrate). The draft proposes SADB_ACQUIRE message extension to include the entire (or the beginning of the) IP header that triggered the acquire message. The reason of the extension described in the draft is to extract the CoA of an MN that is used for IKE communication. The question is that, do we need to include the entire (or the beginning of the) packet to the acquire message? If the goal is to provide the CoA information to an IKE program, then why can't we simply notify the address? Including a raw packet has two drawbacks. 1. The IKE program that supports this extension has to parse the raw IPv6 packet to extract a CoA. 2. Some kernel implementations do not have the final packet structure when sending an ACQUIRE message. In these implementations, they only have abstract information to construct the packet, and the packet will be constructed just before it is sent. In this case, the kernel must create a packet before sending an ACQUIRE message, that is not necessary in their design. What do you think? --- Keiichi SHIMA IIJ Research Laboratory WIDE Project --Apple-Mail-15-800160949 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKbjCCBF8w ggJHoAMCAQICAhIQMA0GCSqGSIb3DQEBBQUAMEUxCzAJBgNVBAYTAkpQMRUwEwYDVQQKEwxXSURF IFByb2plY3QxHzAdBgNVBAMTFm1lbWJlcnMgb3JpZW50ZWQgQ0EgMDIwHhcNMDYwNjEyMDQ1NTA5 WhcNMDcwNjMwMjM1OTU5WjBkMQswCQYDVQQGFAJKUDEVMBMGA1UEChQMV0lERSBQcm9qZWN0MRsw GQYDVQQDFBIwMzI4IEtlaWljaGkgU2hpbWExITAfBgkqhkiG9w0BCQEUEmtlaWljaGlAaWlqbGFi Lm5ldDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAu6pTSPQTKzeSygFymRWYipFcZRaePRSU nruo6RtpQuNgDyUKvaMOa1KuNWRPYHp28hoWYe0YBrGj5SdHH2A3wbJ2zP5cXQFgMJMxJXhcWuSu +Foo7n9T1+yFjuc37Us9N4LoXZaM3krFqBHz2XSUCSigzTstdkIXWPwxDg+db4MCAwEAAaOBvTCB ujAOBgNVHQ8BAQAEBAMCBLAwIAYDVR0RAQEABBYwFIESa2VpaWNoaUBpaWpsYWIubmV0MDYGA1Ud HwEBAAQsMCowKKAmoCSGImh0dHA6Ly93d3cubW9jYS53aWRlLmFkLmpwL2NybC5jcmwwIgYDVR0j AQEABBgwFoAUOM7FCTrTDVTyVXHmSMda90Tf6bowKgYDVR0lAQEABCAwHgYIKwYBBQUHAwQGCCsG AQUFBwMDBggrBgEFBQcDAjANBgkqhkiG9w0BAQUFAAOCAgEAlB3DdeJJZ1gJh4sszEgoUg9DIHRG eaotuAi5FfGkd+KmzEARKYvgfh1A8AVAoHISFvavv0OD9w9dmzGyAmNUTBUsSMeH/5XiLuWJPbjU 3bVK467oyDEFaA+XFJurRY6RuPb4afHoi+aCHtY/pmcGCCSQPKnOuN8BviNLp/haDQyPVVwA+9it s7PwUArSkPnkBo1GXk4FSFDkijbw6zzJkXePBLHkE3QcFBYIo0woy6P2NFFYz8nPmd8M8qyT0Yh8 A9g0UVxvcWk4gUaJP0AeZ8/raNCr7eXBMByhDx5FSvparc21zEmQ5MnCVduDuM9eM8Qc8zFqzTzg mmZza69jiiq98kL1yFqjfL4+Nu7+N9D8Q/NuaIYLd9E++s20X9Kb7dW1xqMS1E30I8ZZnIwu2Fox ZRziQnKHkatDFBI+zuNY3+nIcE8bvzm/Y36xwk2GhN8p707CsT5i17ZCzkvriCdkE13riXNhXDOe qGR6Kj1aZLLBxHeLvFUa72q65+ShesszO6lOxf66auFbXYsOfzIUhG3z5YmM6Lk5NtJom6F7Drob jPjyDv2zZoGNGdIqbDbOaFkmBEYchuToVMNzYk6v6d+v4A/MrnGlexgQbzfgC0Ld32NwPlDDGFnO LPjaEZ19bFK65rWjWwEyLsO15GD7jotBrDU5yngkhu15RKowggYHMIID76ADAgECAgIJFjANBgkq hkiG9w0BAQUFADA+MQswCQYDVQQGEwJKUDEVMBMGA1UEChMMV0lERSBQcm9qZWN0MRgwFgYDVQQD Ew9XSURFIFJPT1QgQ0EgMDIwHhcNMDYwNTE4MTMzNTM2WhcNMTYwNjMwMjM1OTU5WjBFMQswCQYD VQQGEwJKUDEVMBMGA1UEChMMV0lERSBQcm9qZWN0MR8wHQYDVQQDExZtZW1iZXJzIG9yaWVudGVk IENBIDAyMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA4BYQZ8z3YdyJUt0ZbDh0+rVf fpf/Aw2J2GKNLy4fMIGpEhjS+OhAPC9TUH6rNVV2AR6myr94stzWhGY++bZjd7/oYYRLa+tCtUKa Om49ibS8CHSqfeR/Yb0YHKTrHCaAu2PUw6kENGZ3bDCiMbuDPkPLVkYuN3rSRp3qHd1XJ8DZ2bTX DbW3cwVqHFxKjVf6mdBInlL8pMs9z4T9GNpcqQO1i7Uk467KLZYbi1W1d5m23Jodr/7/y08bc078 ppWE3dP9eNEysmRxdIvKMgTHfTjtYN3ZhnfUEsYoJ6W9flc9Qoe+5UqdBt+O5ruJM3m1viWf+Rs8 xvvs9ZnodrqaxAIDwgmgpHePLCV2Qc/Fix3vkLY2Rt9KXeRCjLOzgdCYhtuJI42hY/l9dJjrRRK/ Qo5jABzbRRJzCavDlqS25q1OXenrO64nU+7T92PfFeOv1ORg5PcCSoY0dIzN9lcL51yb2PLn3cUx ya4itIYV9MHFXaIDM4inLLmBUR/0xD4Q+Ju1Zqd5n+uK5lCrQ48+kMPKbrDyrDyvqHYTo8XRuyAU Z1F56NJFv6umd+/m0ADC1M7Q9HNXwt8dRZyvVgH8l4teYu9We32NtZ7H8dyNaa34R2zs1bP2ftDT Au//Bi/3u47JTSJ6M1zE6lsc7OwP6c32okaCRCwayxVYi+FgNdUCAwEAAaOCAQYwggECMA8GA1Ud EwEB/wQFMAMBAf8wDgYDVR0PAQEABAQDAgH+MFsGA1UdIAEBAARRME8wTQYJKoMIjJwYAQECMEAw PgYIKwYBBQUHAgEWMmh0dHA6Ly9tb2NhLndpZGUuYWQuanAvbW9jYV9ndWlkZS9tb2NhX3BvbGlj eS5odG1sMDwGA1UdHwEBAAQyMDAwLqAsoCqGKGh0dHA6Ly93d3cud2lkZS5hZC5qcC9jYS93aWRl cm9vdGNybC5jcmwwIAYDVR0OAQEABBYEFDjOxQk60w1U8lVx5kjHWvdE3+m6MCIGA1UdIwEBAAQY MBaAFAzMoku5z7HsuNTr5KwJl0+xojExMA0GCSqGSIb3DQEBBQUAA4ICAQAKZpGub2X1UG9aXuAS P1MsRJtlgcataxapi6Lbox+8/5nrLXA6M5+FSD/3wjO96KEdv+KGK4WIE6AAsGKdH0dFE8jgzGVw uyoyXZg+UWhFrCMB3lbNfY9UsTBJfVx1TlMC1BXaT5qKCgp2N5dF6s2yeNa1kgGvR+xDkxNGDf6q 3xcN3QiC9ofyUyeRaZEacTjUp7bo4VREFtv3txyocbT6B961inhUS3PZNx6nIzJqiZA2CX/QGrlg 7uE1EoXgSJ+N77MdasX5Tl69Cb+fJCAdlbji1LAgWLEPXM0kHyYnfsLHfEXo4bCRdpN+GpPvqyhW DOk8ZEmrzYglsK38KIIG4Mp0tUoj25nzXhHnkNt0OCLSvzPcTopabRaPl4MnvQQ1tGsKbSafUBR5 gzdjA/f/o9bQKYwZC+fP8Gu50Ib4sYc5BbXEZdUx0Pjc/1nbIuM0t1YFrfLOiWP+Ar0x/WuPrtLZ gUyRnVBVyHm73be8T9wfE31aJw9E+2a92cjrp0lyCfWoCKjHGxdsPFvPIg1gKVG/IlgKeKEnKu1N O4PmD//LW/7p6A5V/W1vGZn8jI9ErwVz2cMiyJJfRVaviV5TcC58vrREH6qB9LfJwA7jy4CRu1oP GsaQRg5ZTMaV1JZ5cFBNHKcJiSDPTqVdKPkjmSUVUlYvEN+08pPGK/4KcTGCAgwwggIIAgEBMEsw RTELMAkGA1UEBhMCSlAxFTATBgNVBAoTDFdJREUgUHJvamVjdDEfMB0GA1UEAxMWbWVtYmVycyBv cmllbnRlZCBDQSAwMgICEhAwCQYFKw4DAhoFAKCCARcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDcwMTMxMDg1MDA2WjAjBgkqhkiG9w0BCQQxFgQUbP7EJQkfsY3+ jhsb/eDy66sPG5IwWgYJKwYBBAGCNxAEMU0wSzBFMQswCQYDVQQGEwJKUDEVMBMGA1UEChMMV0lE RSBQcm9qZWN0MR8wHQYDVQQDExZtZW1iZXJzIG9yaWVudGVkIENBIDAyAgISEDBcBgsqhkiG9w0B CRACCzFNoEswRTELMAkGA1UEBhMCSlAxFTATBgNVBAoTDFdJREUgUHJvamVjdDEfMB0GA1UEAxMW bWVtYmVycyBvcmllbnRlZCBDQSAwMgICEhAwDQYJKoZIhvcNAQEBBQAEgYBxDCx2UeZD9cHNMafP vD3UAOS3ut3wmdXjcunjS4EymFjgFMrRbfvfpiIqdQGvmNudtHMleBlHxK+SOwA9/aFPBOZHpxIu jgCJufZQSxih3rKI1QgHMB/P8USkBiaBS7kGtmHLUEfYOp3qJ6Er7vgiQdmTZOlfmNobm4vs7Db2 FAAAAAAAAA== --Apple-Mail-15-800160949-- --===============0892810605== 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 --===============0892810605==-- From mip6-bounces@ietf.org Wed Jan 31 05:27:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCCgP-0002lq-P4; Wed, 31 Jan 2007 05:27:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCCgO-0002lk-Bj for mip6@ietf.org; Wed, 31 Jan 2007 05:27:16 -0500 Received: from tao.fdupont.fr ([82.236.136.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCCgM-0001uH-S3 for mip6@ietf.org; Wed, 31 Jan 2007 05:27:16 -0500 Received: from tao.fdupont.fr (localhost [127.0.0.1]) by tao.fdupont.fr (8.13.5/8.13.5) with ESMTP id l0VAR0pN019468; Wed, 31 Jan 2007 11:27:02 +0100 (CET) Received: from tao.fdupont.fr (dupont@localhost) by tao.fdupont.fr (8.13.5/8.13.5/Submit) with ESMTP id l0VAQvOf019464; Wed, 31 Jan 2007 11:26:59 +0100 (CET) Message-Id: <200701311026.l0VAQvOf019464@tao.fdupont.fr> From: Francis Dupont To: Keiichi SHIMA Subject: Re: [Mip6] Question about draft-sugimoto-mip6-pfkey-migrate In-reply-to: Your message of Wed, 31 Jan 2007 17:50:05 +0900. <249F62F0-967F-40F7-9A94-61AFA92AE595@iijlab.net> Date: Wed, 31 Jan 2007 11:26:57 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: mip6@ietf.org, Kazunori MIYAZAWA 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 In your previous mail you wrote: I have a question about the PF_KEY extension draft (draft-sugimoto- mip6-pfkey-migrate). The draft proposes SADB_ACQUIRE message extension to include the entire (or the beginning of the) IP header that triggered the acquire message. The reason of the extension described in the draft is to extract the CoA of an MN that is used for IKE communication. The question is that, do we need to include the entire (or the beginning of the) packet to the acquire message? If the goal is to provide the CoA information to an IKE program, then why can't we simply notify the address? => in fact you have the choice between to decode the packet in the kernel or in the application. I am in favor of the first option for many reasons including: - it is better to keep the kernel as simple as possible (i.e., KISS principle) - we don't know a priori what applications will need. Including a raw packet has two drawbacks. 1. The IKE program that supports this extension has to parse the raw IPv6 packet to extract a CoA. => someone has to do this. 2. Some kernel implementations do not have the final packet structure when sending an ACQUIRE message. In these implementations, they only have abstract information to construct the packet, and the packet will be constructed just before it is sent. In this case, the kernel must create a packet before sending an ACQUIRE message, that is not necessary in their design. => to give the final structure doesn't matter as the decoding code is supposed to be kernel dependent (even if there are no many choice and it is easy to get one code working for many kernels). The only key point is to give to the application enough information, the way they are organized is a detail as soon as the application knows it! Thanks Francis.Dupont@fdupont.fr PS: if you believe it can be good, can you propose some text to explain this to add in the I-D? _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jan 31 08:22:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCFPC-0005zb-DM; Wed, 31 Jan 2007 08:21:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCFPA-0005zW-BQ for mip6@ietf.org; Wed, 31 Jan 2007 08:21:40 -0500 Received: from tao.fdupont.fr ([82.236.136.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCFP8-00038K-UF for mip6@ietf.org; Wed, 31 Jan 2007 08:21:40 -0500 Received: from tao.fdupont.fr (localhost [127.0.0.1]) by tao.fdupont.fr (8.13.5/8.13.5) with ESMTP id l0VDLWeU019868; Wed, 31 Jan 2007 14:21:32 +0100 (CET) Received: from tao.fdupont.fr (dupont@localhost) by tao.fdupont.fr (8.13.5/8.13.5/Submit) with ESMTP id l0VDLTJx019865; Wed, 31 Jan 2007 14:21:32 +0100 (CET) Message-Id: <200701311321.l0VDLTJx019865@tao.fdupont.fr> From: Francis Dupont To: Jari Arkko In-reply-to: Your message of Wed, 03 Jan 2007 13:14:33 +0200. <459B9019.8030301@piuha.net> Date: Wed, 31 Jan 2007 14:21:28 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: 'COMBES Jean-Michel RD-MAPS-ISS' , Mobile IPv6 Mailing List Subject: [Mip6] Re: re-review of mip6-cn-ipsec 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 In your previous mail you wrote: > The purpose of this document is not to replace the [RFC3775] return > routability procedure by the use of IPsec/IKE which has some > authentication requirements which make its universal deployment more > than unrealistic. Again for readability, change to The purpose of this document is not to replace the [RFC3775] return routability procedure by the use of IPsec/IKE. It is unrealistic to expect credentials to be available for strong authentication between any pair of communication hosts. => I have still a problem with this, current text is: The purpose of this document is not to replace the [RFC3775] return routability procedure by the use of IPsec/IKE which has some authentication requirements which make its universal deployment worse than unrealistic. The wording of your proposal seems better but it doesn't mean the same thing even we agree *universal* deployment *today* is unrealistic. Regards Francis.Dupont@fdupont.fr _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jan 31 08:42:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCFiU-0006Nc-0i; Wed, 31 Jan 2007 08:41:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCFiS-0006NX-NT for mip6@ietf.org; Wed, 31 Jan 2007 08:41:37 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCFiQ-00019Z-AK for mip6@ietf.org; Wed, 31 Jan 2007 08:41:36 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id A51391986AF; Wed, 31 Jan 2007 15:41:33 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 675C81986AE; Wed, 31 Jan 2007 15:41:33 +0200 (EET) Message-ID: <45C09C8D.7080805@piuha.net> Date: Wed, 31 Jan 2007 15:41:33 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Francis Dupont References: <200701311321.l0VDLTJx019865@tao.fdupont.fr> In-Reply-To: <200701311321.l0VDLTJx019865@tao.fdupont.fr> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: 'COMBES Jean-Michel RD-MAPS-ISS' , Mobile IPv6 Mailing List Subject: [Mip6] Re: re-review of mip6-cn-ipsec 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 Francis, > In your previous mail you wrote: > > > The purpose of this document is not to replace the [RFC3775] return > > routability procedure by the use of IPsec/IKE which has some > > authentication requirements which make its universal deployment more > > than unrealistic. > Again for readability, change to > > The purpose of this document is not to replace the [RFC3775] return > routability procedure by the use of IPsec/IKE. It is unrealistic to > expect credentials to be available for strong authentication between > any pair of communication hosts. > > => I have still a problem with this, current text is: > The purpose of this document is not to replace the [RFC3775] return > routability procedure by the use of IPsec/IKE which has some > authentication requirements which make its universal deployment worse > than unrealistic. > The wording of your proposal seems better but it doesn't mean the same > thing even we agree *universal* deployment *today* is unrealistic. > I just attempted to break up the long sentence. Would adding "today" or "universal" to some part of my text make it OK for you? Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jan 31 17:24:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCNs9-0006Xs-KQ; Wed, 31 Jan 2007 17:24:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCNs8-0006XL-5u for mip6@ietf.org; Wed, 31 Jan 2007 17:24:08 -0500 Received: from 207.47.15.6.static.nextweb.net ([207.47.15.6] helo=mail2.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCNs4-0003Su-Lr for mip6@ietf.org; Wed, 31 Jan 2007 17:24:08 -0500 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, 31 Jan 2007 14:24:03 -0800 Message-ID: <45C11700.4010400@azairenet.com> Date: Wed, 31 Jan 2007 14:24:00 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "K.Kawaguchi" Subject: Re: [Mip6] Non-tunnelled Echo Req MN to HA References: <459A295C.5000005@motorola.com> <200701051650.JGI82841.BJLHVUXB@ysknet.co.jp> <45A26BA7.9060102@motorola.com> <200701091652.AAH56236.XJVBUBLH@ysknet.co.jp> <45A39A57.4020801@motorola.com> <200701161433.JBD35485.HLJBVUXB@ysknet.co.jp> In-Reply-To: <200701161433.JBD35485.HLJBVUXB@ysknet.co.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Jan 2007 22:24:03.0500 (UTC) FILETIME=[835A0EC0:01C74586] X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 Kawaguchi-san, Sorry for the late reply. K.Kawaguchi wrote: > The test specification interprets RFC3775 as follows now. > > a) Whether HA transmits BRR or not. > > => HA doesn't send BRR. That is correct. > b) How should HA do, when HA receives the packet of Echo Request with > Home Address destination option from MN where HA has the binding > cache entry. > > => HA replies Echo Reply wtih type2 routing headr. > When HA sends the packet to MN, the processing of HA is the same > as CN (10.4.2 refer to 9.3.2 in RFC3775). > In view of the situation, when HA receives the packet from MN, > the processing of HA is the same as CN (so 10.4.x seems to have > missed the reference to 9.3.1.). > c) How should HA do, when HA receives the packet of Echo Request with > Home Address destination option from node where HA hasn't the binding > cache entry. > > => HA replies Binding Error(status 1). > The reason is the same as b). No. If you want to interpret RFC 3775 accurately, the HA should send a binding error (status 1) only if the home address in the home address option does not belong to the home prefix served by the HA. If the HA is the home agent for that mobile node, the packet should be dropped (no binding error is sent). Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jan 31 22:22:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCSVp-0007C6-3z; Wed, 31 Jan 2007 22:21:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCSVn-0007B8-LQ for mip6@ietf.org; Wed, 31 Jan 2007 22:21:23 -0500 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 1HCSUB-0003Yf-Gm for mip6@ietf.org; Wed, 31 Jan 2007 22:19:45 -0500 Received: (qmail 12212 invoked from network); 1 Feb 2007 12:19:31 +0900 Received: from (HELO MIP6-236) (@) by with SMTP; 1 Feb 2007 12:19:31 +0900 To: vijay.devarapalli@azairenet.com Subject: Re: [Mip6] Non-tunnelled Echo Req MN to HA From: "K.Kawaguchi" References: <45A26BA7.9060102@motorola.com> <200701091652.AAH56236.XJVBUBLH@ysknet.co.jp> <45A39A57.4020801@motorola.com> <200701161433.JBD35485.HLJBVUXB@ysknet.co.jp> <45C11700.4010400@azairenet.com> In-Reply-To: <45C11700.4010400@azairenet.com> Message-Id: <200702011219.HCC87083.JHBLBUXV@ysknet.co.jp> X-Mailer: Winbiff [Version 2.43 PL1] X-Accept-Language: ja,en Date: Thu, 1 Feb 2007 12:19:28 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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, Thank you for your comment. Excuse me, I do not understand your sentence enough. Please let me confirm it in a more concrete example. I try to enumerate some patterns, though it doesn't understand be suitable for your intention. - There are the home prefix 2001:DB8:1:1::/64 served by the HA. - The HA has one binding cache entry for the MN-1. - The MN-1 home address is 2001:DB8:1:1::1. - The MN-1 primary care-of address is 2001:DB8:100:100::1. How should the HA do, if the HA receives the following echo request with the home address option. 1) The "well known" addresses in the echo request. Echo request with the home address option src: MN primary care-of address (2001:DB8:100:100::1) dst: HA address home address option, home address: MN home address (2001:DB8:1:1::1) It is echo reply with the type2 routing header in my understanding. src: HA address dst: MN primary care-of address (2001:DB8:100:100::1) type2 routing header, home address: MN home address (2001:DB8:1:1::1) 2) The unknown address in the source address field. Echo request with the home address option src: unknown address (2001:DB8:100:100::2) dst: HA address home address option, home address: MN home address (2001:DB8:1:1::1) It is binding error in my understanding. src: HA address dst: 2001:DB8:100:100::2 BE header, status : 1 home address: 2001:DB8:1:1::1 3) The unknown address in the home address field of the home address option. It is in home prefix. Echo request with the home address option src: MN primary Care-of Address (2001:DB8:100:100::1) dst: HA Address Home Address Option, home address: unknown address (2001:DB8:1:1::3) It is binding error in my understanding. src: HA address dst: 2001:DB8:100:100::1 BE header, status : 1 home address: 2001:DB8:1:1::3 4) The unknown address in the home address field of the home address option. It isn't in home prefix. Echo request with the home address option src: MN primary Care-of Address (2001:DB8:100:100::1) dst: HA Address Home Address Option, home address: unknown address (2001:DB8:4:4::4) It is binding error in my understanding. src: HA address dst: 2001:DB8:100:100::1 BE header, status : 1 home address: 2001:DB8:4:4::4 5) The unknown address in the source address field. The unknown address in the home address field of the home address option. It is in home prefix. Echo request with the home address option src: unknown address (2001:DB8:500:500::5) dst: HA Address Home Address Option, home address: unknown address (2001:DB8:1:1::5) It is binding error in my understanding. src: HA Address dst: 2001:DB8:500:500::5 BE header, status : 1 home address: 2001:DB8:1:1::5 6) The unknown address in the source address field. The unknown address in the home address field of the home address option. It isn't in home prefix. Echo request with the home address option src: unknown address (2001:DB8:600:600::6) dst: HA Address home address in Home Address Option: unknown address (2001:DB8:6:6::6) It is binding error in my understanding. src: HA Address dst: 2001:DB8:600:600::6 BE header, status : 1 home address: 2001:DB8:6:6::6 Best regards --- Kiyoaki KAWAGUCHI "Vijay Devarapalli " wrote: > Hello Kawaguchi-san, > > Sorry for the late reply. > > K.Kawaguchi wrote: > > The test specification interprets RFC3775 as follows now. > > > > a) Whether HA transmits BRR or not. > > > > => HA doesn't send BRR. > > That is correct. > > > b) How should HA do, when HA receives the packet of Echo Request with > > Home Address destination option from MN where HA has the binding > > cache entry. > > > > => HA replies Echo Reply wtih type2 routing headr. > > When HA sends the packet to MN, the processing of HA is the same > > as CN (10.4.2 refer to 9.3.2 in RFC3775). > > In view of the situation, when HA receives the packet from MN, > > the processing of HA is the same as CN (so 10.4.x seems to have > > missed the reference to 9.3.1.). > > > c) How should HA do, when HA receives the packet of Echo Request with > > Home Address destination option from node where HA hasn't the binding > > cache entry. > > > > => HA replies Binding Error(status 1). > > The reason is the same as b). > > No. If you want to interpret RFC 3775 accurately, the HA > should send a binding error (status 1) only if the home > address in the home address option does not belong to the > home prefix served by the HA. If the HA is the home agent > for that mobile node, the packet should be dropped (no > binding error is sent). > > Vijay > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6